When wearing the information architect hat, your job is designing a user interface (UI) structure that satisfies the corporate business strategy, product strategy, and user experience strategy and accommodates all use cases and product requirements. Information architecture addresses questions such as:
- What are users’ primary goals, and how can they achieve them using the application?
- How do users get from place to place?
- What rules exist that users have to work around?
- How are product features and components branded?
- What is the optimal scope of the application’s feature set?
- How do the UI roadmap and product roadmap position the application in its vertical market?
- How should I enable users to create and store multiple objects?
- What is the application’s search mechanism?
Through laying the groundwork and producing the deliverables shown in the sidebar, information architecture provides the foundation for the other competencies.
With increasing pressure to create rich user experiences, the interaction designer bears the greatest load and is responsible for conceptual design, which requires exposure to the latest UI patterns and components. In laying the groundwork for and producing the deliverables listed in the sidebar, the interaction designer dives deepest into the minutia of page elements, presentation, and page flow.
Questions the interaction designer must address include:
- What layout pattern would work best?
- Which features and information are of higher importance, and how do I draw users’ attention to them?
- How should I incorporate the user feedback I am getting from user research, user surveys, and formative and summative usability testing?
- What behaviors occur on dragging and dropping, on mouse over, and so on?
- How can I communicate the strengths of a feature or application?
- How can I satisfy users’ primary needs and support the tasks that let them achieve their goals?
- How can I draw on users’ intuition to get them to the next step?
- How can I ensure users are aware they’re performing a subtask that’s part of a greater task they’ve started?
- How can I use the UI components that are available to me—such as grids, tabs, and panels?
- How can I maintain consistency throughout the application?
The emergence of rich application experiences has increased the workload for interaction designers. What, in a traditional Web design process, we once specified as page-by-page state changes, we now achieve through a UI-component-by-UI component, multi-state specification often expressed as a matrix. At present, no single methodology that efficiently enables the documenting of rich application designs has emerged as the standard in the UX design community.
On the plus side, the focus of specifications has shifted. Remember when interaction designers had to specify a UI component, then give the specification to the engineers to go build it? Now designers can just pick a pre-built component that the engineers can configure.
At my company, I am the sole user experience designer, and I have observed that, when shifting into usability engineering, it is beneficial to completely remove myself from the other four competencies, for three reasons:
- Doing so immediately places me in the mindset of the user.
- It favorably affects my ability to maintain neutrality when conducting usability tests.
- It gives me perspective on design churn.
Shifting into a user mindset helps me both when laying the groundwork for usability testing and when creating the pre-test and post-test deliverables shown in the sidebar. It is essential when conducting usability test sessions, evaluating the findings of a usability test, and making design recommendations.
I’ve also observed that the moment my usability engineering hat comes off, I dive right into another design iteration, fueled by the abundance of newly gathered knowledge about usage patterns.