Just Make It Look Pretty…

The assumption that designers and developers sole role is to either make things look pretty or to be a cog in a machine with no soul.

Making this article look pretty with a pretty image by: Joanna Kosinska, on unsplash.

NOTE: This article is based on a conversation I had with Jake Archibald for a new youtube series called “Designer Vs Developer”, which you can see here on our Youtube Chrome Channel. You can also listen to a longer version of the conversation by downloading or subscribing to our podcast on iTunes or Google Music.

I was super excited. 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…”.

"I could finally call myself a “Designer”."

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 designers 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.

"Design, to me has always felt like a part of who I am."

Sometimes I do think we are our own worst enemy, because the privilege of doing what we do we gives us a 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.

A sprint involves all of the stakeholders in a team, from marketing to engineering, typically 5 to 8 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 5 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 program 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 2–5 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 6–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.

"This creates a team that works together for a common understanding and improves the respect they have for one another."