How is prototyping different? June 5, 2017
Usually interactive projects involve one or all of the following creative talent:
- User experience (UX) designer
- Visual designer
- Front end developer
- Back end developer
- Quality assurance engineer
A traditional project lifecycle looks something like this:
- The user experience designer expresses user flows and wireframes which represent the final product. After your approval...
- The visual designer processes the wireframes into mockups which capture the client's desired visual aesthetic ("look and feel"). After your approval...
- The back-end developer builds the API while the front-end developer integrates.
- If you're lucky, a QA engineer tries frantically to break things and reports what they find to the developers for fixing.
And if you're really lucky you'll have nothing but praises to sing about the your product and everyone can go home early.
Except that never happens.
What really happens is that you notice things. Things you didn't notice when all you were working from were some black-and-white sketches. You realize a button's text is confusing, so you ask if it can be changed. Your supervisor informs you that the product needs to work differently.
If only you could have shown your supervisor sooner.
If only you could have seen your product in its early stages to collaborate on its success, instead of leaving it to the mercy of an agency.
That's the problem prototyping solves. Prototyping is when you build a product iteratively, collaboratively, and with as little upfront design as possible.
It puts experimentation above specification, and outcomes above delivery. It implores developers to become product- and design-focused instead of just playing an adult game of paint-by-numbers.
Your average developer builds software according to a design specification.
Developers who prototype design software to achieve outcomes through experimentation.
A new paradigm
As programming tools have increased in capability, developer productivity has increased with it. It's now not unfathomable that a solo developer execute both the design and implementation of a small- to medium-sized digital product.
Composable user interface libraries like React mean we rely less and less upon visual designers to inform the first versions of our products, because it's trivial to iterate on visual aesthetics in the midst of a product build.
And technologies like hot reloading of stylesheets mean that a developer fluent in CSS can rapidly design a gorgeous user interface without ever consulting a visual designer.
Paradigm shifts like this one have occurred throughout the course of software development history. Agile development killed the idea that you could build software successfully with rigid upfront specification, but its methodology speaks very little about user experience and what role developers play in shaping it.
I believe we're now going through another transformation: The realization that developers, if up to the task, can play a unique role in driving the user experience conversation. And that role can be so profound that it changes the entire process of product development.
Now, I don't want to make any wild claims that visual designers are unnecessary or that all developers should start focusing on user experience. After all, we need specialists in all sorts of disciplines, and big projects will always require the leadership of a visual designer to create cohesion and establish identity. But I do think that as product managers, entrepreneurs, and anyone who buys professional software services realize the potential in granting product leadership to their developers, we're going to see a shift in methodology.
And too, as developers begin to recognize the value they can bring to a product by becoming more involved in the user's perception, experience, and value, they too will embrace this subtle but powerful change.
The power of simultaneity
A non-technical user experience designer can offer only so much in terms of real value to end users. They can demonstrate a concept, but not execute it for analysis.
A non-technical visual designer can produce a new identity for an interface, but relies upon the whims of a paint-by-numbers developer to bring that concept to customers in the product.
A design-focused, user-focused developer can execute all of this simultaneously. They're able to conceptualize a visual identity, produce a working prototype of an interface concept, and give it to real end users to test their hypothesis.
By putting your developers in the design seat, you reduce the communication feedback loop that inevitably occurs between designers and developers. This new autonomy produces design decisions which both serve the user and consider technical challenges.