{"id":15886,"date":"2017-09-01T18:27:33","date_gmt":"2017-09-02T01:27:33","guid":{"rendered":"https:\/\/www.uxpin.com\/studio\/?p=15886"},"modified":"2020-04-22T06:35:29","modified_gmt":"2020-04-22T13:35:29","slug":"rapid-user-research-enterprise-ux-10-minute-guide","status":"publish","type":"post","link":"https:\/\/www.uxpin.com\/studio\/blog\/rapid-user-research-enterprise-ux-10-minute-guide\/","title":{"rendered":"Rapid User Research for Enterprise UX: The 10-Minute Guide"},"content":{"rendered":"

Your mileage may vary, but my experience with enterprise organizations dictates there is usually little to no budget for <\/span>true user research<\/b> \u2014 meaning user interviewing, shadowing and\/or direct observation of end-users. <\/span><\/p>\n

Getting buy-in for these activities is time-consuming and difficult, and on a tight deadline we quickly realize there\u2019s no time to educate management on user research. <\/span><\/p>\n

So instead of just a \u201cSprint 0\u201d where we carve out time and personnel for heavy upfront user research, we try a different tack altogether: <\/span>we research early, and we revisit it often<\/b> to continually narrow and qualify what we think we know and what we\u2019ve learned along the way. <\/span><\/p>\n

Here\u2019s how.<\/span><\/p>\n

For more practical advice based on 25+ years experience, download the 91-page e-book <\/span><\/i>Fixing the Enterprise UX Process<\/span><\/i><\/a> by Joe Natoli. <\/span><\/i><\/p>\n

The 1-Page Summary <\/span><\/h2>\n

By the time a project kicks off, you\u2019ve probably already discussed how proposed features and functionality will be used. There\u2019s existing knowledge about user roles and responsibilities, and in most cases, some past use history that allows for educated guessing. This is <\/span>what we <\/b>think<\/i><\/b> we know<\/b>, because it has yet to be qualified. <\/span><\/p>\n

Because it\u2019s part of the project, our current hypotheses about user needs are worth documenting. But that documentation should be nothing more than a quick, one-page summary. Many organizations love big documents, but the truth is <\/span>no one reads them<\/b>. And most executives won’t read past the first page, <\/span>ever<\/span><\/i>. <\/span><\/p>\n

Even if your organization mandates gargantuan documentation, create a table-based summary for each section. In terms of user research, my favorite approach is dead simple \u2014 a table with four columns:<\/span><\/p>\n

    \n
  1. Problem\/Issue<\/b> (what problems do we believe users have, that we intend to solve?)<\/span><\/li>\n
  2. Proposed solution<\/b> (how will we alleviate those problems?)<\/span><\/li>\n
  3. Expected Result <\/b>(what do we expect to happen [success metric] both for the users and the organization as a result of doing this?)<\/span><\/li>\n
  4. Related Requirements\/Tasks\/Activities<\/b> (what do we think is needed in order to do this?)<\/span><\/li>\n<\/ol>\n

    If any of this takes up more than a single page, <\/span>your scope is too large<\/b>. You\u2019re taking on too much with lines of inquiry that simply don\u2019t matter. <\/span><\/p>\n

    In my mind, no matter what the document is or contains, these four components are what clearly delineate everyone\u2019s marching orders. They keep all research related activities focused on <\/span>value<\/b>, allowing us to narrow the areas we investigate.<\/span><\/p>\n

    Break everything down to common-sense level, <\/span>write so anyone can understand it<\/b>. Dispense with industry jargon and big words.<\/span><\/p>\n

    Skip Traditional Personas and Get to Context Quickly<\/span><\/h2>\n

    You\u2019ll find plenty of prescriptions for personas, but – unless you follow Alan Cooper’s one true model – they\u2019re all essentially the same: laundry lists that suggest you can understand a person\u2019s motivation simply by checking boxes and asking questions related to behavior. <\/span><\/p>\n

    We don\u2019t have the luxury of time to start wide and rigorously work to separate fact from fiction. We need to be accurate in our first shot at describing user needs \u2014 which means it should be <\/span>contextual<\/b>.<\/span><\/p>\n

    The process includes two key steps:<\/span><\/p>\n

    1. First, develop empathy for the person<\/b>. Empathy goes far beyond demographics, likes, dislikes, job roles and responsibilities. Empathy is about understanding the <\/span>emotional drivers<\/span><\/i> that affect the user\u2019s behavior, because <\/span>emotion will trump intellect<\/b> in almost every user situation. Design for the emotion and you\u2019re truly designing for a <\/span>person<\/span><\/i> instead of a collection of possible attributes. While that sounds intimidating, the truth is it can be done in 20 minutes \u2014 using what we call an <\/span>Empathy Mapping Worksheet<\/span><\/a>.<\/span><\/p>\n

    \"Preliminary<\/p>\n

    2. Next, uncover behavioral attributes that motivate use, in the context of a situation<\/b>. What has the person just done or just finished doing when they encounter the product (site, app, tool)? What are they <\/span>thinking<\/span><\/i> and <\/span>feeling<\/span><\/i> at that moment, and how does that affect what they need to see or do, or how they act? What <\/span>stress<\/b> is present in that situation, and how does it affect the person\u2019s perception and action? Sounds like a lot of work, but again, it typically takes no more than 15-20 minutes. The tool we use is called a <\/span>Situational Mapping Worksheet<\/span><\/a>.<\/span><\/p>\n

    \"Situational<\/p>\n

    Both tools are extremely simple and virtually self-explanatory, and you can learn more about them <\/span>here<\/span><\/a>. <\/span><\/p>\n

    Because we\u2019re focused on <\/span>context of use<\/b> in both situations, our hypothesis are almost always more accurate than any traditional persona work. The enterprise teams I\u2019ve worked with have found that combining this work with simplified user interviews (when possible) is a one-two punch that is <\/span>extremely<\/span><\/i> hard to beat.<\/span><\/p>\n

    Streamline User Interviews <\/span><\/h2>\n

    When interviewing users, aim for the largest representative sample possible. The way you do that is by asking fewer, but more poignant and open-ended, questions.<\/span><\/p>\n

    Don\u2019t ask them about the system at hand<\/b>, or it\u2019s features or functions. Those questions will focus the answers on the tool they\u2019re using \u2014 instead of the process they follow. Any number of factors unrelated to the specific tool or even the <\/span>task at hand<\/span><\/i> may contribute to the current issue or problem. People might use workarounds to avoid using the system altogether. And if you ask a narrow question that\u2019s tactic- or tool-specific, you\u2019ll never hear<\/span> about any of those things. <\/span><\/p>\n

    \"Meeting<\/p>\n

    Here are the 6 core questions that typically prompt people to tell the kinds of stories that uncover problems and desired outcomes:<\/span><\/p>\n

      \n
    1. What constitutes a good work day for you?<\/b><\/li>\n
    2. How do you go about doing<\/b> (name a specific process, task or end goal)?<\/span><\/li>\n
    3. Can you show me how you do that<\/b> (if time allows)?<\/span><\/li>\n
    4. How does this compare to other organizations you\u2019ve worked for? <\/b> <\/li>\n
    5. What are the biggest problems, obstacles or inefficiencies you deal with in doing this?<\/b><\/li>\n
    6. What other things do you do before, during and after this?<\/b><\/li>\n<\/ol>\n

      Are there other questions you can ask? Of course. <\/span><\/p>\n

      But <\/span>these six are worth their weight in gold<\/b>, because they invite the kind of stories that quickly get to the heart of real obstacles. You want to interview as many users as possible, as quickly as possible, so stick to these six. <\/span><\/p>\n

      Here are some quick guidelines to make the interview process quick, focused and easy to manage:<\/span><\/p>\n