Dawid’s Blog
Published in

Dawid’s Blog

User Experience is a way of working that makes delivery easier

I’ve recently notice that User Experience is ‘someone else’s job’, in the form of an interaction designer, a UX team or the service design guys.

This is wrong. We promote cross functional teams delivering outcomes, the only certainty that you have is that your product will fail if users don’t like it. This is amplified in enterprise delivery, where we aren’t creating sexy consumer ride share apps or recipe managers. What if it’s a system to manage the replenishment of inventory, diagnose a tricky support ticket or produce a financial reconciliation report.

We expect perfect experiences from any tech we interact with. Minimalistic guided processes that allow me to focus my energy on the important parts of my work, problem solving, spending time with my customers and my staff.

There is an important and unexpected benefit to having a user experience lens to our way of working. To get even a minimal degree of certainty that your users will like your product, you need to spend time with them and involve them in the design process. We call this co-design or co-creation.

Our end users are there with us, designing the solution, sketching what they expect the experience to look like, how they logically think of step 1, 2 and 3. By involving users deeply in the design process, we get ownership of the solution by those most important, and thus far more confident requirements, understanding of tradeoffs and accountable decision making.

The old way of gathering requirements was to run workshops. Traditional workshops are horrible horrible things. A business analyst, often a contractor with minimal experience in the industry, sitting behind a computer, asking questions and then typing up what a user requires in the form of user stories.

The end users leave the room feeling a bit strange. Was everything captured correctly? Did the business analyst really understand what they said. How can they be sure that they provided everything… they’re not in IT, they don’t know what level of detail is required, they think that maybe someone else is doing it.

The next time the users are invited back it’s to test the solution, and apparently it meets all the requirements. Imagine if an architect asked you how many bedrooms, bathrooms, and car spaces you need, then asking “what else”, then the next time they see you is when the house is built. Imagine how different your mental image is to theirs. But what if they involve you deeply in the design process… they went a bit slower first, they showed you sketches of ideas, took you to a house to show you some of the components, and then gave a 3d model or a drawing of what they’re building. You took that home with you, thought about it, did your own drawings over it, and then brought that back to them. That’s co-design.

Once the build process starts, they know exactly what they should be building, and you know exactly what you should be getting.

I wonder if we shouldn’t have different ways of measuring projects. We’ve come a long way, but particularly on enterprise delivery we are still flawed. Before we start tracking user point velocity and # of defects, let’s track the level of meaningful conversations, confidence and deep contextual understanding of all the parties that matter. Design Thinking gives you a framework for this, and a facilitator can help you pull this off.

Do your developers know why they are building this? Have they literally sat in the chair of and end user for an hour. Do the end users understand the limitations of the platform that has been selected? Let’s get these people to work together as one team. The end users aren’t one part of the beginning of a project, and then intermittent cameo appearances around the place.

By deeply understanding and involving end users in the design process, we not only build better experiences but more fit for purpose products. It’s more fun for end users too… really! If your user can create a product specifically for them and they trust the process, they will be invested. If you think this means user stories and epics, you are wrong. It’s sketches, tests, mockups, simulations, interviews. And not by the build team, by the users themselves also.

And the final side benefit is that build teams love completing solutions users love. If you’ve worked through the night for multiple weeks and you witness a sprint review where you constantly fall back on “it wasn’t in the requirements. It’s out of the box. It’s how the system is designed. It’s out of scope”, it’ll always be an us-vs-them situation and there will be attrition and disappointment.

But what if your users were your biggest advocates? What if at the sprint review the users are explaining why it’s been built this way and educating their stakeholders on the journey… It’s powerful, it’s the only way.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store