Design and Development Empathy – Covidence Case Study

Matt Shanks

Matt Shanks

Principal Product Designer & Author/Illustrator for children. I'm out to improve the quality of life for everyone who uses the things that I make.

It’s been interesting to watch the ways in which software companies are trying to bridge the conceptual and language gaps of designers and developers. There are frameworks, design systems, collaboration tools and so on that are ‘trying to connect designers and developers in a better way’. And, whilst I use these tools regularly, none of them come close to doing the actual work of listening and understanding the needs of ‘the other’, and working together to get shit done.

Designers vs Developers is the not the right way to frame things

There are way too many articles and thought-pieces that keep pointing out the biological, contextual, social, and cognitive differences between designers and developers. But, at Cogent, and, more specifically, on a very recent project, we’re talking about things differently. Yes, it is important to acknowledge the differences, but there’s also space for acknowledging what’s common – the outcome that we’re both working to achieve, together.

No-code tools are a solution to some problems, but not the main one

Ever since development became a bit too complicated for one person to do both (yes, web designers used to code and do the design work), we’ve had ‘prototyping tools’. One of the most ubiquitous in the early stages of my design career was Axure. The powerful but complicated and convoluted way to ‘make and test something without a dev’. I have personally spent a huge portion of my working career in Axure making very powerful but fake, throwaway experiences. I’ve used variables, if/else statements, for loops and so on, with the express purpose of mimicing what a good front-end developer could’ve made in 1/3 of the time.

And whilst Axure is still brilliant at keeping designer and developers apart, new no-code tools have entered as the ‘new wave’ approach to fill the gap. The problem with Axure prototypes is that once you answered the questions that the prototype was meant to answer, that prototype was discarded and it was up to the developer to build it all from scratch. No-code tools go part of the way to solving the ‘throwaway’ problem. Now, the time I spend making a prototype (or the ‘real thing’ in a no-code tool) isn’t wasted, because I can publish it, and learn from it – at least for a while. It’s got a longer lifespan than my Axure prototype but, the problem with no-code tools is that it’s still not the real thing. It’s still attempting to avoid what seems to be the industry taboo – designers and developers sitting together.

Covidence: A designer + developer case-study

At Cogent, we build teams and we build them well. What clients get when they get a Cogent team is a group of like-minded individuals who already know how to work with one another. It means we get up to speed and progress through storming → performing more quickly. So, when a Cogent team was deployed on Covidence, we thought we’d ratchet things up. Designers and developers sitting together, prototyping together, learning together, and – you guessed it – building together. We proved, very quickly, that software alternatives to sitting together mean sub-par outcomes in a less efficient time frame. Here’s how we did it.

Common goal creation and setting

It’s easy and safe to focus on team outputs when we’re kicking off a piece of work. But, that’s a recipe for division, so, instead, we focus on outcomes. Instead of “Release a piece of functionality by the end of this engagement (6 months)” we set business goals to achieve:

  • Increase use of a particular part of the application by X%
  • Increase revenue by X%
  • Ensure customer love remains at X% or higher

When the goal is outcome-based, it gives the team agency to explore how they might own and develop a solution together. The usual design process goes something like this:

  • Set the goals
  • Designer does some research
  • Team sketches on ideas to solve the problem
  • Designer prototypes the solution and tests it with users
  • Designer shares insights with the team
  • Designer iterates on designs to make ‘final’ mockups
  • Designer and team create cards to deliver
  • Developer builds everything, all over again, from scratch

This frontloads the context and learning, and the designer is the one that benefits. They then have to spend a lot of time ‘updating’ the team on what they’ve learned and why it’s important. “Bringing the team along the journey” is a phrase that gets bandied about as if it’s a good thing. But, what this means is that the pressure is on the designer to make sure that they communicate those things truthfully and clearly and hope that everyone ‘gets it’.

With Covidence, we worked a little differently – Designers and Developers paired up from the beginning so that everything was shared. It looked something like this:

  • Set the goals together
  • Designer does some initial research (and developers can attend if they want to)
  • Designer and developer come up with possible solutions
  • Designer and developer pair to build multiple re-usable prototypes, in browser
  • Designer and developer test with users
  • Designer and developer iterate on the fly, refining the code as we learn
  • Designer and developer work together to refine a ‘good-enough’ solution to ‘productionise’
  • Developer releases new feature and picks up next piece of work to answer the next most pressing question

There is a lot of benefit in this approach but here are two main ones:

No more ‘bringing people along the journey’

Suddenly, the designer no longer needs to make ‘presentations’ and excess documentation to ‘bring people along the journey’ because, those people that normally sit in meetings to listen to those presentations? Well, they were there. They were invested in trying some things (building prototypes), they learned what the effect was (what worked and what didn’t), and they got deeper into the domain because of it. Suddenly, if a designer is sick, projects can still move forward because the context lies outside of one person. Progress can still be made because the team, as a group, can still continue to learn.

A better solution that’s quicker to build

By having designers and developers pair throughout, it means that during the creation and learning phase, we’re leveraging the different ways that designers and developers bias toward solving a problem to come up with new and interesting ways that neither party alone could have invented. There was a key moment where I was so stuck in my own bias that a developer literally sketched out the solution in code to show me what they meant. Because of their intimate knowledge of the problem, combined with their technical prowess, I know there is no way I would’ve arrived there on my own or even off the back of ‘concept sketching workshops’. My proposal would have taken three times as long to build and with no greater certainty that it would’ve solved the problem any better.

Build the thing as we go means the product is the documentation

We’re building the thing as we’re going. There are no ‘throwaway final’ Axure documents or no-code environments. It’s the real thing. Sure, it starts off dodgy – there are no tests and maybe we’re using libraries and frameworks that may need to be replaced later, but, that always happens anyway. Sketching in code early means that we are constantly de-risking and refining the work together; it means less bugs and less uncertainty when we’re ready to release the work into the wild. And, finally, we have an immense efficiency in working together to solve the next problem, and the one after that. The context that is normally the sole responsibility of the designer is now shared – it makes conversations over documentation possible, which is what underpins the agile manifesto in it’s truest sense. The code and the product is the documentation.

What makes this work?

When I think back to that recent project, and the goals that this high-performing team hit together, there are a few things that I think are critical to the success of this way of working:

  1. The foundation lies in getting the goals right.
    Outcomes not outputs. Giving the team a business goal and the context about why it’s important, i.e. “Improve customer satisfaction by 20% because that will lead to greater revenue.” AND then the autonomy to solve that problem in the way that they discover works was critical. Without that trust, the whole thing is impossible and we end up stuck in delivering a ‘road map of features’.
  2. Excellent people skills that begin with listening.
    It’s such an easy thing to write but such a rare thing emphasised in retros and planning when the focus is all about ‘what’ we’re delivering, not ‘how we’re actually working together. Good listening skills, empathy, and an openness to achieving the same outcome in whatever way we get there was the glue that bound this team together. Designers and developers recognising that it wasn’t about individual success, but team success. Getting to know our own strengths and weaknesses. Calling each other on the moments that we drifted away from the goal (it always happens), and celebrating the light bulb moment that can come from the spaces in between the individuals – the conversations. Yes, there are uncomfortable debates and differences of opinion, but with the goal set (see number 1), it’s easy to resolve that objectively.

You’ll notice that those 2 ingredients above don’t need specific tooling because they aren’t tooling problems, they’re people ones.

Trust, empathy, listening, understanding, alignment to a common goal are key. Admitting to this is the first step toward a more successful and high-functioning team. A more successful team will likely translate into a better product, and thus, a better business. In short, everybody wins.

Liked this post? Share it on…

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn

Related posts

Design
Will Rockel

Aligning design tools with design practices – Part 1

In this two-part series, I’ll take a look firstly at the reasons why we choose and use the tools we do, and what those tools say about our organisations. In Part 2, I’ll step through a practical process for assessing the nature and value of the tools you’re currently using, and your organisation’s design maturity, before suggesting some next steps to help you create a roadmap for a better design culture.

Read More
Design
Ben Rowe

Getting on board with onboarding – Part 2

Welcome to part two of my post on User Onboarding. In part one, we talked about what good onboarding is, and isn’t. And after showing some great onboarding examples, we talked about how understanding your user – and understanding the value that you’re providing them – is crucial to a successful onboarding experience.

Read More