User research is important. All of us smarty-pants UX practitioners say so. But does the rest of your project team know how understanding user motivations and mental models lead to a better final product? Your project manager reads the personas and knows that Sharon Shopper researches products online while taking care of her 3 children. So what? How will this influence what she does?
I had spent most of a pregnancy as the only UX resource on a multi-million dollar project. There were expectations that once design deliverable templates and a style guide were created, the UX work would be complete. Other roles would have a sort of instruction book to design the rest of the application. Needless to say my days included copious evangelizing. The nature of the project meant also meant that most of the team consisted of database power users, the type that doesn’t have much use for an elegant GUI. After much gnashing of teeth and circular arguing, the self proclaimed ‘data people’ came to appreciate my user-centered perspective even if they were still unsure of my methods.
When I returned to the project following my maternity leave (Welcome to the world Baby Zoey!) I was asked to review the UX deliverables created while I was out. The wireframes and site map didn’t need much help, but the user research artifacts told an interesting story.
The spreadsheet from the new methodology recording user characteristics was mostly filled with “NOT APPLICABLE”. Really? The amount of daily time the main users spend using the application is not applicable to the creation of said application? The person who recorded the information didn’t understand what could be done with it. What user characteristics affect the design? Sure it’s unfortunate that user A gets interrupted frequently while running his Reports, but so what? Since we’re designing the interface according to best practices, it will create the best experience possible. Right?
When we extol the virtues of user research, we need to let people know how it’s used in order for everyone to understand why it’s important. For someone who has watched hours of usability tests it is apparent. But for the uninitiated, the explanation often sounds like this:
Step 1: Know your users. You are not your users.
Step 3: Create an easy to use product.
We need to explain what happens in between. How do we use the personas and contextual interviews to influence the design? Use examples. Explain how users that are more frequently interrupted need extra signposts to remember where there are or that older users need higher contrast fonts.
Step 2: Prioritize features according to their impact on your users, and design the application to satisfy the specific needs of those who will use it. If a best practice conflicts with what is good for your users, do what is best for your users. Oh, and never assume that you know what is best for them. Test with them instead.
Personas are often created and pinned up on team room walls by User Researchers saying that even the programmers benefit from empathizing with the users and understanding their mindset. I’ve never witnessed anyone explain HOW that benefit is achieved. Not everyone makes the necessary leap that the design your users need may contradict what works for you and seem crazy to the majority of the populous. Identifying the right people as users, learning about them and testing your designs with them gives you what you need to end design debates and make the right decisions.
Try including HOW knowing your users begets a better product in your next project proposal and see if those user research dollars flow a little more freely.