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

Your design mock-up is not your product.

The high-resolution design phase needs to die with fire. It’s time to re-think our design process, put Photoshop and Sketch in their place, and maybe then we’ll get some real interactive design done.

Let’s start with scope. I want to speak to the high-resolution or high-quality design phase: the bit where we use Photoshop or Sketch or some other app-du-jour to pixel-nudge our way to glory. People often think of this as ‘coloring-in’ the wireframes. It tends to happen after the scoping, design brief and hopefully some UX processes have taken place. Depending on your workflow and stakeholders, there may be many, many painful iterations in your design tool before you can go ahead to code.

This post started as a response to a really frustrating design consultation I was engaged on recently. As the dust settled and I began to think about it more, I realised that this experience had the same feeling, the same texture somehow, as many design reviews that had gone before. In other words, I began to form an intuition that all of these seemingly different frustrations and frictions might in fact be symptoms of the same disease.

So let me unpack this a bit more: my recent experience was of a high-resolution website design phase where the client had a very clear idea of what they wanted visually, but very little clarity on what the strategic goals of the website were, what behaviours they wanted to enable, or how the site would solve problems for their end-users. While this lack of strategy was acknowledged, they wanted to put off addressing those questions until they had a live website. Presenting visual design ideas was additionally frustrating because the client had a strong opinion of what they thought high quality design looked like for their specific domain and user base, so were very anchored to specific visual outcomes but without perhaps having a strong rationale for those choices.

If you’re in a product team, it’s easy to hear stories like this and think “oh yeah, painful clients, but this doesn’t apply to our team”. And yet product teams suffer just as much from communication and alignment issues. There’s that old chestnut, where we think we’ve agreed to a scope, a feature set, or a way forwards — then when design is presented it becomes clear that the stakeholders on the team all had very different ideas about what they had agreed to.

“Agreement”

I’ve experienced design feedback where the conversation was really bogged down on a specific feature. “This accordion doesn’t work!” They were adamant that it was the wrong component for the needs of the UI. They kept coming back to it, and I couldn’t work out why it was causing such a strong an emotional response. And then I finally realised, they hadn’t seen the icon to expand the accordion. It was lacking a design affordance that was easy to fix. The component itself was actually a pretty useful way to group information, while making the form easy to navigate. So often with design feedback, there is a nugget of truth which you have to unearth, and it takes patience and forbearance to get to it.

And then there’s the times that design conversations get lost in the quagmire of small, relatively unimportant details. Why do we care so much about which specific shade of blue that button is? Why do seemingly intelligent, thoughtful people go down this rabbit hole of critiquing small design details that feels at best wasteful, and at worst like turning bikeshedding into an extreme sport?

Perhaps it’s about empowerment, or lack thereof. I believe that generally people come a place of good intentions: they want to contribute and to get to the best outcome! But these conversations get derailed because they lack the vocabulary or the context to provide constructive feedback.

The common thread

So here’s my hypothesis: the reason we get bogged down in the high-resolution UI design phase and waste critical amounts of project time and resources on design iterations is because this is where shit get real. Clients, investors, internal team members: all the stakeholders actually think about what you are building (really think about it) for the first time. The mental arithmetic calculating perceived product value versus price tag begins.

Unsurfaced assumptions about product vision, look and feel, and emotional tone may arise. Miscommunications or poorly explored product ‘defaults’ are exposed at this point. All the unexplored and implicit ideas about implementation are suddenly laid bare. Reality and imagination collide in the most uncomfortable way possible.

Importantly, the pain we collectively experience at this moment is almost always due to the failure of earlier processes to communicate, investigate, align and problem solve. Endless high resolution design iterations are a crutch for lazy, bad process. We give ourselves permission to work it out when we have visuals, and put-off hard decisions til later.

Design right now:

If we try to visualise the UI design resolution mapped out over the course of a project, it’s maximised in the middle, bottoms out when it hits the code phase, and may not reach the same level of quality by go-live. This is often due to hitting deadlines or resources running out. Why invest so much of our precious project time and resources in this design phase, if we’re not optimising the result for our final product? There are a thousand unseen, gorgeous concept design .jpgs out there whose visual quality far outshines the final web page or app screen that real users interact with.

So here’s the question: is it time for the ‘high-resolution’ phase of software design to die? Can we throw Photoshop and Sketch on the pyre and dance around in our un-designed wireframes, shaking our assets with the freedom of a toddler escaping their nappy? Well maybe not for all use-cases, but I think there are plenty of instances where the answer is yes. More importantly, it’s time we stopped assuming that we must have a UI design phase, and question its necessity to the project, the domain, and the problems we are solving. Let’s give ourselves permission to redesign the way we design.

Wouldn’t it be better if our design quality looked more like a consistent upwards trajectory?

Design as it could be:

So how do we get to this design process utopia?

I think it starts with education. Most people are unpracticed with spatial visualisation: they simply struggle to imagine a wireframe or sketch as its potential end result. And importantly, they don’t know the multiplicity of design choices and refinements that still await after the wireframing phase. This type of visual thinking is a hard-won skill for designers, a muscle developed over years of use. Recognising and planning for this disparity, and trying to arm people with the tools they need to engage with the design process strategically, feels like the right place to start. Here are a bunch of ideas, tools and thought-starters for your consideration. I’ve clustered them roughly by project phase.

1. Education at kick-off

There are lots of people trying to tackle this question of how to build up capabilities in a group, align intentions, and enable everyone to contribute to the creative process. Some examples of tools to enable collective creativity are Lego Serious Play, Project Play (run by Dara Simkin here in Melbourne), and Draw how to make toast. In addition to group activities, here are some thought-starters for how to tackle education:

Teach clients and external stakeholders about the processes you’ll be employing for design across UX, UI and development. Consider giving them historical context: how have these techniques come about? What sorts of problems do they respond to?
Empower everyone with a shared vocabulary. Be wary of jargon.
Practice collaborative design processes like sketching design ideas, card sorting, providing design critique, etc. Use a topic or problem outside the product domain so that stakeholders can practice these skills and build up their ability to participate in an effective way is not fraught or emotional.
Identify the strategic goals of your design as early as possible. What are you trying to learn? Who’s your primary audience? What behaviours are you trying to enable?
Communicate and champion that design strategy. Continuously refer to these strategic goals, especially if the conversations get off track. Ask stakeholders to frame their design feedback in relation to the success or failure of these goals.

2. Make your UX work

Low resolution design — sketches, wireframes, etc, is where most of your design ideas should be explored and where most of your iterations should occur. While it can be difficult to test low-res prototypes with end-users, you might find that you can jump straight to code prototypes which are a really effective testing tools, if you’ve done sufficient ideation and refinement already. Read more about the use-cases for different fidelities, and think seriously about how to get the most value from low-resolution design:

Low-resolution design is much (much) cheaper to the business than design in high fidelity tools like Sketch or Photoshop.
Low-resolution design lets you explore more solutions, more rapidly.
No expertise is required to sketch on a whiteboard — so you can gather lots of ideas from non-designers like clients and devs.
Low-resolution design helps you avoid anchoring bias (where stakeholders getting attached to the first visual design, rather than exploring strategy and solutions).
Storyboards can help you explore user journeys and the context in which your design will be used. They’re an effective way to communicate design ideas rapidly.

3. Redesign design

Our design processes are in many ways a hangover from creative agencies who developed before the explosion of digital publishing. I think all aspects of design should be up for grabs: the process, design artefacts we use for discussion, and tooling.

Look for the fastest ways to communicate your ideas. Think outside the box. Finished design is time and resource expensive compared to other design activities like sketching, wireframing, stealing ideas from existing websites, etc.
If your design process still requires magazine-style full page concepts, please stop! It’s time our design deliverables match development deliverables. Atomic design aligns nicely with component-driven development.
Moodboards can communicate your color palette, font choices, look & feel and emotional tone rapidly, and there are some great digital tools to use:
https://www.canva.com/templates/collages/mood-boards/
http://www.gomoodboard.com/
Look for ways to demonstrate design or implementation ideas as quickly as possible. Google Design Sprint has a bunch of great ideas for ways to achieve cheap and hacky prototypes.
Use real content as soon as possible to test design use-cases.
Explore design use-cases and edge-cases as soon as you can, and identify ways that the design may be brittle or fragile for problem-solving with developers.
Kill the idea of design sign-off. Instead, have regular design check-ins where you confirm you’re going the right direction with the relevant stakeholders.
If you must have an artefact to sign-off on, make it a good quality wireframe. Iterations on your wireframes will still be significantly less time consuming than making those iterations in Photoshop.

4. Design in code

How can we make increase iterations and make the process more collaborative? There are a number of teams tackling tools to help bridge the design to development gap, including AirBnB’s recently released React to SketchApp library, which produces Sketch symbols from your codebase to help designers maintain consistency and design with the ‘real’ UI. It has also been forked to HTML to SketchApp. Follow Mark Dalgleish to hear about his adventures in implementing this tooling in his team at Seek. There’s a whole world of tooling and work on how to create better Living Style Guides and Design Systems rather than constant bespoke design sprints which don’t scale and introduce unnecessary discrepancies.

This is such a big domain I’ll just point at it rather than trying to cover it thoroughly. My suggestions for intention setting, regardless of your tech or design stack, are:

Move into front end code sooner.
Design in-browser with your inspector. Take screenshots.
Simultaneously explore design ideas in code and in design tools. Focus on the bits of UI that are innovative, new, or hard to communicate.
Plan for pairing and collaboration between UI and FED skill sets.
Encourage skill-sharing and growth between FED & Design.
Don’t assume that the design phase ends once coding begins.
Stop telling developers that their roles aren’t creative!
Allow time to explore and be creative in code.

Final thoughts

It’s worth pointing out that this is hardly an original topic, that I’m not the only one mulling over these challenges and how to tackle them. TBH I wanted to write this post for my own benefit to help clarify and formalise what I’ve been feeling over the past few years. I genuinely love visual design and I think at its best it has the capacity to be emotional, evocative, even epic. I want designers to spend more time pursuing new ideas, visual innovation, and pushing their own limits; less time pushing pixels and tweaking line-heights. Let’s use the design tools more deliberately and more sparingly to explore vision, invention, world-building. Incremental optimisations and refinements should happen in code.

If you’re interested in this intersection between design and development, Invision has recently launched a fund to support startups who are trying to bridge this gap.

To close, doubtless there are many other tools, techniques and ideas out there to tackle this question of improving how we share and critique design ideas, and help align them more efficiently with their eventual outputs. How else could you communicate design ideas rapidly and efficiently without using Photoshop or Sketch? Consider as an exercise: you need to communicate the emotional tone, look & feel and other qualities of your design without doing a concept mock, so how could you go about it? I’d love to hear your ideas.

Burn the concept mocks was originally published in Prototypr on Medium, where people are continuing the conversation by highlighting and responding to this story.

Burn the concept mocks

Cool stuff, every week

More Articles