🧭Guide 2. - User Context Definition
🧭

Guide 2. - User Context Definition

The process

The goal of this guide is to provide a clear overview of the needs of our users from a developer's perspective. For this we will analyze who they are, what are their problems, their circumstances and their expectations. These will offer guidance in ranking the importance of the different properties of the software technologies. As a further benefit, we can use these to align our unique insight and ideas to the real goals of the product. Getting help from UX colleagues to do the analysis can be tremendous, but we can still get a lot of value out of it even when doing this on our own. First, take a look on the simple overview then I will expand on their details.

Overview

I. What are the goals and tasks of the different user types?
  1. In plain, real world terms, without our product in mind.
  1. The functionality they expect from the product to help reaching those goals.
  1. The non functional attributes the application should have to fulfill their needs.
 
II. What problems do they have? In the following areas:
  1. Business domain - the issues of the tools, processes and workflows that block or constrain the users in effectively reaching their goals. (without considering the solutions we provide)
  1. Product usage - the inconveniences of using the current solution if one already exists.
  1. Service quality - the inconveniences of interacting with the company if it already has customers.
 
III. What are the important characteristics of the average/target user?
  1. The devices they use and their 5 elementary resource capabilities.
  1. The length of product usage in typical user flows.
  1. The different situations of product usage - workplace, public, under stress, relaxing, etc...
 
IV. Describe the customer journey
  1. Identify the steps it takes to become a returning customer or loyal user of your product for someone who hasn't even heard about it.
  1. Identify the parts of UX and the Product API that affect the chances of the user continuing in the process, at each step.
  1. Prioritize their relative importance.
 
V. What are the expectations of the typical user about the product in terms of the Product API?
  1. Define what constitutes each attractor in terms of the current product.
  1. Identify factors that affect their importance for the overall performance of the project.
  1. Prioritize them accordingly.
 
VI. What are the expectations of the typical user about the UX of the product?
  1. Identify factors that affect their importance for the overall performance of the project.
  1. Prioritize them accordingly.
 
This is the outline of the User Context. Once you answer these questions for all user groups, you will have every piece of information that is required for a developer to fully align their decisions with the real user needs. It's important to track usage data to validate and update this definition to improve the value match of the product.

Details

Who are the users? The baseline step is to identify our users. Who is going to be using the system? This is the prerequisite to find what we should build. Of course, in real life, it might come second after a product idea, but for system planning it's the fundamental starting point. Most likely there will be different types of users, with different goals for using the system. The following steps should be done for each of those individually.
What are their problems? The most important factor comes second, to identify their problem(s). What are we trying to solve for them? This is the main driver of what functionalities should we provide. It will vary for the different user types. Understanding what does it like for the real life users to do their business tasks and their job is tremendously helpful here.
Blocks and constraints A really important part is to identify what stops them from achieving their goal, what causes the problem we want to solve, what are their constraints? This reveals more information about what we should do for them, how we should alleviate these issues.
Where are the pain points? Next is to dive deep into the problems and identify the exact pain points our users have. They might already have solutions to them, but if those are far from optimal, the issues can become pain points that hinders their productivity. This will give us the priority of ideas, which ones are the most important, core functionalities and which ones are only nice to have features. Usually these obstacles are the reasons for creating a software solution instead of a physical, the speed, scalability and level of automation an application can provide is usually the key to address the pain points. In case of an established product, this section should include the pain points of using the application in its current form, besides the real world problems our users have.
Behaviors It can be a part of the deep dive to find the behavior patterns the users exhibit. What's common in their course of action when facing the same situation? How they naturally solve their problems, or how they attempt it?
Feelings Finding the real pain points of our users can be guided by identifying what kind of emotions they have in the situations we want to handle. Its important to identify what are the causes of those emotions. Sometimes the first answers are only scratching the surface, it's a good idea to apply the 5 why-s.
Customer journey You can map the whole customer journey which follows all the steps of engagement with the product or service through the phases of the customer lifecycle. Use it to identify the pain points in this process as well and find opportunities for improvement. This will give us priorities for the CL phases so we can focus our efforts on improving the weakest parts.
Examples:
  • Slow processes - speed them up
  • Hard to find information - make it accessible
  • Complex task - simplify them
  • Don't know what to search for - recommend based on existing knowledge
Business events If you want more specific insight into some of the features of the application after identifying the main problems, you can continue to lay out the process our users walk through when trying to get their tasks done. Identify all the business events that happen along the way, which simply means to drop software usage from the picture and think about the conceptual or real life steps. This shows in detail what kind of functionality should the application provide.
Requirements You can gather specific details for the functionalities required to handle each business event. It will be either a condition (budget, time frame, deadline, compliance) or a capability (get some task done, look and feel), often a combination of both.
Prioritize Analyzing the user needs and requirements can go into much more detail than what I described, but the rest doesn't really add to establishing the context of our software. If you did all the previous steps it's more than enough to finish creating our guidelines. It's important to prioritize the previous findings. Rank the problems and pain points in order of their importance to the users, that will hopefully correlate with their importance to the business.
The typical interaction with the product
The technology/technologies they use. What characteristics does it have regarding the 5 elementary resources? What type of inputs and outputs does it provide?
The situation of usage This includes external factors like where does it take place, at what time of the day and internal factors like their emotions and physiological conditions. You might ask why do these matter? Just imagine designing software controlling a nuclear missile launch process on a submarine compared to an application you use to track your golf performance. The difference in emotional state and physiological condition is very significant. The users on a submarine might be under enormous stress and be injured, the software should be absolutely fool proof yet easy to operate even in these situations, but on the golf cart these are much less of a concern. Accidentally touching the wrong button, or having to wait a second doesn't matter that much to the user. Another good example is when using the product in public spaces. Passwords and other sensitive personal or financial data should be discretely handled. A similar example is when the users are servicing customers live, under stress, because of urgent situations (medical history for ER doctors) or simply impatient customers. They should be able to respond instantly and also protect showing sensitive data to the unauthorized customer. It can indicate quick idle timeouts to authentication sessions. The time of the day might indicate a need for a night mode UI.
Typical length and frequency of interaction This might affect the performance requirements and offer guidance in the case when speed degradation issues appear and you need to prioritize them.