Continuing our series about UX tips for small areas we take a look at charts this time.
- always label your axis – this one should be obvious the reader needs to know at what data he looks
- use units – is this meter or yards, data can only be understood if the scale is clear
- use distinctive colors – different data, different color, and don’t forget the color blind
- use color with purpose – same data, same color, e.g. having different values of the same source should use the same color or tint of color
- for bar charts always start at zero – the distortion often used for exaggerating differences is immense
- leave out decoration – decoration distracts from the data
- no 3d effect – data speaks for itself, please do not try to make it prettier
- use them for lots of data – if you just have a few numbers a table of data might be more appropriate
- use a title – what aspect or slice of data are you showing me, a summary helps to understand perspective and intention
- use a big enough font – this and the appropriate contrast should be obvious for all UI work
- label tick marks – use them at meaningful intervals, do not just slice the axis into equidistant intervals
- include time – even if it isn’t a time series chart, tell the reader from when the data is
- size 2d shapes by area – do not use diameter or radius for sizing 2d shapes (circles, bubbles…), unless you use bar charts (where the length is compared) the proportion gets way out of hand
- use consistent rounding – first round your numbers and do this consistently
- for comparisons use the same scale – do not distort your data by presenting it at different scale
User experience is a vast field which can be overwhelming at start. To make it easier for others I want to break it down to specific areas.
The start makes a rather narrow field of software: forms.
Forms are ubiquitous: almost every software user interface has them. Most of them are too big and overwhelm the user. But in complex software you cannot “just” leave out some inputs to make a small form. Here are some tips to improve your next form:
- use a grid – your labels and inputs (and indeed every UI element) should be layouted on a grid, the goal is to improve scanability and readability and to reduce visual clutter
- align all labels in the same way – this one should be obvious, but often it is missed, it doesn’t matter if the labels are left or above the input, all should be aligned in the same way
- use labels – another obvious one but often labels are omitted to make the UI look cleaner, but if the user cannot see from looking at your interface where he inputs his username or password something went really wrong
- put fields in chunks – if the form gets too big (and most of them do), use blocks with whitespace around them to chunk fields, how do find out the groups for the chunking? You should know the domain and you can always ask the user
- use specialized inputs – if only a date can be entered use a calendar widget, if you need a color use a palette input, the goal is to reduce errors made by the user, which also reduces his frustrations
- provide format helps – if you cannot provide a specialized input, provide format helps, describe how the input should be formatted and what formats are accepted, again to reduce errors
- order the fields – ask the user and a domain expert what the mental model of the fields is, what order should the inputs be made, what is optional, what is important
- distinct the mandatory from the optional – nothing is more frustrating than to fill out a form, click submit and get told 10 times which fields are missing
- use different sizes – if the input is just a one digit number the input should be sized to indicate this, if you want 3 lines of text, use three rows, the goal is to visually communicate what kind of input is expected, but remember: please align them properly
I hope these tips help you to make better forms and make your users less frustrated.
At the start of a new project we like to begin with a naive mind, a beginner’s mind. In it we try to avoid our assumptions and start with a blank slate. Our clients do not. They are expert in their respective domain and know a lot. It’s naturally that during the project we learn lot about them and their domain, their work and their daily struggles. We see how they work around the limitations of their tools and cope with software written more than 30 years ago.
But besides us learning something about the domain, the stakeholders learn something about their domain, too. Because to develop the domain, the use cases and the daily work, we have to know details and reasons. Why is this step before that? Is it optional? Are these all the formats which are allowed? How long is the text usually? Why is there an exception to the rule? How often does it happen?
Usually we ask questions which cover the most traveled path, the happy trail. But in order to understand we need to get to the edges as well. The dark edges. Sometimes the number of objects we deal with is so big, nobody has all the answers. Our work, even before we write the software, enables collaboration. People and different departments have to work together. We work with all of them. Our software helps them to reach their common goals. But before that we need to know. And in order to tell us that the stakeholders need to dig deeper in their respective domain. Sometimes we need to look at the history in their domain, their work history, the decisions other stakeholders made in the past. It’s like archeology without the shovels, well, most of the time :).
Luckily the people we work with enjoy getting to know more about their work. They are astonished what depth the details have. How much different types of things, where gaps are. It is not always easy to light up areas that were kept in the dark so long. That were done just the way they were done. No we come and ask sometimes uneasy questions. We need to know. We need to know exactly. We need to know deeply.
This curiosity is not for its own sake. Our clients can confirm that the new software is so much better than the old. Not technical, but most importantly more adapted to their daily work.
That’s what’s important.
From large to small, from projects to issues, a team needs to define when they are considered done.
This decision differs from team to team, some have steps to done, others just one state. Even the words used in your issue tracker reflect your choices: what does ‘fixed’ mean, what is ‘closed’ used for…
Even some practices like test driven development define a state of done: the code is done if all tests are green and it is refactored.
What’s your definition of done?
Let’s take a look at some examples:
- tests are green and code is refactored
- QA says ok
- customer/stakeholder/product owner accepts the issue
- developer thinks the code reflects the description in the issue
- a predefined spec, maybe even with an acceptance test, is fulfilled
- no bugs were found while clicking through
- the code is merged with the master branch
- the continuous integration tool has found no errors
The problem with this ‘definition of done’s is that either they look for an external person to accept by their opinion/guideline or concentrate on some output. But the people needing the software do not want the software in its own regard. They want to reach a goal through the software. The software is a mean to an end: their goals. Without defining the goals and needs beforehand you are either doomed to guess them and are at the mercy of arbitariness (from your point of view) or concentrate on some measurable output like code, tests or a completed feature.
Defining what the user wants to do with this new feature or project should be the first thing in a project right after the initial introductions. Who will use the app or the feature? (the intended audience, the users) What do they expect from it? (the benefits) What goal do they want to reach?
With this questions and answers you have a target. After completing the issues or project you can see if the target has been reached, if the goals are met. It might be the same with an acceptance process from a stakeholder but here you know the target beforehand not after.
Reminder: What are personas ?
Personas were first described by Alan Cooper in his ground breaking book “The inmates are running the asylum”:
Our most effective tool is profoundly simple: Develop a precise description of our user and what he wishes to accomplish.
He goes on to define personas as “hypothetical archetypes of actual users” and states that personas “are defined by their goals”.
One of the key points here is that personas are never made up but are grounded in research. They are used to provide condensed information about the result of the user research. Another take away is that a persona description should include its goals.
In recent times some designers dumped personas because they are 1) imaginary and 2) defined by attributes that leave out causality. The problem here is that personas are often seen as a collection of mere demographic data (like age, job, income, …). But this only describes marketing personas not the personas imagined by Alan Cooper. As seen in his books the data of a persona is never made up but inferred from user research. Also demographics play only a minor role in creating personas, citing Mr. Cooper again:
Personas are segmented along ranges of user behaviour, not demographics or buying behaviour.
So the behaviour of our users defines the persona not any demographic trait.
The causality mentioned in the criticism misses a vital part of a persona: the scenario. Personas go hand-in-hand with scenarios (by Alan Cooper, About Face):
Persona-based scenarios are concise narrative descriptions of one or more personas using a product or service to achieve specific goals.
Scenario content and context are derived from information gathered during the Research phase and analyzed during the Modeling phase
So with these scenarios personas describe the context and the goals and behaviours of our users.
As we see with the criticism the context, goals and motivations of our users are important. Personas and scenarios should not be made up but condensed from research. They are used to say ‘no’ to decisions in the process of designing. A word of warning: do not abstract your persona too far away from your users. One goal of personas are to built empathy. If your personas are too artificial your empathy will suffer. Also I like how Jeff Patton uses research findings: for him they are like vacation photos, if you’ve been there they are reminder what happened.
The criticism largely comes from designers favoring the jobs-to-be-done (JTBD) methodology. Jobs-to-be-done is a framework to analyse and describe why a users hires a product or service to get something done. It provides a very useful perspective on the context and behaviour of users. Both approaches (personas and jobs) can be combined. Where personas provide a human connection, jobs provide a contextual one. Shahrzad Samadzadeh provides a sketch how both can be combined with the help of a journey map. All three methods help to balance each approach: the personas help to avoid making the jobs too analytic, the jobs help to ground and limit the personas in research valuable to the problem at hand and journeys can bring all together.
One of the most important things to understand before starting any design or development is the user’s workflow(s). A user uses your app to reach a goal. His starting point is the start of the workflow. His goal its end. He takes steps in order to get from the start to his goal.
The order and the type of steps he takes helps us to understand how he reaches his goals at the moment. Visualizing these steps, often called mapping, is a great way to see the system from the user’s perspective: what does he do with the system, how and when does he do it.
This workflow helps us to keep the big picture in mind and organise planning and execution around the important part of the project: the user goals.
How does a workflow look?
Use the visualization or tool that suits you most. A workflow can be a sketch of boxes and arrows. Or an excel sheet. You can use a diagramming software or a presentation software. The important point is that you see the start, the goals and the steps and can annotate each step with important details.
How can we create the workflow
A workflow describes a series of actions. When the system supports the user to get from his start to his goal our application does its job. The user experience is how efficient and pleasant it is for the user to take each step.
One way to find out about the steps the user takes is to observe him doing so. At first: try to only watch and listen. Take notes. Be open. Record each step as if you were a beginner knowing nothing about the system or how the software works or should work. Especially watch out for the struggles.
Struggles can be seen in:
- back steps
- changing applications
- repeated steps
The struggles give us a hint where to put our energy. In the second run keep an eye open for unusual steps. Unusual steps are actions which seem complicated or unnecessary from a beginner’s mind. Start with the notion that every step is needed but find out the reasons why it is. In subsequent observations look for variations and ask what information lead the user to decide differently this time.
Armed with your recordings you can now sketch the first version of what you understood about how the user reaches his goal using the current systems.
In the past sales has often been disregarded. But modern sales is more like UX. The goal of modern sales is to bring a positive impact to both the seller and the buyer. This is called a win-win. Both parties win.
Shortcuts or favors result in one party losing which is not a sustainable strategy.
For the buying to be winning a seller has to care about the needs of the buyer. These needs range from jobs to be done to personal ones. As a seller you employ UX research methods like interviews and open questions targeting the thoughts and feelings of the buyer. The wins are always personal never something abstract like a company strategy or even KPIs. But: the wins are based upon result: measurable, objective things like conversion rates, efficiency improvements, closed sales. Together they are called win-results: an objective metric that has a personal benefit for the buyer.
Assumptions in UX can be dangerous and can doom a whole product. Assuming win-results or the wrong needs you can miss the buyer completely and lose the sale. In strategic sales every uncertain or missing information or contact is regarded as a red flag. UX should also mark its blind spots. The product kata is a great way to eliminate assumptions in a project.
But even if you know the needs you have to take into account the context. The personal and emotional situation a buyer is in has direct consequences for how you need to address him. The same with UX where context and the job to be done control your solutions – what works and what not.
If you are interested in a more person centered sales strategy I recommend reading strategic selling and following blogs like Seth Godin and Bernadette Jiwa