Mapping the user’s workflow

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:

  • mistakes
  • back steps
  • pauses
  • 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.

What UX and sales have in common

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

Discount UX

Creating a better user experience does not need to be expensive, you don’t need fancy tools like eye tracking or facial expression detection to make a difference. Here are some tools I use to get a better understanding of what users need.

Sketching

The universal tool to communicate besides words are sketches. Whether I draw an idea for a user interface, use a state diagram to discuss transitions or draw boxes and arrows to show connections, sketches at the heart of everyday working and thinking. What you need for this? Paper and a pencil.

Observation

In order to understand a human using your system you not only need to talk to him but you have to observe him doing his work. This is not just playing the fly on the wall. These sessions are interactive in nature, resulting in a back and forth. The user shows you how he works, you ask questions, he goes into more detail, you wonder about certain points, he explain his reasoning (or sometimes has wonders himself). Again paper and pencil is great. Having the option to take screenshots or (permission provided) a photo is even better. The most crucial is an open mind. You need to go in with a beginner’s mind: do not assume anything and wonder about almost everything.

Card sort

Observation is a pretty direct way to learn about the user doing his work. But even then some part of the mental model is hidden. To dig deeper into what kind of concepts and words he uses and how these are interrelated, a card sorting session can be helpful. Together with him we draw those words onto cards and let him sort them into groups and give them priorities. Here often discussions arise about the exact words you write on the paper. Some words need to be in more than one group, two different words mean the same, another word means something different in a different context. Here you also can take a glimpse at (sub-)domain bounds. Again cards, a pencil and paper to take notes is all you need.

Design studio or crazy 8

Sketching is so helpful you can do it even in a group. If you need to brainstorm for a user interface you take a sheet of paper and divide into 8 sections. Then you draw 8 very simple sketchy version of the UI in 8 – 16 minutes. After that you evaluate them in the group against your goals. The first round produces divergent sketches after seeing each other drawings, you will see that the next round converges into a common direction. You probably guessed it already: paper and a pencil is all you need.

Paper Journey Mapping

The last one in this group is more of an analyzing and communicating results tool. A journey map is a way to show the user (his thoughts, feelings and actions) along the steps he takes in his daily work. This map can highlight different aspects of your findings: the many applications he has to use to get his job done, the critical parts which mostly affect his mood, the frustrations, the many points for failure, the different people involved and so on. A large (DIN A3 or bigger) piece of paper is helpful and different colors of pencils help to highlight aspects.

Summary

All these methods use (almost only) pen and paper but are very helpful in getting to a better user understanding and therefore a better user experience. What are your tools for understanding?
If you have any questions or need more details please feel free to comment. I am at the starting point of the user experience journey and like to learn from others.

Getting better at programming without coding

Almost two decades ago one of the programming books was published that had a big impact on my thinking as a software engineer: the pragmatic programmer. Most of the tips and practices are still fundamental to my work. If you haven’t read it, give it a try.
Over the years I refined some practices and began to get a renewed focus on additional topics. One of the most important topics of the original tips and of my profession is to care and think about my craft.
In this post I collected a list of tips and practices which helped and still help me in my daily work.

Think about production

Since I develop software to be used, thinking early about the production environment is key.

Deploy as early as possible
Deployment should be a non event. Create an automatic deployment process to keep it that way and deploy as early as possible to remove the risk from unpleasant surprises.

Master should always be deployable
Whether you use master or another branch, you need a branch which could always be deployed without risk.

Self containment
Package (as many as possible of) your dependencies into your deployment. Keep the surprises of missing repositories or dependencies to a minimum of none.

Use real data in development
Real data has characteristics, gaps and inconsistencies you cannot imagine. During development use real data to experience problems before they get into production.

No data loss
Deploying should not result in a loss of data. Your application should shutdown gracefully. Often deployment deletes the directory or uses a fresh place. No files or state in memory should be used as persistence by the application. Applications should be stateless processes.

Rollback
If anything goes wrong or the new deployed application has a serious bug you need to revert it to the last version. Make rollback a requirement.

No user interruption
Users work with your application. Even if they do not lose data or their current work when you deploy, they do not like surprises.

Separate one off tasks
Software should be running and available to the user. Do not delay startup with one off admin tasks like migration, cache warm-up or search index creation. Make your application start in seconds.

Manage your runs
Problems, performance degradation and bugs should be visible. Monitor your key metrics, log important things and detect problems in the application’s data. Make it easy to combine, search and graph your recordings.

Make it easy to reproduce
When a bug occurs or your user has a problem, you need to follow the steps how the system arrived at its current state. Store their actions so that they can be easily replayed.

Think about users

Software is used by people. In order to craft successful applications I have to consider what these people need.

No requirements, just jobs
Users use the software to get stuff done. Features and requirements confuse solutions with problems. Understand in what situation the user is and what he needs to get to his goal. This is the job you need to support.

Work with the user
In order to help the user with your software I need to relate to his situation. Observing, listening, talking to and working along him helps you see his struggles and where software can help.

Speak their language
Users think and speak in their domain. Not in the domain of software. When you want to help them, you and the user interface of your software needs to speak like a user, not like a software.

Value does not come from effort
The most important things your software does are not the ones which need the most effort. Your users value things which help them the most. Find these.

Think about modeling

A model is at the core of your software. Every system has a state. How you divide and manage this state is crucial to evolving and understanding your creation.

Use the language of the domain
In your core you model concepts from the user’s domain. Name them accordingly and reasoning about them and with the users is easier.

Everything has one purpose
Divide your model by the purpose of its parts.

Separate read from write
You won’t get the model right from the start. It is easier to evolve the model if read and write operations have their own model. You can even have different read models for different use cases. (see also CQRS and Turning the database inside out)

Different parts evolve at different speeds
Not all parts of a model are equal. Some stand still, some change frequently. Some are specified, about some others you learn step by step. Some need to be constant, some need to be experimented with. Separating parts by its changing speed will help you deal with change.

Favor immutability
State is hard. State is needed. Isolating state helps you understand a running system. Isolating state helps you remove coupling.

Keep it small
Reasoning about a large system is complicated. Keep effects at bay and models small. Separating and isolating things gives you a chance to overview the whole system.

Think about approaches

Getting to all this is a journey.

When thinking use all three dimensions
Constraining yourself to a computer screen for thinking deprives you of one of your best thinking tools: spatial reasoning. Use whiteboards, walls, paper and more to remove the boundaries from your thoughts.

Crazy 8
Usually you think in your old ways. Getting out of your (mental) box is not easy. Crazy 8 is a method to create 8 solutions (sketches for UI) in a very short time frame.

Suspend judgement
As a programmer you are fast to assess proposals and solutions. Don’t do that. Learn to suspend your judgement. Some good ideas are not so obvious, you will kill them with your judgement.

Get out
Thinking long and hard about a problem can put you into blindfold mode. After stating the problem, get out. Take a walk. Do not actively think or talk about the problem. This simulates the “shower effect”: getting the best ideas when you do not actively think about the problem.

Assume nothing
Assumptions bear risks. They can make your project fail. Approach your project with what is certain. Choose your direction to explore and find your assumptions. Each assumption is an obstacle, an question that needs an answer. Ask your users. Design hypotheses and experiments to proof them. (see From agile to UX for a detailed approach)

Pre-mortem
Another way to find blind spots in your thinking is to frame for failure. Construct a scenario in which your project is failed. Then reason about what made it fail. Where are your biggest risks? (see How to map your fears for details)

MVA – Minimum, valuable action
Every step, every experiment should be as lightweight as possible. Do not craft a beautiful prototype if a sketch would suffice. Choose the most efficient method to get further to your goal.

Put it into a time box
When you need to experiment, constrain it. Define a time in which you want to have an answer. You do not need to go the whole way to get an impression.

From Agile to UX: a change in perspective

Usually a project starts with a client sending us a list of requirements in varying levels of detail. In my early days I started with finding the most efficient way to fulfill these requirements with written software.

Over time and with increased experience I broke down the large requirements into smaller ones. With every step I tried to get feedback from the client if my solution matched his imagination.

Step by step I refined this iterative process by developing more efficiently, getting earlier feedback, testing and asking questions for more detail about the constraints of the solution. Sometimes I identified some parts that weren’t needed in the solution.

In the journey to getting more agile I even re-framed the initial question from ‘how can I get more efficiently to a satisfying solution’ to ‘which minimal solution brings the most value to the customer’.

This was the first change of perspective from the process of solving to a process of value. But a problem still persisted: the solution was based on my assumptions of what I believe that brings value to the customer.
The only feedback I would get was that the customer accepted the solution or stated some improvements. But for this feedback I had to implement the whole solution in software.

The clash of worlds: agile and UX

Diving into the UX and product management world my view of software development is questioned at its foundation. Agile software development and development projects in general start with a fatal assumption: the goal is to bring value through software that fulfills the requirements. But value is not created by software or by satisfying any requirements. For the user value is created by helping him getting his jobs done, helping him solving his problems in his context.

This might sound harsh but software is not an end in itself but rather one way to help users achieve their goals.
On top of that requirements lack the reasons why the user needs them (which jobs they help the user do) and in which situation the user might need them (the context).
In order to account this I need to change my focus away from defining the solution (the requirements) to exploring the users, their problems and their context.

The problem with finding problems

As a software developer I am skilled in finding solutions. Because of this I have some difficulties in finding the problems without proposing (even subconsciously) a solution right away. If you are like me while talking with a client or user I tend to imagine the possible solutions in my head. On top of that missing details that are filled by my experience or my assumptions. The problem is that assumptions are difficult to spot. One way is to look at the language. A repeatable way is to use a process for finding them.

The product kata

Recently I stumbled upon an excellent blog post by Melissa Perri, a product manager and UX designer. In this post she describes a way named ‘the product kata’.

The product kata starts with defining the direction: the problem, job or task I want to address.
After a listening tour with the different stakeholders (including clients and users), the requirements list and a contextual observation of the current solution I can at least give a rough description of the problem.

These steps help me to get a basic understanding of the domain and the current situation. In my old way of doing things I would now rush towards the solution. I would identify the next step(s) bearing the most value for the client and along the way remove the shortcomings of the current solution. But wait. The product kata proposes a different way.

A different way

Let’s use an example from a real project. Say the client needs a way to check incoming values measured by some sensors. The old solution plots these values over time in a chart. It lacks important contextual information, has no notion of what ‘checking the values’ mean and therefore cannot document the check result. Since the process of checking the values is central to the business we need to put it first and foremost. Following the product kata I define the direction as ‘check the sensor values’.

Direction: check the sensor values

To see if I reached the goal the kata needs a target condition which I define as ‘the user should be able to check the sensor values and record the check result’.

Target condition: the user should be able to check the sensor values and record the check result

Currently the user isn’t able to check anything. So the next step of the kata is to look at the current condition. If the current condition matches the target condition I am done. The current condition in my example is that the user cannot check the sensor values in the right way.

Current condition: the user cannot check the values in the right way

The first obstacle to achieving the target condition is that I don’t know what the right way is. Since the old solution lacks some important information to fulfill the check my first obstacle I want to address is to find out what information does the user need.

Obstacle: what additional information (besides the values themselves) does the user need

Since the product kata originates from lean product management I need to find an efficient step which addresses this obstacle. In my case I choose to make a simple paper sketch of a chart and interview the user about which data they needed in the past.

Step: paper sketch of chart (to frame the discussion) and interview about information needed in the past

I expect to collect a list with all the information needed.

Expected: a list of past data sources which helped the user in his check process

After doing this I learned what information should be displayed and which information (from the old solution) was not needed in the past.

Learned: two list of things: what was needed, what not

Now I repeat the kata from the start. The current condition still not matches the target condition. My next obstacle is that we do not know from the vast resources of information that is needed and the possible actions during the check which are related, form a group or are the most important ones. So my next step is to do a card sort with the users to take a peek into their mental model. I expect to find out about the priorities and grouping of the possible information and actions.

After I gathered and condensed the information from the card sorts, my next obstacle is to find out more about the journey of the user during the check and the struggles he has. From my earlier contextual observation I have the current user journey and the struggles along the way. Armed with the insights from the earlier steps I can now create a design which maps the user journey and addresses the struggles with the data and the actions according to the mental model of the user.
For this I develop a (prototypical) implementation in software and test them with a group of users. I expect to verify or find problems regarding the match of the mental model of the user and my solution.
This process of the product kata is repeated until the current condition meets the target condition.

Why this is needed

What changed for me is that I do not rush towards solving the problem but first build a solid understanding by learning more about the users, their jobs and contexts in a directed way. The product kata helps me to frame my thoughts towards the users and away from the solution and my assumptions about it. It helps me structure my discovery process and the progress of the project.
My old way started from requirements and old solutions improving what was done before. The problem with this approach is that assumptions and decisions that were made in the past are not questioned. The old way of doing things may be an inspiration but it is not a good starting point.
Requirements by the client are predefined solutions: they frame the solution space. If the client is a very good project manager this might work but if I am responsible for leading the project this can lead to a disaster.
The agile way of developing software is great at executing. But without guidance and a way of learning about the users and their problems, agile software development is lost.

What I’ve learned in UX in the first half of 2016

Since the beginning of the year we as a team of developers started meeting 1-2 times a month talking about UX design. Urged with a motivation to create better software for our clients and serve them better I started the conversation inside our company. Years ago I read classics like Alan Cooper’s The Inmates and Don Norman’s The Psychology of Everyday Things. They left me with a craving to create something more fitting for users but I had no place where to start. At the turn of the year I focused on learning as much as I can about UX, product design and design in general. Here’s my list of insights I gained in these 6 months (in no particular order):

  • doing UX means changing the culture and mindset of the whole company from technology to people
  • nothing beats exposure to real users in their contexts (source)
  • contextual observation and interviews are key and the most profitable and motivating method to find out more about your users
  • analytics and data can tell you more about what user do, interviews why are they doing it
  • in the enterprise context where we are it is sometimes difficult if not impossible to gain access to users
  • some methods from UX feel a bit squishy and the value of doing them not apparent
  • traditional (UX) designers have a hard time talking about the value of UX for the business
  • the definition of UX is all including at best and inconsistent at worst, but it doesn’t really matter to me as I want to improve the software we write regardless of what it is called or which responsibility it is
  • in order to craft a better user experience our development process has to change drastically
  • the creative method (observe, reflect, make) is a way to order my concepts about UX
  • users behave differently in different situations, the better way to capture that is jobs to be done not persona
  • the UI layer is where experiments are made, therefore it should be changed more easily than other parts
  • assumptions are very dangerous, trying to validate or falsify them
  • you have to live with assumptions, know their risk
  • conversations are the way to spread knowledge, not documentation and not presentations
  • let users or stakeholders talk, do not complete thoughts for them, get comfortable with silence
  • the user has a whole different view of your UI than you
  • I have to learn to suspend judgement
  • ask why but not endlessly
  • the struggling moments of your users are the best points to start for a better solution
  • understand the problem, the context and the user’s motivations better
  • requirements are liars
  • use whiteboards more, they help me to think spatially
  • if you cannot argue for a design, the client overruns you with his taste
  • think in systems, systems of people and design systems
  • small usability improvements are easy and therefore we often tend to flock to them
  • conversations with people are hard therefore we tend to avoid asking the hard and important questions

In future posts I will write in more detail about each of the points.

Requirements should not drive development

For more than a decade I develop software for engineers. The software they use is coined by vendor lock-ins, terrible interfaces and dowdy technology. In the last years I am struggling to find a better way to make tools that help them to get their jobs done. In a more pleasant and efficient way. My journey started with trying to make the internal quality of the software better through practices like clean code, TDD and the like. Maybe the software got more robust but the benefit on the user side of things was negligible.
So I turned to learning user experience design (UX). A vast land of new unknown concepts, theories and practices lays before me. So big that even practitioners in the field cannot agree what UX is.
The label isn’t important to me.

I want to make the work of engineers better.

To make the work better I have to learn more about the people and the work. The importance of domain knowledge is undisputed in the software development world. And collaboration is a pillar of modern software projects. But after reading and practicing several methods to uncover information about people and their work (read: user research) I found the traditional way of communicating inside a software project lacking.
Normally a software project starts with gathering requirements. Requirements describe what the software should do in an abstract way. For example: the software should calculate the balance of the user’s bank account. How did we found out that this is a requirement? We interviewed a stakeholder.
At first sight this might sound reasonable. Looking closer we find many problems with this approach.
First in the context of enterprise software where I work the user and the stakeholder are often different people. Even more alarming is that we talk about the wants of the solution. We have no indicator what problems does this requirement try to solve. Without knowing what we want to solve we are doomed. We are imaging an illusion.
Now even if the one who made all research and wrote the requirements knows the problems he wants the software to address the requirement is a very poor communicator. We need to spread the knowledge about the problems throughout the team. The agile approach to include roles (as a), actions (I want to) and outcomes (so that) in so called user stories is not much help.
In order to know what properties a solution must have we need to understand the user and his work. For this we need to see his context, the situation he is in. In different situations he might want to do different things. So we need to capture his motivation and of course his goals.

Jobs to be done – job stories

In the search for a better way to communicate what we find out during research I stumbled across the jobs to be done methodology. Coming originally from marketing several teams adapted this way of thinking to product development. I think Paul Adams mentioned and Alan Klement developed the idea of the job story and several others have had a great success implementing it.
What’s in a job story? A job story take the form: When (situation), I want to (motivation), so I can (expected outcome).
Now the first part captures one of the most important concepts of UX: the context.

The situation

Context is so much more than I naively imagined: it is not location and surroundings. Context or better the situation is what happened before in the environment, in the system and for the user. Developers might call it the state of these. For example: When I am about to buy a car, when I start a measurement, when I am leading the race, when my application crashed, …
The situation and what happened just before is crucial to get a sense of what the user is struggling with.

The motivation

The user wants to move from the current situation to his goal. Why? And what is important for him? What might hinder him to do so? The jobs to be done framework calls this forces. We have 4 forces:

  • push of the current situation: what is bad now
  • pull of the future: what is good then
  • habits: business as usual might hinder progress
  • anxiety: the fear of the new might bring hesitation

These forces help us to document needs of the user in the current situation. If we want to better support the user we need to care about him as a person, not just as a machine going from one state to the next. Forces help us to communicate needs. Again a property the current solutions of documenting requirements lack.

The outcome

What benefit does the user get from his actions? He has a goal. We need to know his goals in his current situation to help him get there. Beware: this is not just a feature of the system, it is an understanding the user gets, an accomplishment, a symbol of status. The benefit is the value the user gets.

Conclusion

Describing situations in which people struggle to get to the wanted outcomes and goals helps us relating to them. It helps us documenting findings and communicate them to other team members. When evaluating different solutions we can lean on the job stories to determine if they fit. Requirements and user stories are just too solution focused and miss important details to drive any software development effort which wants to help people doing a better job.