Last Friday saw the launch of my wife Romany’s exhibition, Women’s Weeds: the hidden history of women in medicine, at the Museum of the Home. Researched, written and created by her, the exhibition covers 600 years of history with four distinct themes; Witches, Herbal Healers, Colonial Medicine and Victorian Feminists, and takes the form of an audio trail through the gardens of the museum. Visitors are encouraged to walk through the garden, where they can listen to Romany narrate her work through audio tracks, which can be accessed using a mobile device and headphones.
Romany asked for my help in putting together the webpage where people can access the audio tracks. She already has a WordPress site, Blackthorn and Stone, where she shares her work, and so, in order to give her the ability to make changes easily, and encourage people to explore her site further, she asked for the Women’s Weeds page to be part of the site. As her project was supported by an Arts Council England grant, as well as hosted by the Museum, it is important for her to be able to track visitors to the page, as well as seeing which audio tracks they listened to. We managed to achieve this by using the combination of the analytics on her WordPress site, as well as using the Soundcloud analytics provided by her Soundcloud Pro account. Also, to access the page, I created a QR code using Bit.ly, which allowed users to quickly access the page using their phone cameras, and provided another way of tracking visitors. We even created the shortened link of bit.ly/womensweeds, in case visitors were not able to use their cameras.
One of the signs in the garden one the Museum of the Home, showing visitors which section of the exhibit that they should be listening to.
The page itself was built using a standard WordPress page, which provides a way for Romany to be able to make adjustments as she wishes, without having to engage in any coding. I then applied custom CSS, using the specific class that WordPress gives the page to define it from other pages, and optimise it for a phone interface, as this is the most likely thing that visitors will access the page with. We gave some careful thought to how visitors will interact with the page, and as it is quite a long project with twenty three sections, we needed to help users navigate between sections as easily as possible. I started by building the sections, and then providing a menu at the top with page links to jump to each section individually. At the bottom of each section, I provided a link back to the main menu, which helps visitors from unnecessary scrolling. We did think about having the link back to the menu as a floating box at the bottom of the screen, but opted for the simpler option of having a link at the bottom of each section, as a floating box could obscure information, and would be harder to cater for on different screen sizes.
The menu is provided with a map of the gardens beside it, so that it is easier to see and associate each section with the relevant part of the garden. The map was traced from an aerial view on Google Maps, in order to ensure proportions are correct, and the sections are picked out in which, so that they can be more easily seen, even when looking at a phone with glare from the sun. Each section also includes photos of the areas, so that visitors can see where they should be looking, and it also provides a visual representation of the gardens, allowing visitors who can’t access the Museum the ability to see visual context, even if they can’t be there.
The exhibit had a very successful launch this last Friday, on the 7th July, with Romany and the Museum Director, Sonia Solicari giving short introductions to the exhibition before encouraging everyone to explore the gardens and listen to the work (which you can see in a video below). Visitors found the page intuitive and easy to use, with one small issue of one person who tapped on the Soundcloud link, and though she was meant to be listening the the tracks from there, rather than from the page. With this feedback, I also ensured that there were clear instructions for people to tap the orange play button, to prevent them from the same confusion.
The exhibit will be in the gardens until the end of September, so if you’re ever in the Hoxton area of London, please do go and give it a look, or if you can’t why not go to the page, and you can at least experience it remotely.
If you’d like my help with designing and creating intuitive and enjoyable online experiences, please get in touch, and we can discuss your requirements.
A little while ago, a friend shared with me her receipt from a restaurant called Daisy in Margate, Kent. Rather than being anything about the food or cocktails there, my friend (who is also called Daisy) knew I would be interested because it was one of the best examples I’ve seen of what we in User Experience call “delighters”, which can be the thing which can guarantee the success of your product, and even lift it above the competition.
To understand what delighters are, you have to know about the Kano model, a theory for product development devised in by Noriaki Kano in the 1980s to define customer satisfaction. It groups product work around three main areas; basic needs, performance needs and delighters, corresponding to the way in which user perceive them. To summarise their meanings:
Basic needs are the absolutely must-have functions that a product must include in order to successfully address the needs of the user. An example of this would include having a seat on a bicycle, so that the user can sit on it. Not having these would constitute an abject failure in addressing the basic needs of the user.
Performance needs describe the continuing improvement of functionality in the product. In our bicycle analogy, this might include providing rubber grips on the handlebars so that the user can comfortably hold the handles absorbing shocks, and prevent their hands sliding off if they get sweaty. Not an absolute basic need, but a definite improvement that can become a fundamental expectation from that point.
Delighters are the extras which provide added value for users. For our bicycle, this could be the addition of mudflaps, so that the rider isn’t splashed with mud when riding off-road.
In building a project, it’s clear that addressing the basic needs of the user are fundamental for success. If you don’t have them, you will have omitted important must-have functionality, and that would prevent the user from achieving their most important tasks. However, once you have those basic needs identified, appreciation of what could bring extra value might well be what sets your product out from the competition.
These needs are recognised in the user research stage of the production process, as we speak to users about their experiences, and identify opportunities where we can help them with our work, sorting them into “must-haves” (basic needs) and “nice-to-haves” (delighters). Working with our project team, we can then use the combination of business needs, user needs and technological restrictions to define the shape of our solution, and produce something which satisfies those three, as well as hopefully giving space to include a few extras that delight our users, make them excited about our product, and increase sales and satisfaction.
(For clarity, the photo above is only part of the receipt, and just shows the delighters of information on weather, tide (Margate is on the South East cost of England, so this might help inform customers if they want to go for a stroll on the beach after their meal), train times, taxi phone number, and postcode so you can plan your own taxi home. Of course, I’ve omitted the part of the receipt that shows the actual basic needs of the cost of the meal, as that’s private to my friend.)
If you’d like my help with ensuring success in your products and teams, please get in touch, and we can discuss your requirements.
In my previous post, I stated that a number of large companies fail to follow user-centred production processes, and that by adhering to those processes, you can get ahead of a lot of the competition. As a way of providing more detail to my claims, I’m sharing a talk I previously gave on this very subject, how I discovered that it was enough of a common phenomenon that it actually had a name, how it affects more than just designers, and how everyone on a software production team can work to address it.
The user-centred production process
Everyone who has worked in a project team to produce something should be aware of the User Centred Production process, (also known as User Centred Design, but I prefer to call it a production process, so that it’s more inclusive to non-designers). It’s a valuable mechanism which ensures, by identifying and placing user needs at the centre of production decisions, the resulting product will be successful with users because it addresses those needs. This is a fundamental improvement on previous production methods, which would try and guess what users wanted, build and launch something to address that, and then adjust the product in the next version, or build something else, which could be very time consuming and costly.
Discovery – a collaborative exercise to define the aims and scope of the project, giving a rough idea of what is being achieved, and how it will be achieved
Research – conducting research with people who actually will or currently use the product, to gain insights around their requirements, and ensure that what you plan to build addresses their needs
Analysis – reviewing what’s discovered during research, highlighting opportunities and problems, identifying user types and their interactions, and noting further questions and assumptions for further research
Prototyping – quickly creating low fidelity solutions, doing just enough to be able to challenge assumptions and questions, and start a process of slowly improving fidelity as understanding grows, aiming towards a finished product.
User testing – letting users try the prototype, testing assumptions, asking questions, and providing feedback for further development as part of a “build, measure, learn” cycle.
Launch – the product can now reach a “minimum viable product” level where it’s ready to ship, and can be widely released. The “build, measure, learn” process can continue, for further refinement and to address further issues.
So why do companies get this wrong?
As previously mentioned, I’ve worked with a number of companies who fail to follow this process, and there are various reasons why this happens. I’ve included them below, with some actual quotes from project leads, justifying why they’re not following the process properly:
Lack of appreciation of the value of the process
“I’ve been in this industry for 15 years, I know what users want, so we don’t need to waste time on research.”
“We don’t need to conduct research, let’s just build something and test it.”
Project leads in this example assume that they don’t need research, and that they can save time and effort by not including it in the production process. This may well be down to a lack of experience of how good research can inform a project. I’ve always found during research that not only does it identify basic needs, which the people above may well be aware of, but there is always something which you didn’t expect – a new discovery, an added benefit, or a “gotcha” moment that changes your perspective. These are impossible to predict, and understanding them can mean the difference between a functional product and a truly great product. Also, in the second quote, by not conducting research before you start building something, you run the risk of building entirely the wrong thing, and wasting time and effort by having to revise it heavily, or scrap it altogether. Research before production ensures that you have a decent understanding of user needs, and have identified opportunities and problems before you begin.
Lack of interest in engaging with users
“We don’t really have connections with our customers, so it’s going to be hard getting people to talk to.”
“Our users are far too busy to engage in research.”
“We would get you some users to talk to, but Sales are far too busy.”
Project teams are often distanced from Sales and Customer Relations in larger companies, and this can sometimes be used as apathy to not engage in user research. I actually heard the first quote while working on a scientific database product, and I detail in my case study about how I had to go out myself and find research candidates, because the project leads were unable to. This friction is usually the cause of project leads being unable to provide links, or scared that if they do, the research will harm sales in some way. A lot of my experience runs counter to this, and having users take part in research, they feel invested in the process and that their requirements are being individually addressed. This can actually help with Sales efforts, and gain useful knowledge that will be beneficial to them.
Time constraints
“I’ve promised that we’ll deliver this product in (x) weeks. We haven’t got time to research or test with users.”
Project leaders stating they haven’t enough time for research indicate more lack of appreciation of the benefits of research. They may not have given time to conduct research because of an adherence to antiquated production techniques that aren’t user centred, or they don’t include time for research because they don’t see its value. Projects should always include time to conduct research as a fundamental part of the user-centred production process, and the concept that research takes a lot of time can be quelled by drawing up research schedules to demonstrate that they fit in the overall project roadmap. Ideally, Agile projects should include continual research, which allows some degree of running research alongside production, although this could introduce the need for some rapid changes of direction if new discoveries are made.
Pressure to deliver
“We can’t pause production to conduct research, we’ve got to start building something immediately!”
It’s understandable that projects have deadlines, as value and progress need to be demonstrated, but the need to build something quickly indicates again that time has not been allocated for research properly. Research should be an important part of initial project planning, and the understanding of its value and the need for allocating time should be made clear to all participants and stakeholders from the start. By doing this, you will ensure that stakeholders will ask to see research discoveries, rather than product progress.
Discovering UX Theatre
After seeing these patterns, I came across a number of articles which indicated that I wasn’t alone in this situation:
A series of headlines from online articles stating that there’s a fundamental problem with how UX is being practiced in some companies.
These articles led me to the discovery that this term “UX Theatre” had been coined by Tanya Snook in 2018, describing it as:
“the application of any sort of design methodology without including a single user in the process, or including users but merely for show.”
As we’ve previously discussed, missing out on research means that you could start building the wrong thing, but what if you missed out on other parts of the process?
Missing out on analysis (which often happens if you don’t research, as there’s nothing to analyse) means that you fail to identify opportunities and problems before you start building solutions.
Missing out on prototyping means that you don’t iterate on your design, and the user doesn’t see it before launch.
Missing out on testing (which happens if you don’t prototype) means that you increase the risk of the product failing upon launch
This last point is best described in a diagram I saw in a talk by Josh Sieden, co-author of the excellent Lean UX: Designing Great Products with Agile Teams, which has been a fundamental part of my UX learning. In the last slide of his talk, he included this diagram, which describes how continual iterative testing minimises risk in a product production process:
A graph showing how continual production without testing increases risk (red line), whereas each instance of testing reduces the risk back to zero each time (blue line).
This helps explain the value of iterative testing (a subject I’ve written about before), and how it’s an important part of the user-centred production process, a process which, as indicated above, should be followed fully.
So, what can we do to address this?
The responsibility to identify and address UX Theatre doesn’t just stand with designers, as, demonstrated above, it affects the whole production process and the team. It is here that I invoke one of my favourite film quotes, the inimitable Jeff Goldblum playing Dr Ian Malcolm in Jurassic Park:
Everyone in a production team should be able to challenge the way in which a project is being conducted, and ask for more information about how decisions are being made. To that end, here are some things you can ask:
Check with your team that they’re building the right thing (research)
Have they provided research and analysis documentation and thinking, to justify their production decisions? Are they based on conversations with actual users, or just assumed?
Did they write their “as a user…” statements based upon actual research discoveries, or are they just making them up out of what they think is right?
What other assumptions are being made?
Check with your team that you’re building the thing right (testing)
Is the project following an iterative “build, measure, learn” process, building a Minimum Viable Product, just high enough fidelity to test, and then rebuild based upon the discoveries made while testing?
Or are they building a Minimum Sellable Product, which won’t be tested with users until it is launched?
If you can, make sure the project is properly structured
If you’re part of the initial planning of a project, ensure that the structure of the project includes each of the stages of the user-centred production process above.
If people question why these sections should be included, provide examples of ways that each stage is useful, and explanations of what could happen if they are omitted.
Conclusion
By identifying and preventing UX Theatre being practised, you’re achieving a number of things:
Preventing wasting production time and expense by working in an iterative method, being able to identify problems and address them proactively
Creating products that are more successful, and not only address the needs of users, but also identify ways in which to delight them.
Reducing frustration in project teams, providing more opportunities for them to learn about users (which can prove useful in future projects), and making products which demonstrate success that they can proud of.
Thank you for reading this through, and for helping to make products and project better!
If you’d like me to help with ensuring success in your products and teams, please get in touch, and we can discuss your needs.
