You’re the designer, isn’t this your job?

During last week’s Clearleft UX Laundromat Hana{:target="_blank"} asked for session suggestions for a workshop she’s running as part of the many Spring Forward{:target="_blank"} events happening in and around Brighton in March.

Hana’s workshop Concept to Code{:target="_blank"} brings together the members of Ladies That UX{:target="_blank"} and Codebar{:target="_blank"} in a spirit of discovery and demystification in the UX and dev spheres.

The following discussion touched upon various themes; type of audience, levels of experience, managing expectations, workshop formats.

Throwing in my 2 cents, I suggested a couple of activities that might be beneficial to both the UX and developer audience; an outcomes vs outputs session and a collaborative sketching session.

A problem shared…

I remember the first time I read Ben’s Outcomes, not outputs{:target="_blank"} blog post. I was feeling the frustration of working in a feature-centric top-down organisation. I hadn’t yet been turned onto Lean so it blew my mind a little when I read it.

Outputs = features shipped

Outcomes = desired change

Our team was juggling a bloated feature list on top of several newly shipped big features. The last question we needed to hear as designers and developers were “What shall we build next?”.

Fortunately the other designers and developers were advocates for performance and accessibility and naturally responded positively to a different kind of project question: “What is the change we want to make?”.

When you think in features (outputs) you are making huge assumptions of what is actually needed for your users. Worse still, the usual next step in this process is to just build the thing and wait to see if it was actually the right thing to build.

But when you start to think about what change you want to make for your users in order to help them solve a problem (outcomes) you are taking the first step to empathise with your users, user centred design and providing a great UX.

But I can’t draw!

In my previous role as a “front end designer”, I was responsible for both front end development and user interface design. Sometimes I would be handed over a fully developed feature and assigned to “make it look pretty” and maybe if I was lucky “add UX”. Other times I would be the one handing over the prototype and sketches to the developer.

After a few days the recipient would start to wear a quizzical look on their face and then the flow of micro-level questions would start to trickle in shortly followed by the macro-level.

This exposes two problems.

1. An absence of shared understanding from the macro-level - joining a project late and not being part of the x weeks of conversations and decisions
2. An absence of shared understanding from the micro-level - one-sided development of a solution that might ignore technical constraints or user needs

This isn’t exclusive to design and development either. Anyone from the organisation who can add value should be present in the design process.

Collaborative sketching sessions are a great way to generate and discuss a bulk of ideas very quickly together, creating a shared understands of why one solution should live and another die, and avoids a panic when the designer goes away on holiday and someone wants to know why solution x died and y and z are in the next phase of testing.

It also breeds advocates for the design. If everyone is designing together everyone is invested in the overall outcome.

Danny{:target=“blank”} also pointed out, developers think and draw in systems so make very good sketching partners.

---

There are still tickets for Concept to Code{:target="_blank"} and Hana’s{:target="_blank"} looking for questions for the night so get in touch!