In medicine, we follow a very specific process to collect, document and share all the information we can from patients. This information is then used to come to a diagnosis and formulate a plan to treat or manage the patient. We call this process clerking (pronounced clarking, and no-one seems to know why!)
I use a very similar method to clerking as a Clinical UX Designer, when I “diagnose” UX design problems.
Here, I share my methodology which I use whenever I’m working on a UX project. I have yet to test this, but I would estimate a good 80% of all the information you will need to start working on the iterative design process will come from completing the first two sections, with the additional sections giving you more information as you go on. You may also notice a hidden message, which I’ll explain at the very end.
Are you ready? Here we go!
Presenting Problem (PP)
This is the problem or request that the client comes with. The amount of detail presented can be rather variable. Examples include “I want more customers on my website” or “I require a high fidelity prototype to demonstrate my app to investors”. There will always be more questions to ask though, hence the next section.
History of Presenting Problem (HPP)
Here we gain context of the problem. There are quite a few questions that need to be asked here. To make it easier to remember, I use an acronym
This stands Team, Vision, Needs, Obstacles/risks, Measures of success,Assumptions/expectations and Deadline.
Let’s have a look at this one by one
Team; It is always good to get to know the team before getting any work done, so you can quickly identify the most influential people on the project and start building healthy working relationships. You want to develop a good rapport with everyone, but there is no point presenting your ideas to the most junior member of staff as they probably have little to no power. So find out who is in the team and identify preferred names, roles and responsibilities. When you know who is the project manager, make sure you also find out what their budget is. Also, how do they work? Waterfall, agile, 9-5 Mon-Fri, 24/7, etc? And finally, how do they communicate with each other? Emails, MS Project giant glass walls?
Vision: Here, you will find out the dream and ambition of the project. You can learn a lot about moral levels as well as business and project maturity by simply asking “What is your vision?” Unless whoever you are talking to are Oscar worthy actors, they will show on their face how excited (or not) they are about the vision. If you can pick and choose your work, you will certainly rather work on an exciting than boring project.
Needs: There will be a lot of needs to consider, whether the client knows this or not. This is especially true if the client doesn’t know it’s customers/users very well for whatever reason. First off ask about the client’s needs, not just of the project, but of their business. For example, when they ask for a mobile app so their customers can use their online shop better on their phone, a need may be that it can have loads of adverts in it to help increase revenue. You will then want to know about the needs of the users, which don’t always match up with needs of the client. An example following on from last one would be that users want the adverts to be turned off. Don’t worry about conflicting needs at this stage, just focus on getting all the needs for now.
Obstacles/risks: No project is obstacle or risk free. Have you ever worked on a project where the most senior person on the team has virtually no amount of creativity or visual designs skills? They become an obstacle if they also want to dictate how the design should look rather than let the experts get on with their work. You need to know what these are from the get go so you can plan how to tackle them before they become a problem.
Measures of success and failure; This one is rather self explanatory; what do you have to measure to know whether the project is a success or failure. The “failure” bit is important as if you don’t know what failure looks like, you could be blindly wasting time, money or opportunities in the pursuit of success. Consider the situation of redesigning a website. A measure of success could be that traffic to the site is increased by 100%. A measure of failure however is that out of the 100%, only 10% or less become customers.
Assumptions/expectations; Generally speaking, there is nothing wrong with a few assumptions or expectations. Even crazy outlandish ones. Let me explain. You could be working with a small start up who believe that their first mobile app will earn them £1 Billion in year one. Now, this is crazy and outlandish, but if this is what they believe, you will need to bring them back down to earth, gently. Understand their assumptions and expectations so that you can give them a realistic understanding of how things will pan out, such as why making a wristwatch that tells the time through smell is not going to earn them loads of money.
Deadline; This one may get picked up in the previous line of questioning, but if it hasn’t, make sure it gets asked. Deadlines are so important! It lets you know how long you have to achieve the various tasks which leads to a successful project.
Past Project History (PPHx)
Have they tried to do this project before? If so, what went well, and no so well. What lessons were learned? Is there any documentation?
Brand history (BHx)
Understanding the brand is really important, as it will give you insight into where the brand has been and where it is planned to be in the future. There should be brand guidelines to be used on certain project which outline how the brand should look visually on products or advertising, including colours, fonts and the use of images. It is also worth discovering the brand’s products and/or services, especially if there many products and services, including those from other brands, which must compliment or be differentiated from another brand’s product or service. A great example is creating an mobile gaming app which must work on an iOs, Android or Windows phone. The visuals and the technologies will differ for the different platforms.
Digital history (DHx)
This section covers the client’s digital infrastructure. This would include websites, social networks, online marketing, etc. There may be no digital infrastructure at all, it could be extremely well developed and well known, or anything in between. Let’s say your client is a young start up and only has a WordPress site and they want to now start selling products online. Developing the WordPress site with an eCommerce plugin would be a quick, easy and low cost solution that doesn’t have to be a radical change to what they have now.
Technology history (THx)
Here you find out more about what is in place to create, manage or interact with the digital infrastructure, such as the computers,mobile devices and software. Again, this could be some very well developed technology, or virtually nothing, and the current project will need to work in this space.
By this stage there will be a lot of foundation knowledge which allows you to collect some more information from other sources, propelling you closer to the final solution. Research is a very broad topic and is out of scope for this article, however it will include the following areas
- User research: get to know the target population and the limiting users, ie the users who could have the most complex of needs that must be satisfied in order for the product to be useful for as many people as possible. This is where personas come in handy; fictional representations of real members of the target population.
- Competitor analysis; there may not actually be any competitors, but if there are, you will want to know what they are doing, and make sure you are not inferior to their solutions, especially if the market you are working in is really crowded.
- Standards: Even if you are inventing something, there will be some norms that users will be expecting. Deviate from these too much and you may have a huge number of users against your solution. However, there is always the chance that you create a new standard that everyone else follows. If so, well done!
- Everything else; it is a simple fact, there will be unknown unknowns. This includes information that you learn in an opportunistic way. If you never discover them, then fine. If you do find some, you may well get insight that will radically improve the quality of your final solution. To increase your chances of learning something to fit in this category, you have to fully immerse yourself in what you are doing and take advantage of all opportunities to learn.
Differential Solution (DS)
With plenty of information at your disposal, you will then develop your final design solution. This is where all the prototyping comes in handy and the whole iterative design process. However, just as there is allegedly more than one way to skin a cat, there may be a variety of solutions to the Presenting Problem. You may even think your design is perfect, but have no proof it is, nor sufficient buy in from seniors. So to be on the safe side, the next step is invaluable.
This is another section which is really huge, but put simply, it will involve using a variety of methods to test if the solution or solutions satisfies all the requirements gathered previously.
If a the project creates a new project, always think about repeating some of the tests which will make sure that everything is still ok. Don’t take it for granted.
So there you have it, The Dr-Hyphen UX Method. Hopefully you will see benefit in this sort of way of breaking down the process. But did you see the hidden message?
The hidden message is…
… this all becomes easier with experience, as each part of the method will seamlessly flow into one another.
What generally separates a junior from an expert in any discipline is the fact that experts not only know more than juniors, but they work more efficiently than juniors. They can work on projects with little information yet still produce amazing results. They follow a process without thinking, and recall solutions from previous projects for the benefit of new ones. By master this process through repeatedly using it on projects, I intend to become an expert Clinical UX Designer.
Please do get in touch and let me know your thoughts on my method. Or if you want to talk about UX, especially healthcare UX.
Thanks for reading.