{"id":11666,"date":"2017-08-25T10:26:25","date_gmt":"2017-08-25T09:26:25","guid":{"rendered":"https:\/\/marvel7077.wpengine.com\/?p=11666"},"modified":"2018-03-05T10:24:48","modified_gmt":"2018-03-05T10:24:48","slug":"designers-developers-collaborative-design-process-innovation","status":"publish","type":"post","link":"https:\/\/marvelapp.com\/blog\/designers-developers-collaborative-design-process-innovation\/","title":{"rendered":"Designers & Developers: Collaborative Design Process for Innovation"},"content":{"rendered":"

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.<\/p>\n

This post is written in co-authorship with vixentael<\/a>, iOS developer @Stanfy<\/a>.<\/p>\n

Non-collaborative design\u00a0process<\/h2>\n

Let\u2019s take a look at the usual, non-collaborative design process. It probably will look very familiar to you.<\/p>\n

\"\"<\/a><\/p>\n

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

    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.<\/p>\n

    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.<\/p>\n

    I bet you have been in this situation!<\/p>\n

    This approach has several downsides.<\/p>\n

    \"\"<\/a><\/p>\n

    <\/p>\n

      \n
    1. Designers\u2019 ideas may be difficult to implement<\/li>\n
    2. Designers are unaware of technical possibilities that can make solution better.<\/li>\n
    3. Developers feel disengaged because they are just handed the solution and they don\u2019t understand the reasons that brought to it.<\/li>\n<\/ol>\n

      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.<\/p>\n

      So you waste your time working on a solution that is not ideal and your developers are sad.<\/p>\n

      No one wants that, right?<\/p>\n

      Collaborative design\u00a0process<\/h2>\n

      Let\u2019s see how engineers could be involved on the different stages of the design process to build successful products together.<\/p>\n

      \"\"<\/a><\/p>\n

      <\/p>\n

      Research<\/h2>\n

      Every project at Stanfy<\/a> starts from the design research. It helps you to answer questions and make important decision about the product and the business model.<\/p>\n

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

      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.<\/p>\n

      Research usually consists of three parts:<\/p>\n

        \n
      1. Define your research goal and questions. <\/strong>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.<\/li>\n
      2. Plan and prepare. <\/strong>After we have identified what <\/strong>we want to find out, we can move on to how<\/strong>. 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.<\/li>\n
      3. Collect the data. <\/strong>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.<\/li>\n<\/ol>\n

        \"\"<\/a><\/p>\n

        <\/p>\n

        While preparation for research may be done by the designers themselves, I am sure you should insist that your engineers join at least 1\u20132 interviews.<\/p>\n

        This is what engineers say after joining the research session:<\/p>\n

        \u201cI didn\u2019t feel that I am just creating an app. I had a feeling that I\u2019m making a useful tool for real people.\u201d<\/span>
        \n\u201cAfter talking to older people, I had ideas for new app features, like dynamic font type support.\u201d<\/span>
        \n\u201cAfter we talked to children I was inspired to add some animations to the app.\u201d<\/span>
        \n

        \"\"<\/a>

        Interview with the potential user. Google Hangout\u00a0session.<\/p><\/div><\/p>\n

        <\/p>\n

        There are a couple of things you should do to keep your engineers engaged.<\/p>\n

        Ask developers to take\u00a0notes.<\/h2>\n

        \"\"<\/a><\/p>\n

        <\/p>\n

        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.<\/p>\n

        Share observation right after the\u00a0session<\/h2>\n

        \"\"<\/a><\/p>\n

        <\/p>\n

        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 \u201cWhat I heard\u201d, \u201cWhat I saw\u201d and \u201cWhat stood out\u201d. We usually spend from 10 minutes to half an hour discussing the interview.<\/p>\n

        \"\"<\/a><\/p>\n

        <\/p>\n

        Analysis<\/h2>\n

        Once we have collected the data we gather it all together and look for meaningful patterns.<\/p>\n

        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.<\/p>\n

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

        What you will need:<\/p>\n