Stop designing screens and start designing outcomes

In a large corporate environment, a client once challenged how I spent my time everyday.

''I don't understand what you're doing all day. Quite frankly I don't see the output on dropbox to justify the time you've spent on the project!''

(I interpreted this to mean that the quantity of sketch files I had produced was inadequate).

At the time, this struck me as a fundamental mis-understanding of how user experience and design value should be measured in product teams, as it solely reduces a designers responsibility to ‘drawing up UI files’. On reflection, the arena of digital product design has so quickly broadened the spectrum for the term 'designer' (in a digital context), that this view is more easily understood. 

Crafting a beautiful user interface is undeniably key to a digital designer’s role. However it's only a small part of how brilliant product-focused designers add real value. A beautiful UI is worthless until it’s part of a meaningful feature in front of a real person, contributing to business and user objectives. 

At Red Badger our joint team purpose is always to work on the things that matter. To deliver digital products and services that drive these business objectives and add value. A good designer knows the point at which design value is realised: when product outcomes are met, not when sketch or photoshop files are finished. Are they ever ‘finished’? Do they ever need to be?

So how can we deliver visual perfection in our final product, and reduce output of hi-fi design mockups, in favour of spending more time refining working software? How can we spend time designing digital solutions which deliver results, not pixel-pushing sketch screens...

Respect that your final outcome is built in code.

Sounds simple, but digital portfolios still arrive as immaculate design flats instead of live links 'because the engineers ruined it'. Developed features are met with designer's agonised cries of 'but why don't they look THE SAME?'

The obvious answer being: because they're not the same.

Even if we temporarily suspend the depth and complexity of a complete application, and focus purely at the technical construction of a UI, the fundamental principles of front-end web development rarely form the building blocks of a design file. But they absolutely should.

The box model, rules of margin and padding, typography in rems vs pixels vs ems. The importance of considering these constructs in depth is enough content for a whole other blog post.

And then you want responsive right?! Often we’re now trying to create visuals for an infinitely variable visual experience. Insanely more laborious (and sometimes difficult to get your head around) in a static environment.

To produce a good outcome, we need to understand as much as possible about the execution medium (HTML, CSS, JavaScript). We then need to design visuals with these principles in mind from the ground up - and work to realise features in our final medium (code!) as soon as possible.

Start by sitting down with engineers to finalise the UI for a feature, and exact the level of visual precision you want in production ready code. Build spacing and typography rules collaboratively, in a way that’s logical for both engineering and design. A shared framework is much more likely to be adopted successfully, and reduces the reliance on engineers inspecting design files, which are subject to human error. Leverage the consistency of software, and before you know it good engineers will be calling you out on all the inconsistencies in your design flats.

Be clear with the role your ‘design output’ plays in the process of creating a product.

Remember it’s a means to an end. Output should be varied, and always have a clear purpose.

Can this pattern work effectively on all devices? Will users understand the semantics of our question ordering? Is the error messaging convention clear? How can we decrease the number of calls to the helpline?

Consider the work necessary to answer each question, anything from quick sketches on paper to prototypes of features for testing. Be liberated when you don’t need design software to do your job - if the whole team is working on form field errors, some quick sketches and a conversation with engineers can be enough to get an initial version working. Then the nuances can be refined in code, not laboriously perfected in a work in progress file.

Be really critical about where hi-fi UI visuals and complex interactive prototyping will credibly add real value to the process of delivering working features, and recognise where it’s just an overhead. Additional documentation creeps in when the team is divided across a number of concerns, usually to make sure decisions which can’t be discussed are recorded somewhere. Try and continuously collaborate to avoid this.

Importantly - remember it’s completely unnecessary for one set of visuals or prototypes to fulfil all needs simultaneously. This level of cohesive complexity is called your product!.   

Become emotionally invested in the working software and product outcomes, not the work in progress files.


Much of product design and the experience users have with an application, far extends past what we can visualise in a mock-up.

Prototyping tools can give a great indication of flows, but can’t take into account API response times, or how a css animation might impact the performance of the application.

Software is complicated - having all the answers 'upfront' is simply unrealistic, and the visual UI only a specific layer of a complex cake. So designers should be there throughout the process to solve problems or work with unexpected requirements as they arise.

Good designers are in it for the long-haul, and always have eyes on final product strategy. Did more people sign up for your thing? Are people happier? Did you save lives? Sell more ice cream?

They can pivot entirely on something which doesn’t work quite the way the team thought it would and happily rework solutions which are no longer fit to deliver against the product objectives. Their investment is in the final product - not work in progress design files, which should be easily changed or discarded as product requirements evolve.

Designers usually play a key role in communications with the wider business, and understand that part of their responsibility is advocating the importance of working software throughout the project team.

I have worked on projects where designers or stakeholders don’t even know how to access staging environments, such is the investment in the 'pre-designed roadmap'.

Show off the build at every opportunity! Avoid referring back to ‘the original design files’ and take critique and commentary to refine the final built UI. Don’t accept ‘make it like the design file’ as feedback. Resist the urge to present (or even produce) large volumes of high fidelity up-front design.

To less trained eyes the presentation of a complete visual UI looks like so much more of a complete digital product than it actually represents. The last thing you want is stakeholders leaving a meeting thinking they have seen the complete roadmap, and adopting the ‘Now we just have to build it’ mentality. This breeds an unrealistic expectation of the volume of work which has actually been completed, and hardly ever promotes tolerance for mistakes or when things just don’t go to plan.

Spend less time finalising a set of specifications, and more time facilitating team problem solving


Good designers help build shared understanding, facilitate collaborative exploration of solutions and infiltrate product development far beyond just what the UI looks like.

Design visuals are tools for the whole team and should be created in collaboration with everyone. Pre-defining visual solutions is time consuming and arrogantly assumes you have solved everything, which reduces team ownership of the product.

Set up sketching workshops, get initial ideas in-front of everyone quickly, get stakeholder input early and often. A big ‘ta-dah!’ on hard grafted (‘perfect’) visuals will only lead to frustration if something changes.

Collaboration brings brains together on every problem, builds investment and context throughout the team, and swaps time spent finessing a disposable working file, for pushing perfection and value in customer-facing features.

 

Read more about design and user experience in cross-functional teams from Sari, our Chief Design Officer

Come to our User Experience and Design Exchange Meetup to find out more about how we use design methods to influence strategy, address complex business problems and design and build responsive web apps that are used by millions of people across the world.

Claire Murray
More from Claire