Four years ago to the day, after a significant portion of my career working in agencies and consultancies, I made a shift into enterprise products. To be specific, I now work in the complex world of infrastructure automation.
It was a jarring transition, not only from UX project work in an agency to product – but to an enterprise product.
Like many designers, I used to sit on the sidelines of enterprise UX, muttering “why is design over there so bad?”
There are many differences between enterprise UX and B2C, or even much of B2B. One of the key differences is the level of tolerable complexity.
Enterprise products are more often used by teams, not a single individual. The dream of a single user who gets up and running quickly, who is delighted by the experience, and who converts to a product evangelist is a distant one.
Working in an agency, you are hired for expertise or for an outside perspective, possibly to overcome internal politics or inertia. You contribute, your client pays you, and you move on, possibly with some great material for a case study.
There are times when I doubt what I’ve actually achieved; forgetting, of course, that some of the achievement has been to deliver work that is not easily reflected in a portfolio piece. In those times, I find this thought from Jared Spool, one of the most respected voices in the UX community, so reassuring:
“When I talk with UX design leaders …they’re shocked (and a little disappointed) when I tell them it’s likely they won’t see any real movement for months. It could even be years before they’re close to accomplishing their objectives.”
Working in the enterprise means getting comfortable with being uncomfortable with your design output. Outright ‘wins’ of old are hard to discern, and only after some time.
But this discomfort need only last as long as it takes you to realise that what matters, more than ever, is thevalue you have helped to deliver.
Your work is unlikely to raise gasps of “cool!” from other designers. You realise you are now in much more of a team sport, and part of something bigger. And, at this point, you have truly grown as a designer.
Several years ago, I was given a yoghurt maker as a Christmas gift.
A (nameless) relative had been quite astute, having heard me remark on at least a couple of occasions “yeah, we take yoghurt on our breakfast now…” Maybe they had heard it too much. Having identified what appeared to be a need, they presented us with a shiny, new yoghurt maker.
Sadly the gift went unused. The contraption remained tucked away in the corner of a cupboard until it made its way to a charity shop some months later. Not the outcome my thoughtful relative intended.
What went wrong?
It’s not that I was ungrateful. My relative was making a thoughtful gesture. They knew that this might be a source of limitless yoghurt for years to come. Maybe I would try my own recipes. Save some money on store-bought yoghurt.
My relative could not have known was that they were asking me to change my behaviour. Moving from pots of inexpensive yoghurt with the weekly shop, I would now need to:
Learn how to use the yoghurt maker
Buy individual ingredients
Find time to make the yoghurt
Find space in the kitchen or fridge for the yoghurt maker itself
Rather than do all of that, I stashed it away.
Adoption is a challenge for all products and innovations. At the core of this is the requirement to replace incumbent routines or habits. This requires moving people away from how they currently do things and using your product instead. As far back as the sixties, Everett Rogers was addressing these concepts in his influential work Diffusion of Innovations, focusing on new products in the medical and agricultural industries. Years later, digital technology has enabled and accelerated the development of new and diverse products, all still facing the same fundamental challenges.
Outcomes are the successful manifestation of behaviour change. At its simplest, a change may mean starting to do something new (physical activity, for instance) or doing more of something (perhaps managing tasks in a to-do app). A full spectrum of behaviour change was mapped out comprehensively by BJ Fogg as a part of his work in the Stanford Persuasive Technology Lab. The Fogg Behaviour Grid remains a seminal reference on the topic.
No matter how delightful it may look, a successful product must facilitate and inspire the behaviours that motivate its adoption, and ultimately deliver successful outcomes.
This link between adoption and desired behaviour in the product is often missed by product teams, who tend to work in a fictional future where their product is thriving. Designers in particular need to be aware of the process that a product is replacing, and which behaviours are inherent to that process. Helpful questions to ask include:
Which elements of the current process will be hardest to let go of
Is the current process handled by another product or multiple products?
Do the outcomes have any dependencies?
What behaviours do you need to alter to deliver success for your product?
It is tempting to interpret this challenge as one of on-boarding, and creating a delightful first-time run experience. It can help, of course. But doing this alone and then hoping for the best is blind faith.
No matter how delightful it may look, a successful product must facilitate and inspire the behaviours that motivate its adoption, and ultimately deliver successful outcomes.
short term measures that indicate early successes.
longer-term tracking confirming that behaviours have changed, indicating that the product has achieved adoption.
A new product may represent innovation in a sector or industry, but the path to change is littered with friction. This can be particularly evident in businesses where incumbent processes affect multiple departments and teams. Ripping those processes out can be painful, and take time. Innovation can be intimidating and, no matter how positive, will not always be welcomed with open arms.
Understanding this need for behaviour change, whether replacing old or creating new, is a key milestone for designers wanting to achieve ever-greater meaning with their work. As choice architects, designers hold responsibility for facilitating the behaviours they want to see articulated in interactions with the products we design. Achieving this requires a deep understanding of user motivations and what they perceive as success.
By understanding the behaviours which need to change, designers can better anticipate and address the inertia which could otherwise leave their product festering on a shelf, an unwanted gift.
“I have not failed. I’ve just found 10,000 ways that won’t work.” — Thomas A. Edison
One of the most effective ways to kick off a new initiative is to identify how it might go wrong. Similarly, when planning research goals and methodologies, awareness of potential weaknesses can help to establish immediate learning goals.
The Pre-Mortem is a well-established facilitation tool for use early in a project life cycle. As with a number of similar tools, the Pre-Mortem makes use of future projection to address the present.
If you are unfamiliar with it, the activity works like this: an assembled project or product team is asked to imagine a version of the future, a number of months down the line. The project/product/feature has shipped… and has been an abject failure. It wasn’t bought, it wasn’t adopted — whatever failure looks like for the issue in question. The Pre-Mortem then asks, simply: What caused this? Why did it go so wrong?
Eject the elephant from the room
Using a Pre-Mortem, a safe space is created for doubts, concerns or apprehensions to emerge and be expressed as a concern for the future, not as a gripe about the present, even though that’s what it very well may be.
In any team, there are often strongly-held points of view that can seep out throughout the course of not just a meeting, but an entire project. A Pre-Mortem actively invites such thoughts and feelings to be aired. These might otherwise fester, emerging only when there is a bump in the road — “we could have seen this coming!”.
Providing a forum that permits individuals to voice and record their concerns allows these strong opinions to be aired and treated with equity.
“When people have strong feelings about the topic, they often think of the meeting as a contest where their view — which they see as the correct one — should prevail. That leads them to try to convince others that their solution is the right one.”
– Roger Schwarz, author of ‘Smart Leaders, Smarter Teams’¹
While gathering doubts and concerns is a positive step in itself, these can be actively put to work as experiments to find (in Edison’s words) the things that won’t work.
A pre-mortem workshop, with inputs captured around points in a core user journey
Step-by-step
Gather input on post-its . Ask participants to list 3 main factors that will have contributed to the project failing (online this can be done with tools such as Mural, Miro, or Google’s free Jamboard).
Group the inputs — take time to find commonalities in the contributions, and collate them into groups.
Identify themes —it may be helpful to think about these 3 categories²:
feasibility: can we build, scale and support this — usually this will have a technical skew, but can apply to a broad range of resources.
viability: will this be profitable or advantageous for the business.
desirability: will customers find value in this.
4. Finally, devise small experiments³, capable of testing problems identified in each area. Be intentional about what you would need to learn, hear or see that will tell you your project will have difficulty succeeding. As a team, discuss the minimum amount of time, capital or resource required to test whether any of the issues represent credible threats to success.
Find what won’t work
If the issue is a real problem, how could you quickly test for it? Even modest pieces of secondary research, prototyping and competitive analysis can qualify, for example:
Discover if anyone tried and failed to build something similar before. Have they themselves or others written about their experience? Stories of failure are often well documented.
Evaluating a market opportunity is a multi-faceted pursuit. But even this can start with a simple examination of existing, successful products which offer similar features, and a realistic assessment of what is required to compete – and where you fall short.
These are rudimentary activities for sure. However, before massive resources are put into motion, such small experiments that address particular elements of risk can challenge flawed beliefs that a product will thrive.
By leveraging the combined wisdom of the team, then gathering corroborating evidence from external objective signals, UX professionals can contribute to de-risking an initiative.
Mitigating risk
The ‘flipped’ nature of the Pre-Mortem is important in establishing a critical mindset. Confirmation bias is a natural human tendency. We look for validation of an idea, and find false positives. Testing for confirmation of weaknesses introduces critical thinking and can counter inherent biases.
“Optionality works on negative information, reducing the space of what we do by gaining knowledge of what does not work.”
Innovation cannot be manufactured on demand. Success does not follow from throwing unlimited resources and capital at the ‘big idea’. Having more successful ideas is more likely to come from more ideas — small bets — against which small experiments can be run to identify failure points.
No time? No problem
Time more than all resources is limited. If this is the case for you or your team, and follow-up experiments are not an option, try this:
Run through the Pre-Mortem exercise until you have a collated set of potential failure points.
Discuss mitigations around the issues. Look for actions that can be taken now to alter that possible future. Work towards an actionable plan in the event of anything coming to fruition.
Create a reference-able checklist, and review it at each retro or team meeting. If anything highlighted in the Pre-Mortem raising its head, go to your action plan.
Assuming that you have time for the Pre-Mortem itself, the very least you can get out of it is greater awareness. And that awareness can be codified.
Invest in failure
As you plan your stakeholder engagements and workshops, consider investing in a Pre-Mortem. It will typically take anything from 30–90 minutes, and it is capable of revealing that a project is partially or deeply flawed before it begins. For that reason alone it can prove invaluable to your team.
I’ve written a piece for the Puppet blog on the thinking behind an alerts & notifications system for a new product. I’ve had great feedback on the article, which serves to remind me that I should lift the lid a little more often on the work we’re doing.
Covey’s prioritisation matrix is referenced as part of the piece. This is, of course, a commonly known and commonly-referenced framework. Increasingly though I find myself seeking out new models and frameworks to assist decision-making. They are very much part of the toolkit. I hope the system I’ve outlined here makes it into someone else’s.
Despite working in experience design, I don’t go around looking for opportunities to criticise products or services. Like most people, I just want to get on with what I need to do and accept that occasional lapses in service are bound to happen now and then. Ten minutes in to a recent hotel stay, however, I was already making notes.
After taking my name, the receptionist promptly disappeared through a door and left me standing for 5 minutes. What they had omitted to say was that they were checking if the room was ready.
The room key card I was issued didn’t work, requiring a return trip to reception to report it. Then a wait for another to be prepared.
A wifi password supplied in the guest welcome pack didn’t let me connect. The correct one was written on the keycard holder, something I was expected to discover.
It turned out to be a perfectly enjoyable stay. In those first few minutes though, I was questioning the wisdom of booking. It was a small example of how seemingly unrelated lapses by a vendor added up to poor overall customer experience.
Some 10 years ago, I switched my bank due to a series of let-downs. I was prepared to go through the pain (at that time) of moving current and savings accounts away from a bank of 12+ years. During a protracted series of phonecalls, one explanation offered for the difficulties I was facing was: “that’s another department… we don’t deal with that here.”
Departments are a reality in any organisation of course. But as conduits of conflicting priorities or processes, silos are self-serving, destructive entities. Variations on Conway’s Law litter our daily physical and digital interactions. Customers are not interested in how your organisation is structured. When it becomes visible to them, it is usually at the cost of a cohesive experience.
A common problem is that teams working on a product or service know intimately how everything hangs together; they are well versed in the complexity of what’s being created. This awareness can surface as a tendency to see difficult challenges as insurmountable obstacles. Very often, process is wheeled out as a defence of current practices, or a cure-all elixir. Cross-departmental initiatives are hard work, which tends to make them unattractive. The result can be a culture that simply accepts ways of working that do not deliver value.
Naturally, this is all rich, raw material for designers, and service design in particular. Time and again as a design consultant the most radical thing I could do was to reflect what customers were going through back at the organisation. A lack of focus on, or understanding of, creating value for customers is a fundamental issue.
A customer-centered perspective can be the unifying force in the relentless struggle against imposed friction, while also providing a guiding light for new initiatives. Leadership should look to clear the way for ideas to thrive across divisions. Individuals or teams are required with sufficient drive and resilience to face down inertia and defensiveness, even the rampant virus of cynicism.
Siloed organisations are machines of aimless intent, efficient only at generating endless reasons why customer and user experience can’t be made better. Silos are anti-customer and anti-value.
Hard work it may be, but the option not to get rid of such barriers is all but gone. Ultimately every organisation needs to decide – consciously – whether defending silos and siloed thinking is more important than creating and retaining customers.
