By
Roxane Neal
Recently I heard Sarah Barrett of Factor describe how she overcame hurdles in creating an information architecture. These hurdles were brought on by the complexity of the domain she was designing for. At her recent meet-up, “How Hard Can It Be? Information Architecture in a Complex Business Context,” she offered lessons learned designing the information model for an intranet used by personal insurance underwriters. It wasn’t a sexy project, but it was complex. I could relate because for the past six years I have conducted user research for IT management software. In the last two and a half years I worked in a particularly complex domain: management of virtualized servers, networks, and storage that are pooled to create private and public clouds.
Most of us in UX are faced with researching or designing projects in complex industries and could benefit from sharing strategies for learning quickly, making progress efficiently, and ensuring you, your client, and your target users share an understanding.
The root problem is that you can’t possibly understand the whole domain quickly enough to understand the users’ needs completely. How do you provide value quickly to your client or to your product team? How do you confidently argue for findings and steer designs when you are new to that industry’s domain?
Below I share a few tips from Sarah Barrett, a few colleagues, and myself.
1. Plan for iterations of the discussion guide after a few sessions
As with most consulting work, Sarah and the Factor team planned a schedule for user research activities. However they decided to modify that schedule as the first few interviews presented new terminology and challenging topics. They made time between user interviews to review the special language with the client as well as the complexity they were hearing from the underwriters. They revised the discussion guide as their understanding of the underwriters’ domain evolved.
2. “Give them the tools to disagree with you”
When you need to ensure you are super clear and have a shared understanding with your client, Sarah suggests a method to review the discussion guides more closely and realistically in order to give the client a first-hand view of your thinking. On Sarah’s project the client didn’t just review the discussion guide and then comment within the document or via email. She asked the client the interview questions directly so he would experience the questions like the target users, the underwriters.
3. Build up a glossary as you learn
Don’t get lost in a sea of acronyms and unknown terms — look them up quickly. I used Wikipedia and Microsoft TechNet every day to understand terms or to learn how a Microsoft product worked. I also kept track of them and shared my glossary with my coworkers.
4. Ask for lessons from the subject matter experts (SME)
In consulting you might only get a kickoff meeting to learn about the project. However, ask for a separate meeting where your client or a subject matter expert can give you a more in-depth explanation on this domain. When I was on the virtualized IT infrastructure project, I asked the program manager who specialized in storage to give the UX team a one-hour overview of storage concepts. This PM was happy to share his knowledge. We ultimately met four times to cover the necessary concepts, but the UX team became well prepared and we forged a good relationship with this PM.
5. Ask for access to the systems the target users rely on
If you gain access you can look up features that your participants have mentioned. Your clients may have security hurdles in getting you this access. For example, layers of approval are often required, confidential information would become visible to a vendor, or there’s a risk of making mistakes in complex systems for the untrained. But it never hurts to ask.
6. Jump in and start diagramming
My UX architect friend Ken joined a complex project late and was evaluating prototypes within three weeks. This project required integrating and re-envisioning three hotel contracting systems from three different companies that offer vacation packages. His first step? He sketched a high-level workflow when talking to stakeholders and SMEs, then worked on figuring out the data model (e.g., hotels, room types, occupancy rules, dates, prices, capacity, etc.). The flow chart helped with his understanding and his discussions, then he started wireframing. Each artifact advanced the discussion between designer and client, creating a shared understanding. He was soon able to create a prototype and get it in front of the target users, those who load complex hotel contracts into the vacation packaging system.
7. Don’t sweat that you can’t know it perfectly
Ken reminded me of how design projects can never be perfectly designed and executed, so it’s more important to get started researching and designing than being fully prepared. After you’re well into the project you will likely realize you should have done something differently, but iterate as needed and learn from it.
8. Use multiple methods
Fundamental to the research and design process is that we can use a variety of methods to uncover the tacit knowledge of the experts, get at their mental models, and represent the complexity of processes. Observation, interviews, diagramming workflows, journey maps, card sorts, and task prioritizations are some of the techniques we use in design projects to understand our target users’ processes, goals, pain points, and terminology.
Why extra steps matter
Why should you take extra steps for learning your client’s complex industry? For one, you can ask more specific questions. Sarah found that asking specific questions, only possible through the extra work they undertook to understand the insurance industry, got them better information. In my work on IT management tools, all additional domain knowledge directly aided me in asking appropriate follow-up questions and ultimately interpreting need. For example, if I heard “MDT” or “WSUS” I knew to ask about server deployment or updating.
The domain knowledge is needed to make leaps in insight. My colleague Tom worked on a redesign of a system for insurance underwriters and also required the extra learning to understand this industry. Not only did his user research get at the tacit knowledge, but he also needed domain knowledge to make the associations among the existing processes and goals he was hearing about from the underwriters in order to redesign the system.
Facing lots of complexity in your UX projects? When you start a project, accept that you may need slightly more time in the schedule but these strategies could help you conquer the confusion with efficiently. Ultimately, I hope you embrace the challenge, enjoy the learning, and don’t let yourself be overwhelmed by it.
Roxane is downright giddy that Seattle has become the epicenter for Infrastructure-as-a-Service (IaaS) and Platform-as-a-Service (PaaS) cloud computing companies. Always thorough and tenacious, she is currently exploring every lunch eatery in a six-block radius of Blink’s downtown Seattle offices.