📹 New! Remote User Testing - Get video + voice feedback on designs and prototypes
Read more
Viewpoint

Designers & Developers: Collaborative Design Process for Innovation

Posted 7 years ago by Anna Iurchenko
Designers & Developers: Collaborative Design Process for Innovation

The journey from a basic idea to a great product requires clear communication and close collaboration between design and development teams. In this post we are discussing why and how engineers should be a part of the design process, how to create shared understanding and how to build a better design and development culture.

This post is written in co-authorship with vixentael, iOS developer @Stanfy.

Non-collaborative design process

Let’s take a look at the usual, non-collaborative design process. It probably will look very familiar to you.

  1. Research phase. The designers, start by diving deep into the problem space, conducting interviews with stakeholders and potential users, and studying competitors. Developers don’t do anything.
  2. Analysis. Once designers have collected all the data they try to make sense of what they’ve learned from the research. They identify key themes and start looking for meaningful patterns and brainstorming solutions. Developers continue not doing anything.
  3. Implementation phase. Designers start making ideas tangible by creating prototypes. Hopefully they share them with people, get feedback and improve them. Developers still don’t do anything.

At some point, when designers are satisfied with what they have created, they are ready to move forward to the development stage. This is when they meet developers.

So, designers come to engineers with mockups, explaining why they designed what they designed. And developers start to criticize their ideas, asking questions, suggesting new ideas and saying that something will take AGES to implement.

I bet you have been in this situation!

This approach has several downsides.

  1. Designers’ ideas may be difficult to implement
  2. Designers are unaware of technical possibilities that can make solution better.
  3. Developers feel disengaged because they are just handed the solution and they don’t understand the reasons that brought to it.

As a result you need to re-iterate your design decisions, include ideas & limitations that you heard from engineers and spend more time working on your mockups.

So you waste your time working on a solution that is not ideal and your developers are sad.

No one wants that, right?

Collaborative design process

Let’s see how engineers could be involved on the different stages of the design process to build successful products together.

Research

Every project at Stanfy starts from the design research. It helps you to answer questions and make important decision about the product and the business model.

We need to understand the people we are designing for, their needs and current behavior, the context in which they will use the product — and then use this insights to create a meaningful solution for them.

This means conducting user studies that involve your potential users, not just discussing the project within your team, but reaching out to real people who you think will be your users.

Research usually consists of three parts:

  1. Define your research goal and questions. First think about what you are trying to find out, and what you want to learn. Researching your goal and asking questions give your research meaning and they determine the result you will get.
  2. Plan and prepare. After we have identified what we want to find out, we can move on to how. Depending on your research goal and the resources that you have (time, money, people), you can select a type of research. The are a lot of ways to answer your questions and they all have trade-offs.
  3. Collect the data. Typically we want to get to know our users better and assess a potential design solution, so we may conduct multiply studies during the research phase.

While preparation for research may be done by the designers themselves, I am sure you should insist that your engineers join at least 1–2 interviews.

This is what engineers say after joining the research session:

“I didn’t feel that I am just creating an app. I had a feeling that I’m making a useful tool for real people.”
“After talking to older people, I had ideas for new app features, like dynamic font type support.”
“After we talked to children I was inspired to add some animations to the app.”

Interview with the potential user. Google Hangout session.

There are a couple of things you should do to keep your engineers engaged.

Ask developers to take notes.

Instruct them to capture three kinds of things on paper while watching: important insights on yellow post-its, and green ones for ideas or questions. Getting these ideas down on paper will let the team member focus on the rest of the study instead of trying to remember their idea.

Share observation right after the session

Right after the interview have the team sit down and digest the notes immediately with Post-It notes. For example, divide them into groups of “What I heard”, “What I saw” and “What stood out”. We usually spend from 10 minutes to half an hour discussing the interview.

Analysis

Once we have collected the data we gather it all together and look for meaningful patterns.

During the previous, research phase, inviting engineers was an optional, nice-to-have thing. However, in the analysis phase you have to involve anyone who will be designing or coding.

Working together to examine specific behaviors and concerns will help your team to be more informed, invested and empathetic with users from the start.

What you will need:

Analysis is a fun group activity. You get into the room with your team, review all the notes together, make observations and turn them into ideas.

And this is where design truly starts!

Analyzing research data together with the project team Stanfy

TIP: Hang the map in a high traffic area of your workplace. Next to the meeting room or on the way to the bathroom. Put up a sign that says, “What ideas would you add?” with a stack of stickers and a pen. This not only encourages everyone to riff on ideas but also allows everyone to get involved in the project!

Implementation

Our next step is to transform all ideas into product. First we conduct ideation sessions as a team to make sense of what we learned and come up with design principles and UI concepts for the product.

Always involve your developers in the concept sketching and together review design prototype after usability sessions with the user.

In fact involving your engineers in the interface sketching is really useful. First of all , you will get more ideas of how things could work and second , you will hear their prospective on technical limitations or opportunities right away.

Collaborative sketching session at Stanfy

Throughout the whole design process try to share the ownership of the project with your team. When everyone is involved, they become more proactive.

For example, developers may come up with ideas on how to improve or change some components. Or suggest things that are easier to build (like using 3rd party libs may save time).

During implementation phase we usually iterate on the design prototype through a series of usability tests until we come to the final solution. You don’t have to invite engineers to this validation session but always share the summary of what you learned.

Here you can see the summary of the tests and the votes of the developers on what they think is the most significant problem to address in the first place.

For example you can describe key observations or ideas on the sticky notes (here I use virtual whiteboard) and invite engineers to vote for the things they believe to be the most crucial.

Fragment of the summary after the usability testing sessions (Mural)

Next steps

If you are a designer, engage developers in your user studies and involve them in your design decision process.

If you are a developer , try to find ways to be involved into design process. You don’t have to be in on every research session but you have to know your users.

Designing together helps everyone to be more informed, invested and empathetic with users from the start.

So, ideally the design process should look like this.

There are a couple more things that we have implemented at Stanfy that we would like to share. They can make your team work even more effectively and also have fun.

Move into one room

Stanfy project team. Engineers and designers in one room.

This helps designers to become more educated around dev topics and vice versa. Of course, developers can more quickly clarify any design question or suggest an idea. Small talks and informal discussions lead to cool and unexpected ideas!

Create design+dev channel in Slack

Here we post interesting stuff about anything that helps each of us to become better in design.

Have fun at retrospectives!

Drawing retrospective meeting at Stanfy

We are big fans of drawing retros! For example, here everyone draws a visual representation of themselves during the last sprint. We had a fun and quite productive discussion around our processes and what can be improved.

And we even had a plasticine retrospective :).

Creative retrospective meeting at Stanfy

I will share tips for such fun retrospective formats in another post. Stay tuned!

If you like sketches in this article and you are a visual thinker — check my Hand Drawn Product Design Tips series.

This article was originally published on Anna's Medium page.

Anna Iurchenko leads design practice at Stanfy, San Francisco based design and technology studio.

Related Posts

Making good component design decisions in react when it’s hard to see how an existing component can still be reused

Disney’s 12 Principles of Animation is one of the inestimable guides when traditional animations are considered. It was put forth by Ollie Johnston and Frank Thomas in their book – The Illusion of Life. These principles were originally designed for traditional animations like character animations. However, these principles can still be applied in designing interface animations. So, this is just… Read More →

Design is no longer subjective. Data rules our world now. We’re told all design decisions must be validated by user feedback or business success metrics. Analytics are measuring the design effectiveness of every tweak and change we make. If it can’t be proven to work in a prototype, A/B test, or MVP, it’s not worth trying at all. In this… Read More →

Categories