UX makes happy
Let’s make your business happy by making the customer happy. To do this we need to understand, model, create and test:
Here we discover what the world is really like. To do this, we collect qualitative and quantitative data via surveys (online and offline), field research (online and offline), and also the analysis of existing data such as webtracking.
If we already have a hypothesis about how the world really is, then we discover new things by testing these hypotheses. To do this, we need to formulate the hypotheses in such a way that they involve measurable change. For example: If we name the button differently in step 3, we will have significantly fewer dropouts at this point.
Here you can test first and then deliver, or deliver and then measure.
Discovery is not something that only happens at the beginning. A “discovery track” is an integral part of development and should happen continuously.
Stories are our way of understanding the world. The fabric of if –> then, motivation, conflict, and resolution helps us generate knowledge from a set of data.
Personas, user journeys, and scenarios are helpful tools that are especially powerful in this context.
A persona describes the dramatis personae, their inner necessities and perhaps also external constraints, which result from this persona and are not general. The important aspects are those that are relevant for the subsequent action in the user journey.
The drama that results from the encounter of the person(a) and their desires born of inner necessity with reality dictates the arc of the entire story that is being traversed: the User Journey. As with any drama, it is important to delineate this journey. That is, to consider exactly what part of our person(a)’s life we are looking at.
The most important part is when we get to the scenario. Because that describes the actual point of contact with what we want to build: the detailed interaction in one step of the persona’s journey.
Let’s take an example: we are asked to develop a new ticket vending machine. Whatever the persona we imagine – old or young, in a hurry or with time to spare, tech-savvy or not – we first have to realise that this persona doesn’t want to buy a ticket at all.
Rather, the persona wants to use a means of transport out of an intrinsic motivation to get to a destination. The relevant journey for us therefore begins with the formulation of the destination and ends with the arrival.
The task of building a new ticket vending machine defines our scenario as the event of purchase. The many little dramas that can happen here – the incomprehensible honeycomb map, the unclear destination selection, the confusing different fare offers, concerns about hygiene at a public vending machine, or simply the sun making the display unreadable – are to be identified, prioritised and provided with solutions.
And a solution can then also be to propose a contactless prepaid solution like the OV-chipcaard in the Netherlands instead of a ticket vending machine.
Some designs need to be created quickly so that they can be agreed upon quickly: with pen and paper, together on a board (virtual or together in a room) or even with software such as Axure or Balsamiq, which allow quick “quick & dirty” visualizations of ideas.
Designs that are more design and less just idea are created with more time. They communicate, specify and document more accurately the desired end product.
These can be wireframes that draw an exact picture of the screens with Sketch, for example, or stronger functional documentation, as with Axure.
These can be user stories, specifications and functional descriptions.
This works especially well if there is already a design system that defines basic and pre-existing solutions. So there is no need to talk about colors, buttons and typography every time, but there are ready-made components that can be put together according to a modular principle and added to as needed.
Here, too, reusability ensures sustainable work.
Test, test, test! This brings us back to discovery at the beginning.
In terms of UX, too, testing must take place in a systematic manner and always be geared to the result. Only if we know what we want to achieve with the user can we also make this change measurable and test its occurrence.
Testing before launch prevents unpleasant surprises.
But also the constant collection of feedback after the launch helps to control and prioritize the backlog for the future.
Often, this feedback is found virtually on your own doorstep, with customer service representatives or, for example, in the reviews in app stores.