Inclusivity is something that designers like to bang on about. A lot. However, few of us take the opportunity to actually do the work to be inclusive. Let’s take a small step on the path to inclusion and let go of our egos, include engineers in design and discovery, and make better products for our users faster.
Share your lego and work the problems as an inclusive design team
Designers are skilled problem solvers who come at things from the perspective of the user who is going to endure the problem. But, guess who else is good at problem solving? The engineers who build the product. And, guess what? The engineers know the construction materials better than the designers, by the fact that it is their job to know these things better.
Inclusion in the real world
Imagine if UX was a more grown up profession for a moment, and consider the real world analogy of an architect who designs a building. In addition to building regulations and planning, a good architect will consult directly with the builders to decide the shape that the building takes and will listen to feedback. It’s a bad architect who doesn’t listen to the people who construct the house and make sensible compromises based on cost, function, whatever.
However, this is exactly what happens when a designer hands off a prototype, calls it done, and leaves the engineers to figure out the implementation details. At which point, the actual design is in the hands of the developers.
The rise of Ego Centred Design
I’m tired of hearing about UX education from designers being used as a shield when things go wrong. The conversation around levelling up UX by teaching our coworkers is worth having. However, far too often this as a one way street for the designer to blab on about empathy or something so foundational it hurts. It is defensive more than productive.
Should designers code?
I don’t care what people do for a hobby. I like to read fiction. Should designers? Actually, they might be better at empathising with others if they did. Do what you want.
Should we be familiar with the platforms we’re designing for?
You bet we should. Knowing the capabilities, behaviours, and limitations of web browsers has often informed the work I do. To tell a developer how to execute designs and not consider the materials is irresponsible. I used to struggle with designers handing over work to me back when I was a front end designer. Often the designer didn’t understand how browsers work and the designs were incomplete and at times unbuildable, inefficient, and frankly outside the budget I’d been given to do the work. Consequentially, I personally have asked for impossible things too as a designer so I’m guilty of stepping in shit too.
Why should we include business people and engineers? They don’t understand UX
Who’s fault is that? If you can’t communicate this in terms they understand or appreciate it’s on you. Saying that, maybe you work somewhere that doesn’t give a shit. But if you take home a healthy pay check every month from your work, they are at least invested financially in UX. Lot’s of places do, what’s known as, UX theatre as pointed out by folks like Brenda Laurel or Tanya Snook, AKA Spydergrrl. Conversely, there’s lots of stuff many designers, myself included, don’t know about business so let’s not play this game.
Include the mission
Obviously, education is a noble goal, but if we give people a mission they can get behind us. We are likely to educate and learn along the way. A mission is inspiring and a way of framing questions that is effective to capture hearts and minds. This example from Creative Confidence shows the power of reframing a question to inspire others to action:
Chiefly, we need to show others why something is important, how changing a situation could improve the life of a user, and allow them to provide their input into the solution. As soon as you do this, you open up the opportunities for different solutions, from people without the word designer in their title. Crucially, this brings more diverse discussion on the problem, as well as engaging the team in owning the problem. Work tends to ship faster this way than it does when you just feed the beast.
How can you include engineers in design and discovery?
Here are a few things that work for me. I’m not suggesting you turn into a commune, end up with a committee, or endless layers of bureaucracy. Basically, I’m advocating that you bring engineers, and others without design in their titles, into the fold on the work you are doing where appropriate.
- Get them to observe and participate in the research. Active participation requires note taking, and synthesis. In addition, If you are conducting interviews or usability tests, bring them in to watch, capture quotes, and synthesise the findings. Consequently, I’ve yet to meet an engineer who isn’t interested in how people use the things they built.
- Come up with problem statements, needs, and hunches together based on the research they just took part in. By and large, I like the lean UX canvas by Jeff Gothelf. It seeks to invalidate hunches fast and includes both business and user needs.
- Rinse and repeat. Share widely what you’ve learned. I use loom a lot at work to communicate async. It’s a godsend.
So get the most out of your engineers by bringing them into the UX process, dialling back your ego, and sharing power with your team. You won’t regret it and you will get to ”educate” those business folk all about UX. At the same time you will learn more about your team, strengthen relationships, and deliver better products faster than any godforsaken handoff doco.
Links & references for more on inclusive design
- Lean UX Canvas template for Figma on Community https://www.figma.com/community/file/879709971734139333/Lean-UX-Canvas-Template-by-Jeff-Gothelf
- List of things I use on the ephemera page including the goal directed design brief on Notion
- A better articulation of why and how over on Beyond Sticky Notes What is co-design?