In my previous article, “Designing UX for business software: the solution in two steps“, I tried to motivate people who have developed business software to review their applications in a User-Centric fashion, providing a simple two-step recipe for success.
The first step is to know your user. It may seem like a given, but in practice it isn’t, given that usually the person who designs and develops business software is not a user of their own products.
What type of knowledge is needed to plan effectively? In short, you need the ability to identify with users, to the point of understanding the conditions in which they will use the software, how well prepared they are and how well they understand the process, and the reasons they may find it pleasing or irritating to use our products.
This task does not replace the more technical portion in which you analyze the process, the data involved, and the application architecture, but instead it complements it. And since it’s crucial to the company’s success, it’s appropriate to complete it before everything else.
How can you achieve this level of understanding and identify with your users? The best thing is to put yourself in their place, even physically, spending time with them to understand what their problems actually are. The more you observe the better: making hypotheses can be misleading because we’re inevitably conditioned by our preconceived ideas.
At this point, we need to formalize the results of our observations. UX design techniques require different formalization methods. In my experience I have found that three types of documents can suffice: the User Profiles, User Stories and the Business Model. What do they contain?
In the User Profile document you need to describe the various types of users for the application. For each type of user, you need to describe:
- significant personal characteristics, such as level of education, ability to understand the process, and familiarity with IT tools.
- Usage conditions: when the system is used, where, for how long, by which users, and in which environmental conditions. Using a system on your smartphone at the subway stop is not the same thing as doing so on your desktop computer in your own office.
- The problems that our users have (pain) and how our system should help them overcome these problems (gain).
A web search will find you many User Profile examples.
The User Stories document is, in my opinion, the one that is most important to write – and to be completely honest it’s also the most fun. The job is to describe the typical situations in which the system will be used, best if observed in real cases. This description is delivered in actual stories in which you describe the context, the problem to be solved, and how the application helps – or will help – the user, through to the success of the operation.
For each type of user, you should include at least one story for each specific application function that concerns them. That means that this document is larger than the other one, but it is also crucial for checking that the prototype (mockup) of your application is suitable for the purpose.
There are also examples of User Stories documents on the web.
Lastly, it’s smart to also include a description of the Business Model. Why does the business model affect design? The answer is simple: today we can use a multitude of business models for software. Think for example of the SaaS model, or the freemium model, or models that are completely free based on advertising or cross-selling schemes. Each of these models affects the characteristics of the application UX, in the sense that they determine both the functionalities and how they are presented. In some cases, the application has to sell itself. That means it’s important to check that these characteristics are given due consideration beginning with the prototype design.
It is only at this point, after we have worked carefully on these three documents, that we are ready to take the next step and see how to use UX standards to reach a solution that is adequate for our business type applications.
Il passo numero due? Lo trovate nel prossimo articolo!
Step two? You’ll find it in the next article!
