Designer vs Developer: how Google is trying to bring them together

Google Design Advocate Mustafa Kurtuldu has initiated a YouTube and podcast series aimed at improving understanding between designers and developers

Kurtuldu has been working in digital design since 2001, during which time, he says, he has seen a lot of friction between designers and developers, much of it borne out of a lack of understanding.

As a Design Advocate at Google, he has been party to a lot of internal discussions about how to iron those issues out and thus came up with the idea of Designer vs Developer, a six-part YouTube series and podcast. Released every two weeks, each episode will deal with a different issue, from effective collaboration to whether too much testing and data ruins the creative process.

“The premise of the show is to try and solve the challenges faced in the industry by having an open conversation between the two, providing takeaways, solutions to workflows, tools and discussions on everyday struggles,” Kurtuldu says. “We also want to introduce design ideas to the developer community and educate them about design best practice. I picked subjects based on things I had personal challenges with, such as the feeling that the world of UX is over regulating the creative process to figuring out how best to work with one another.”

The first episode, below, shows Kurtuldu in conversation with developer Jake Archibald.

Here, Kurtuldu explains a little more about the idea behind the series and how Google uses Sprints to aid collaboration and understanding:

“I was super excited he writes. It was my first day of my brand new job. I had just finished university and was raring to go. I had made it. I could finally call myself a ‘Designer’. That glorious emotion was short lived though, when my manager approached me and said that my job was to ‘just make it look pretty…’.

There is a perception by those who don’t design that our role is to ‘paint’ existing things, that nothing is original, and we as creative people are nothing more than sensitive flowers (or snowflakes) who just need to be told what to do.

I wonder if this is down to a degree of envy for what we do. After all, when you look at the designer’s average day or try to explain the ins and outs of how we spend our time, we are incredibly lucky. None of this feels like work.

I have had real jobs before, from working in a sweatshop, garage as a mechanic, to stacking shelves in a supermarket.Those felt like REAL jobs, but design, to me has always felt like a part of who I am. What surprised me when speaking with Jake was how developers sometimes felt the same, a lack of appreciation for what they do, nothing more than a cog in a machine.

Sometimes I do think we are our own worst enemy, because the privilege of doing what we do we gives us the habit of living in our ivory towers. The language that we use is quite inaccessible to those not involved in design or development. We as an industry often speak of ’empathising with the user’ and ‘user-centric design’, but how can we honestly build empathy for our users if we can’t empathise with each other, or those outside of our towers?

Talk is cheap. So how can you create an environment that encourages empathy? Well at Google we advocate Design Sprints, which might make you sigh, “what, another process…? Surely that sucks out the creativity?” From personal experience, projects I have worked on that used the Design Sprint process have helped solidify the team and have worked wonders for the project.

The 5 phases of a Design Sprint

A sprint involves all of the stakeholders in a team, from marketing to engineering, typically five to eight people. This helps break away from the typical office setup of siloed teams. Everyone gets a chance to have a voice and everyone’s voice is respected. Then over the course of five steps, the team goes from learning about the challenge they are trying to solve, coming up with concepts individually, sharing those ideas, deciding and refining, building a prototype and finally testing the proof of concept. This process creates a bubble where the whole team works concisely to solve a problem in a short space of time.

An example of a Design Sprint I was involved in was for a project that was sponsored by Google.org, who funded a programme to help children with clubfoot. With a coalition of charities, we were able to get all of the information about the condition, such as the process of curing clubfoot, and the challenges faced in countries which have high numbers of patients. From this, the whole team learnt together about the day to day hardships doctors face and the stigma attached to the condition in some parts of the world. Once we came up with a collection of concepts, we managed to create UX flows and prioritise the focus of the project, allowing the charities to develop a system that would help physicians. You can learn more about the project here.

Sprints can take anywhere from two to five days, depending on the size of the challenge and when you are testing your prototype you would typically use at least five users. This gives enough variation, and we find user testing with five users, you get repeat results.

At Google we have a saying, with Design Sprints, ‘either you win or you learn’. So if you manage to validate the prototype, then great — you are on the path to creating something that people want. If not, then you have learnt that your team may have the wrong priorities, so even when validating the concept, if it doesn’t work, you have saved yourself maybe six to 12 months time developing and launching a product or service that nobody wants. This allows the team to learn about the challenge they face and pivot.

Design Sprints also serve a second purpose. They help the whole team empathise with one another, creating an environment where the whole team has a stake in the thing you are trying to build. This creates a team that works together for a common understanding and improves the respect they have for one another. It also gives designers a chance to show that your job is more than making things look pretty.


Designer Vs Developer can be seen here on the Youtube Chrome Channel. You can also listen to a longer version of the conversation by downloading the podcast here.

Designer vs Developer #2 

Designer vs Developer #3 

More from CR

Designer vs Developer #3: how the language of print is limiting design for the web

Designing ‘pages’, ‘articles’ and worrying about what sits ‘below the fold’: most of the language we use to describe content on the web is derived from print. Would new terminology help free us to exploit the web’s full potential? asks Google Design Advocate Mustafa Kurtuldu in the third episode of his YouTube and podcast series aimed at improving understanding between designers and developers

Artworker

NAO (National Audit Office)