Published on | Prototyping: From UX to Front End — Medium Skjoldbroder

User Experience designers are natural allies of developers, because UX’ers seek to learn what users want and need by showing them stuff, having them try it out, observing them and talking to them.

The outcome for developers: validated, clear product specifications, including concrete designs which have been tested with users. As a result, you will be better able to estimate tasks, deliver value, and who knows? You might also avoid managers changing priorities during development and ruining your shit.

Now here is a (sadly, still) rather typical development process:

Projects with no user involvement are usually heavy on opinions and low on validation. The risk: scope/feature creep, wasted time, and building stuff users don’t want.

How User Experience designers work

For developers, I think this is the most relevant point about UX working methods: You don’t need to build a fully functional app to find out what people will think. To get realistic user feedback, you just need whatever you’re testing to look real, and appear to work. This can be faked without spending anyone’s time except the UX designer!

So that’s one part of what UX’ers do… we fake stuff. Then we get some people in, pretend it’s the real deal, and see what they think and how they react when using it. A popular term for this is pretotyping (pretend prototyping). Obviously this isn’t quite as easy as I make it sound, since products and services are complex. So we might need to build and test many pretotypes, to learn more about this complexity.

In some case we won’t be able to fake something well enough to convince users. In other cases, it simply won’t be possible. So we will still have to use our judgement and experience — obviously. But the things we are able to do will be a good step on the way, and it will be loads better than doing nothing.

Some benefits of a pretotyping approach:

Making something real enough to test requires decisions. Specifically, decisions will have to be made about structure, visual design, interaction design, and content, i.e. all sorts of information you will need come development time. This means producing the pretotype is not just a means to an end — the process of making it is an end in itself.
We don’t need to involve developers — unless you want to ve involved, that is. Design is about collaboration and communication, after all.
User feedback tells us how to iterate. The decisions mentioned above aren’t worth very much until they’ve been validated. So we test — and the best part is, this happens before involvement of developers. We fake stuff to avoid wasting your time!
All of the above leads to more concretisation and validation. Ultimately, this should make developers’ lives a lot easier when the time comes to estimate tasks and put them into development.
Hopefully some features and ideas will be thrown into the trash. Early testing should reveal if a feature or idea is undesirable — Which is good news, because we can eliminate it, and avoid wasting time.

It might still get messy

All of the above doesn’t mean everything about a development process will be rosy-red just because some UX’ers are involved :o) The world is complex, so mistakes will still be made, stuff will be overlooked, new information will appear, and decisions and judgements are only as good as the humans making them. On top of this, lots of unforeseen stuff will always appear during the actual development process: libraries get updated, 3rd party vendors screw up somehow, your platform introduces new requirements, or removes suppport for some API you were using, etc.

So inveitably, we will have to adjust somewhat duing a development process, and make things work despite the unforeseen. We’ll also have to do vertical slices during development, and test again — i.e. learn again.

But

Despite the ongoing need to learn, the initial pretotyping tests will have taught us something about the fundamental decisions and judgements. This will help make sure we are going basically in the right direction, towards something that users actually need and want. This means reduced uncertainty about those fundamentals, so that changes during development will be less radical than they might otherwise have been — they will be “course corrections”, rather than a totally new course. This ought to make developers’ lives a whole lot easier, and enable more productive and less frustrating working lives.

Thanks for reading — I can code a little bit, but I envy developers their ability to manifest working artefacts into the world… and, well… I love developers.

UX Briefing for developers was originally published in Prototyping: From UX to Front End on Medium, where people are continuing the conversation by highlighting and responding to this story.

UX Briefing for developers

Cool stuff, every week

More Articles