Focus on the experience, the interface might follow
User eXperience (UX) and User Interface (UI) are rarely discussed as two separate topics. Job descriptions include both concepts, trainings promise to teach a combination of the two and companies sell ‘UI/UX design’. While this is convenient in everyday office language, it poses a risk to building truly great experiences.
I have recently finished the book ‘The best interface is no interface’. It’s a must read if you’re into UX design and it’s an even more important read if you think you’re into UI/UX design. In short, the book argues that we should separate the two concepts since the best possible user experience usually does not involve a (graphical) user interface.
While the book explains a number of examples, ranging from simplifying car access to measuring activity with an ambient app, I started thinking about how I could apply this concept into my design sprints and development of enterprise applications.
More often than not, companies use models of business processes and data as a blueprint for the new application design. Every data object will get a big table and a form, every step in the process gets a button.
The resulting experience is sub-optimal. Your system serves the process and the user serves the system. Wouldn’t it be better to have a system that serves your user and at the same time, supports the process?
By following the guidelines below, you will learn to understand how to serve the user and design the user experience.
1. Get your priorities straight
In my last post, I briefly explained the foundation for building a great experience, defining the goal you’re trying to reach. By doing this, you move away from the idea that you have to build an interface or even a specific kind of interface. In the end, you’re trying to fulfill an identified need or to find a new opportunity.
The steps following the goal definition will further define, prioritize and design what needs to be developed. After setting the goal, the design sprint teaches you to define key questions. In short, these are questions that will help you validate your prototype by measuring whether that prototype brings you closer to your goal. You start by coming up with potential reasons for failure (e.g. it takes too long for people to understand my app) and turn these into a question ready for validation (e.g. do people understand the app within x minutes?).
The process of defining key questions is very useful and prioritizing these questions gives you an initial sense of your design sprint’s focus. I usually ask the participants or the product owner to pick two or three key questions that are crucial to make the project a success. Prioritization is usually a difficult exercise, but this format does make it a bit easier.
2. Understand your users and their phases
One of the things I like most about a design sprint — and that’s probably most counter-intuitive — is that the visual design is postponed for quite some days. When building an app, you need to know who the solution is serving, why it’s serving them and what process it’s supporting. Too often people mistake a design sprint or design thinking for the act of designing screens. In reality, the screen design is almost a logical outcome of understanding the need and the solution approach.
When creating the user map during a design sprint, I like to dive a bit deeper if the organization has a complicated process. To do this, I co-create a very structured user journey by asking the following questions and visualising the answers from left-to-right:
Who is the key user in this process?
To create an engaging user experience, you need to know which user you’re focusing on. If you’re building something for everyone, you’re creating an experience for no one.
What are the 3–5 phases in this process?
Rather than going into atomic activities, I like to get a sense of the higher level steps that the process goes through. A typical example is the process of buying a product where the phases are something like orientation, discovery, decision and delivery.
What are the user’s goals per phase?
This is much easier and much more effective than finding the overall goal of your user. When orienting, the user wants to know what’s out there. During discovery, the user wants to find the product that is suited to their needs, …
What activities need to be undertaken to reach this goal?
Here you can go into one of two directions. You either describe the as-is process, which is a good basis for understanding frustrations and opportunities. Alternatively, you describe the to-be process in which you immediately define the steps of your new way of working. Describing the to-be process might of course influence the phases!
Via which channel(s) does the user go through these activities?
Please, please don’t think you will create the single platform that your user will ever be using to fulfill their goals. People still talk, read and see billboards in the streets. Identifying or defining these channels will help you target your added value in the overall user experience.
And of course there’s many more layers you can add to this. Input information, output information, frustrations, opportunities, … The key questions that have been prioritized previously can definitely help in deciding which layers should be part of your user journey.
3. Create an experience based on the goals
By now, this one shouldn’t surprise you. The goal you have defined for your project as a whole combined with the goals during specific phases for a specific type of user will provide good guidance for the user experience.
With the project goal “We need our employees to work more efficiently by knowing what’s happening in the rest of the organization”, it’s clear that your solution should show relevant information after very little clicks.
With the user-phase goal “I want to decide which product fits my personal needs”, it’s clear that the user should be enabled to somehow compare a product with their needs and to make a decision.
4. Make the interface follow the user, not the process
Don’t get me wrong. You do need to understand an organization’s business processes when designing an impactful application. However, it’s crucial that the interface does not follow those processes but supports those processes.
Taking this perspective can turn manual steps in the process to automated steps. Even when this automation isn’t possible, there might be a way the system can learn from it’s manual usage and simplify the user’s interaction with the process over time.
A real-world example
A great example that I will never forget was when we were trying to modernize a huge Excel file that was sent to an organization’s account managers on a monthly basis. The file consisted of roughly ten sheets, each containing somewhat important information on suppliers, checks and the statuses of those checks. A goal of the project was to enable different layers of the organization to use that data near real-time, while being on the road.
When we started the visual design part of the design sprint (too soon), the workshop participants created one mobile interface for each of the ten worksheets. This turned the Excel file into a visualization that was even harder to read, since we were now limited to the dimension of a phone.
After asking ourselves what the account managers and their managers were really trying to achieve, we came up with the idea of a layered approach.
Each account manager would see only their suppliers, while still being able to go up the tree with a bread crumb. On the other hand, their managers would get an overview of the account managers that they were responsible for. By using colors we highlighted only the ones that required attention. Clicking on the account manager would show their suppliers, again highlighted with colors to direct attention to the right place.
This simple solution (which might seem obvious when reading it) turned a very complex interface into a very simple interface. The time this saved and the satisfaction it created among employees was significant and shows that defining the UX is an instrumental element in application delivery, even when building internal-facing applications.
Will we ever work without user interfaces? Maybe.
Until that point, we can at least save a lot of employees’ time and frustration by simplifying the path towards their goal. In the end, that’s what a great user experience is about.
