I often get asked “what is UX”. Even more often I get asked “why did you leave medicine? Don’t you miss the patients?”

Funnily enough, the answers to both questions are linked. So keep reading to find out more!

UX, short for User Experience is a term which is general used interchangeably with usability. Often, UX is thought of as a means to make something look nice for users.

This is just half the story however as you can have a wonderful idea of a design which looks fabulous, but in practice it leads to frustrations, confusion, and mistakes. To prevent the last three, a UX specialist needs to also consider the usability of product.

As explained to me by Dr Raymond Bond, a good user experience could be described as someone driving up a winding road on a mountain side. The view can be beautiful, but such a road would have bad usability since usually it wouldn’t have any tarmac, poor signal to check Google Maps for directions crashing would likely lead to death! A busy dual carriage way can have good usability because of the clear markings and signs (most of the time!), but the experience for the driver is normally rather dull.

Therefore having good UX is about optimising the experience a user has with a very usable product.

A UX specialist aims to achieve this by answering the what, who, when, why and how questions during the product development lifecycle. The main philosophy to facilitate this is User Centred Designed (USD), which advocates keeping the user at the centre of everything an individual, team or organisation does. This is where I appreciate that I’m well placed as a medical doctor to be a UX specialist, since Patient Centred Care is USD with the the user being the patient.

I try to tackle UX problems the way I would diagnose and treat a patient who come to be me with a health problem. Lets go through the steps and observe the uncanny similarities between diagnosing a patient and designing for a user.

Step One – What does the client want?

First, its important to identify what needs to be worked on. For a patient, this tends to be the main symptom they complain about, commonly know as the presenting complaint. But in UX, rather than it being a complaint, it is rather the initial request an individual or business has, such as a website for a fairly specific target audience. Notice that there isn’t much detail at the beginning, and that’s fine as long as you realise that its your responsibility to get the extra detail. For doctors, we will then take a detailed history, and a similar thing is done by UX practitioners who are trying to understand the strategy of the request, as well as the needs and restrictions on design.

Step Two – What does the user want?

Armed with a better understanding of what is wanted from the requester, its time to get a better idea of what the user themselves would want. To build on the history taken from patient, a doctor would then carry out an examination and some investigations. Instead, UXers conduct user research to collect both quantitative and quantitative data. Its the analysis of this data which helps a UXer come up with a large number of designs via an iterative design process, which basically means designing with persistent stakeholder and user engagement, allowing the design to change as you get a better idea of what the best idea will be. Its important to think big and outside of the box as you never know, the best idea could come from an initially poor one. The same goes with doctors coming up with a differential diagnosis after reviewing their examination and investigation findings in light of the history. The first diagnosis might be right, but when you are a junior, you often lack the experienced needed to confidently go with the first diagnosis. The iterative design process involves lads of sketching, preferably on post-it notes where the content can be put on a wall. This is particularly useful when you want to group or order the content on the post-it notes. A high fidelity prototype, which is a high resolution or simulation of the design, is very useful here as well once you have a better idea of the final design and can be used for testing.

Step three – offer a solution

The next stage involves getting the final design created. This would be considered the treatment for a doctor, but for the UX designer, this would be development. Rarely UX designers do all the coding themselves, and so will have to communicate their design in a way that a developer can understand. A high fidelity prototype can give most of the information, but writing user stories and acceptance criteria can make it even clearer. User stories are high level, short statements which explain a feature, where as acceptance criteria give low level detail on how the feature actually works/performs. For example, you want the developer to create an guestbook for a website. The user story could be “As a user, I want a guestbook so that I can record my experience with the website”. It follow the simple format of “As a [specify user] I want [specify feature] so that [specify reason]”. The acceptance criteria is a little more long winded.

GIVEN that I am on the guestbook page
AND I click the Name textfield
AND I type my name
AND I click the Comment field
AND I type a comment
WHEN I click the Submit button
THEN my name and comment is saved in the database

Acceptance criteria always start with GIVEN, and before you can have a THEN statement, you must proceed it with a WHEN. AND is pretty self explanatory; use it when you need an additional action. It can get more complicated than this, but generally speaking this should be enough to create test plans which can be used for testing. Never underestimate the power of testing!

Step four – check your solution is right

There is technical testing which looks at errors in what has been produced and should be done by the development team with the support of a tester. This realise on the development being completed rather than a work in progress otherwise you will be find fault with something that is still a work in progress, which makes no sense. There is also usability testing which is when users go through the developed solution and identify issues that effects them. Its always best to do a technical test before a usability test so you don’t have to keep telling a user to not worry about a particular issue which you know is going to get fixed anyway. It wastes time and can skew your results if you are trying to find out how enjoyable the experience of using your solution is since there user is focusing on none issues.

Step five – realise the end product

The final step would be a check up or evaluation of the success of the “diagnosis”. Based on feedback from the all your testing, you then make changes to your solution as necessary. But you should have the freedom to visit any stage of the UX and development process to ensure that what is released is the best user centred designed solution possible!

Hopefully that all makes sense! If you want to find out more feel free to get in touch.