UX Theatre

Image of a theatre setting layout with empty chairs

A theatre, but no one’s there… Photo by Kevin Schmid on Unsplash

UX Theatre


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.

Diagram showing the stages of the user centred production process, which is detailed below
Stages of the user-centred production process
(Icons from https://www.flaticon.com/authors/good-ware)

The stages of the process are as follows:

  • 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 UX has a problem that it is not being adhered to correctly
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 the my experiences above show, this describes the situation perfectly, and I was even delighted to find that Tanya has not only produced a series of useful blog posts about it, but even a poster to help identify and deal with the situation. I’m greatly indebted to her for such excellent and helpful work.

How does UX Theatre affect projects?

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, whereas each instance of testing reduces the risk back to zero each time
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.


By identifying and preventing UX Theatre being practised, you’re achieving a number of things:

  1. Preventing wasting production time and expense by working in an iterative method, being able to identify problems and address them proactively
  2. Creating products that are more successful, and not only address the needs of users, but also identify ways in which to delight them.
  3. 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.

Simple, but true.

Simple but true

Years ago, when I started out in UX design, I thought that the experts in my field had all this arcane knowledge around UX, knowing all these tricks about how to handle projects and how to make products the very best that they can be.

You know what over a decade working in UX has taught me?

  1. Listening to your customers;
  2. Understanding their collective and different needs; and
  3. Ensuring that what you’re making addresses those needs;

is enough to put you ahead of most of your competitors.

This simple premise is one that everyone in a company should be aware of, and yet I’ve witnessed a number of large influential companies out there who still don’t manage it. If you’d like me to help your company, let’s talk.

Making your LinkedIn profile work for you

Photo by Nathana Rebouças on Unsplash

Making your LinkedIn profile work for you

I recently came across Katie Jacquez’s highly useful post I’m a designer at LinkedIn, here are 4 tips to attract recruiter with your profile. This post provides a valuable insight into how recruiters search for profiles, and how you can tune your profile to work for you, merely by adjusting the Headline, About and Skills sections. I’ve been constantly frustrated in the past with the number of recruiters on LinkedIn who approach me, asking if I’m interested in roles which have little to do with my skillset, and I’ve previously put it down to their use of keywords to find me, and their inability to actually bother to actually read my profile. Turns out that yes, recruiters are time-poor and do resort to finding people using keywords, but you can control those keywords and messaging to ensure that you get more useful offers.

I’d previously worked with my Headline and About sections, but Katie’s piece helped me to even focus further on the initial messages I wanted to convey to recruiters who only had time to scan those sections. The real power, however, comes in the Skills section, as this acts as the central resource for keywords by which recruiters search for viable candidates for their roles. I had previously passed it off as not very useful, and had filled it with various things I was good at, as well as some things which I was passable at, but I felt helped pad out my experience. It was only after reading the post that I realised that perhaps the reason why I had recruiters coming to me with development jobs in Python or C++ was because I had some time ago stated I knew a bit of JavaScript (a mistake, as I’m still not terribly good at it), which caused the recruiters to assume that I was interested in working with other languages. What’s more, looking at the order of the skills on my list, I realised that I didn’t have the ones I wanted to show off the most at the top, and there wasn’t really an order of preference. No wonder I kept on getting confused recruiters, asking if I had experience in conducting user research, when that was languishing lower down my list!

By making these simple changes, I managed to greatly improve the quality of responses from recruiters, with one of them even yesterday complementing me on how comprehensive and useful she found my profile. Of course, there are still those who don’t bother to consider my level of experience and offer me junior design roles, or care to read the first line of my About section that states I only add people I’ve worked with, but at least I haven’t been offered another coding job since I made the changes.

Learning to build the right thing; how you can apply user research to make your product successful

Man taking notes on sheets of paper

How and why you should conduct better user research in your projects


Having worked on software development projects for a range of different clients and industries, I have frequently seen that user research is conducted poorly, or even not at all. In this piece, I conduct an in-depth analysis of how to conduct successful user research for your project, and why it is so important. This includes:

  • Planning our your research
  • Getting the most out of your interviews
  • What to do after each interview
  • Analysing research findings
  • Sharing your discoveries with your team

Read “Learning to build the right thing – how you can use user research to make your product more successful” on Medium.

Seeing the road ahead — Catseyes and iterative design

Close up of a "catseye" reflective road stud, in the middle of a road

How road safety measures show the value of revising your design work


Having previously worked on projects where stakeholders had set a tight timeframe, and not allowed for any testing and iteration of the solution, I wanted to explore the concept of iterative design, and how it can benefit a project. I had learned as a child about the story of Percy Shaw, and how he had devised Catseyes, the reflective studs that illuminate the centre line of a road, inspired by the eyes of an actual cat reflecting his car’s headlights one evening. Using this example, I describe how Shaw didn’t just create his solution from that discovery, but went on to revise his design, test it, and incorporate new ideas until he produced the design that we know today. In the same way, projects can benefit from this approach, getting feedback on their designs, and ensuring that they suit user needs, before they are launched.

Read “Seeing the road ahead — Catseyes and iterative design” on Medium

How to improve your job search

Office space in black and white

Sharing my experiences with job hunting in the UK tech industry


On average, people in the UK tech industry change jobs every two years. Having had some experience myself of the difficulties around navigating the recruitment space, I thought I would provide some insights and tips around things I have found useful. These include details such as:

  • Defining your ideal job role, and what you want from it
  • Self promotion, including how to put together your CV and portfolio of work
  • Making applications to adverts, and keeping track of which applications you have and have not been successful in, and following up those you haven’t heard from
  • Tips around how best to present yourself at interviews, from screener calls through to face-to-face interviews

Read “How to improve your job search” on Medium.

How I created the user experience for my portfolio site

A clean design for my work


For many years, I have been using my website, SableIndustries, to represent the work that I do. However, in recent years, it has been in need of an update. This piece takes you through the process I followed in order to ensure that the website echoed the design thinking that I have learned in my work, as well as the work itself.
Continue reading

User Experience Design, a personal perspective

My own experience of user experience design

User Experience Design, or UXD for short, is described in its Wikipedia entry as “the process of enhancing user satisfaction with a product by improving the usability, accessibility, and pleasure provided in the interaction with the product”. Whilst this is a sufficient summary to explain UXD in a brief way, I wanted to take the chance to explain more about User Experience Design, how I view it, how it works for me, and what how I feel it can be beneficial, not just to me, but for companies that put the user at the centre of what they do.
Continue reading

More about me…

Hi, nice to meet you!


Part one

My name is Andrew Robert Burgess, or Andy for short. I’m a User Experience Lead, having worked previously as a Graphic and Digital Designer, and a Front End Developer since I started my career in 1999. This has helped me get a really good understanding of not just the processes which go towards creating a great user experience for the product or service on which I am working, but also experience and knowledge of how best to work with production teams, and knowing what is required to fully optimise that product or service to give the best message and representation.
Continue reading

Designing notifications, or how we could learn to love our phones again

Perhaps the problem isn’t the phone, but the way in which it interacts with you?


Another day, another article providing a soul-searching insight into why quitting smartphones is the new quitting smoking. These articles seem to occur regularly in the media these days, with accounts of people who feel trapped by their overuse of their phones, how they feel that their digital life is impinging on their real life, with their phones turning into monsters that continually buzz at them with notifications. These articles end up preaching solutions such as digital detoxes, phone stacking in restaurants, and have quotes from people saying how much better they feel when they don’t have their phones switched on, or even with them.

For me, the problem doesn’t lie with the way we interact with our phones, it’s about how our phones interact with us. When the web giants such as a Facebook, Google and Amazon began to realise just how much money could be made by advertising, they not only cashed in, but began to manipulate their properties so that they could multiply their efforts. The way that this was achieved was by factoring in design and functionality that encouraged compulsive behaviour. You may have heard of the “slot machine” effect of the Facebook newsfeed, encouraging you to pull down and refresh to refresh your newsfeed and get that dopamine hit of new content, or feedback on your contributions (in the interests of fairness, this isn’t actually exclusive to Facebook, many other apps have the same action, with similar effects). Many sites and apps use patterns to encourage further participation, and to keep the user on their product, and, whether intentionally malicious or not, some of these can evolve into dark patterns.

One such dark pattern that’s prevalent on almost every mobile device I know of are notifications. Even if, like me, you’re very stringent on keeping notifications on your phone to a minimum, whenever you download a new app the assumption is that the app can, unless you tell it otherwise, make noises, put messages on your lock screen and show banners whenever it wants to. In order to curtail this, you have to go into your settings and specify what notifications you receive. Apple and Google have made this easier to access in recent years, but it’s still an opt-out process, rather than an opt-in one, and for good reason – app makers want your attention on their products, and so want this way of bombarding you with information regularly, in the hope that you will give in, click on the link, and buy the product. Chances are, you’re probably not quite as hardcore with your notifications, so just imagine how fewer ones you would receive if you could choose to opt-in, rather than have to make the effort to opt-out?

Chances are, companies such as Facebook and Google aren’t going to go away, and they will certainly be around longer than the time you decide to go on your digital detox and later decide to rejoin the connected world, and, what’s more, you can be pretty sure that a lot of your friends are still going to be using them. However, there is a rising tide of interest in how these companies conduct themselves; we’ve seen questions into fake news, how they structure content on your timeline, and whether they should be responsible for the media that appears on their platforms. In my view, we should be asking these companies to not only look at the content they provide, but also the way they provide it. They should work out what their relationship with their users are, and how that they can provide advertising and updates in a more conscientious way. These companies aren’t the only problem, but if we could get them to change and show the benefits of doing so, others may follow suit. Through better notification design, we could learn to love our phones once again.