Principles of information architecture
High-level guardrails to enact design-bias product decisions.
Aug 12, 2020
Information architecture (IA) is a discipline that helps teams create meaningful relationships between core decisions of software products.
With this definition, IA is a required "making sense of messes" skill set for project teams, and organizations, that desire to reach a higher level of design maturity.
This is true even when thinking about organizational design systems. IA enables a design system to transition from mere component libraries toward the efficient cultural collaboration of how teams create products together.
In an effort to improve the quality of IA within software products, these are the five principles of IA that I have found most useful.
Principles of IA for software products
1. Minimize personas
Any product should strive to define and scope itself to a minimum number of core personas. Start with one, and only increase as absolutely necessary.
2. Minimize user goals
Any product should strive to define and scope itself to a minimum number of user goals per persona. Start with one, and only increase as absolutely necessary.
3. Minimize user goals per page
Any product should strive to define and scope itself to a minimum number of user goals per page. Start with one, and only increase as absolutely necessary.
4. Content follows user goals
Product content should reflect personas' goals in a way that answers “what” information helps a person achieve goal success.
5. Sequence content over time
Product content should be sequenced over time in a way that answers the “when” and “where” information best helps a person achieve goal success.
Generally, these principles can help scope products. They enable small-scale startup focus and also a heuristic-like evaluation for multiple product platforms all at once.
This helps tremendously with operational aspects of an organization: team sizes, how and when to scale, how much teams can handle, how to scope the project team and the product, how to keep focused on a managable number of problem space at a time, how to know when to jump to the solution space, how to plan finances for project teams, how to measure success, and more. The nostalgic blue balls of product scope helps to visualize this.
Lastly, by promoting these principles within a design system site, entire organizations can move beyond the "don't recreate the wheel" goal for the technology or code that goes into products. Organizations can now move toward the "dont recreate the wheel" goal for the cultural aspects (shared resoures, values, language, destination, understanding, equity, execution) of creating products.
In the future, I'll write playbook activities that use these principles in practice, since these principles begin to enable the enactment of a design-bias product decision framework.