My former Fathom_ colleague, and friend Marie-therese McCann then gave us an outline of work to bring focus to accessibility as an element of her role at ESO.
Reginé nominated America On Tech as our charity for this meetup. A donation was made to thank Reginé and MT for their time.
I had hoped this might be the last remote-only meetup before looking to a hybrid model going forward. Time will tell. Planning for 2022 events begins now. I’ll stay flexible on format and see how things stand early in the New Year.
‘Tool soup’ is a term I first heard while designing for developer experience.
It describes the extensive toolset that developers today rely on to get their work done.
The implication of the phrase is this: no matter how central you think your application is to a user’s life, they likely spend only minutes in it before dealing with something else.
The phrase came to mind recently as I onboarded with a range of systems and applications required for a new role.
As with any large organization, multiple systems and applications are essential to help manage a global workforce. Each has different password requirements, various ways of activating and registering, and a dizzying variety of interfaces.
But tool soup is not exclusive to developers or those in the tech industries.
At work, we leverage multiple tools to communicate and collaborate, to document and produce. At home, we use apps and websites to shop, manage our money, perhaps engage with public services. We all deal our own variety of tool soup, whether as professionals, customers, or consumers.
Usability guru Jakob Nielsen’s ‘Jakob’s law’ from 2000 states: “Users spend most of their time on other sites.”
By this, he means that users will prefer your website to work the same way as all the other sites they already know. So don’t reinvent familiar interactions when all people want is something recognisable to work with.
Here is a second law for our software-saturated and time-poor world: most of your users would rather be doing something else. Yes, there are exceptions to this, but very few.
People will love your product if it allows them to effortlessly achieve mundane tasks. If you are short on context for your product or service, work with these smart defaults: people are trying to get lots of things done in a finite amount of time. They are wading in tool soup.
Assume your users would rather be doing something else. They will thank you for it.
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.”
Lockdown has added some new dynamics to meetups, not least converting local groups into potentially global events. I saw this first-hand, hosting UX Belfast this week, as attendees signed in from across Europe, North America, and UAE.
This shouldn’t have been a surprise given our guest author was Susan Weinschenk, speaking to us from Wisconsin. Susan pioneered the incorporation of behavioral psychology as an element of user experience work and features high on my list of design industry heroes.
Our second guest, Tommy McClean (from much closer to home) delivered an insightful talk on the ethics and impact of products that thrive on attention and engagement. Frequently through design-driven habits.
I continue to be amazed at the generosity of guests, giving their time to pass on hard-won experience and wisdom to new generations of designers. This meetup certainly delivered on all those fronts.
An added bonus was speaking with one of the original founders of the UX Bookclub Belfast meetup, Jamie Neely of Monotype.
“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.
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).
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.
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.