Getting out of our own way

I read. A lot. Probably too much. But user experience and building products is my jam. I wake up each day, thankful that this is how I get to spend my time.

Recently, I’ve been wondering why we’re not building better products. And maybe there’s an upward-trending curve on some design macro-plane. Yet every day, my feeds are full of articles full of hand-wringing, restatements of fundamental guidelines, and so many reinventions of time-worn processes wrapped in shiny new rubrics. How is it that we are still wandering? How is it we haven’t nailed this?

I wonder whether the problem isn’t us.

I like to illustrate the difference between UI and UX with a story: a pair of designers, one with only UI skills and one with only UX skills, are tasked with designing an app. After iterating for a year, the UI-designed app will look fantastic and garner praise on Dribbble, whereas the UX-designed app will probably look boring, but support a thriving community (and hopefully a business).

The idea is that UX processes, on their own, provide the tools to help build a customer-focused business. The simple process of talking to customers and testing features with them gets you there, every time.

So why can’t we do it?

We don’t respect each other

This is hard and evidences itself subtly in practice, but often we push our opinions and perspectives onto others’ domains. This is insidious and incredibly damaging, since you’re undermining the responsibility that other person has has within your development process.

When a person feels their contribution doesn’t matter, or that they’re often casually overruled, they will not be fully committed to their work, and the entire process suffers on all projects going forward.

Roles need to be well-defined and well-understood by everyone through each stage of development, team communication needs to be fluid, and stakeholders need to be strictly managed since they wield such tremendous power.

We blindly follow process

Has the “Double Diamond” become a curse? There’s an implicit assumption, a velocity, if you will, that I think needs to be called out. You typically start with an “insight” and — boom !— off you go. Development is now fully engaged and rolling along. But what if that insight is wrong? Where in the DD do you test that assumption, and where do you evaluate the results of that test? Great practitioners know how to bake validation into the process, but I think it’s probably worth pulling out explicitly. This is exactly what Dual-Track Agile addresses.

We don’t follow the process

Most of the time, we fall into the trap of bad habits, or don’t see the harm in skipping steps, and this is where we get into trouble. Process is not “the thing”, but it helps support and guide us on our journey to find and build “the thing”. Too often, we get overconfident and this pushes us off course. The tiniest missteps early in the development process can cause you to end up in a very bad place.

We use the process for evil

I love opportunity canvases, but they’re also a gate and if the opportunity is not obviously incredible (which is 99.99% of the time), then the canvas can be gamed for political ends.

I’ve seen user research summaries twisted to deflect another executive’s opinion, instead of informing product decisions. Usability testing can be gamed in a similar way. Interpretation is critical with user research, so it’s prone to misuse and abuse.

We don’t shape the process to the project

Again, process is not “the thing”, so shouldn’t we dedicate some time to shaping our process to address the project at hand? We’re typically doing this anyway — we skip steps, for example. Better, I think, to acknowledge this with the team and discuss where and why we want to make streamline our process, so everyone understands the benefits and risks.

Software is hard

We are solving new problems all the time, it’s understandable that we don’t get it right the first time. It’s also understandable that by the time we get around to that second iteration, enough has changed to erode most of the existing progress. It’s a tough uphill battle, and it’s difficult to not overextend yourself so that meaningful progress can be made.

We work as geniuses

This is a tough one. We spend our days accumulating experience and improving our skills. It’s understandable that we rely on our domain expertise to make decisions. But we should wield that power wisely. We have a team and a process precisely because we are better when working in concert. A good team, collaborating together within a well-understood process, will create better solutions than an individual genius.

So, those are a few of the reasons that came to mind.

Please share your own reasons that we designers often come up short in delivering great products. I’d love to hear about your experiences.