{"id":12087,"date":"2017-03-20T17:17:10","date_gmt":"2017-03-20T17:17:10","guid":{"rendered":"http:\/\/blog.intercom.com\/?p=12087"},"modified":"2020-07-30T12:58:02","modified_gmt":"2020-07-30T11:58:02","slug":"design-principles-what-to-do-when-nobody-is-using-your-feature","status":"publish","type":"post","link":"https:\/\/www.intercom.com\/blog\/design-principles-what-to-do-when-nobody-is-using-your-feature\/","title":{"rendered":"Design principles: what to do when nobody is using your feature"},"content":{"rendered":"

When we released our new messenger last year, we added the ability for customers to create rich, personal profiles so their users would always know there\u2019s a real person on the other end.<\/p>\n

The problem? Nobody was using the feature. Shortly after release, only 13\u201315% of customers had fully completed their profiles<\/strong>. Most were being partially filled in while many others were left untouched.<\/p>\n

An example of a partial and fully completed profile<\/em><\/p>\n

After talking with colleagues on our research and analytics teams, we uncovered two primary reasons for such low adoption:<\/p>\n

    \n
  1. Visibility<\/strong>. The ability to create your profile was tucked away in low-visibility places throughout the app.<\/li>\n
  2. Education<\/strong>. People were unconvinced of the importance of profiles in establishing a personal relationship with their customers.<\/li>\n<\/ol>\n

    One part of a wider solution<\/h2>\n

    Profiles lived across many parts of the Intercom product which meant that we had to involve many teams to increase adoption. The growth team integrated profile creation into our on-boarding flow, while product gave higher visibility to profile editing within Intercom itself.<\/p>\n

    However, there was a huge opportunity to increase engagement by taking advantage of our mobile apps. Around 45% of teammates who talk with their customers (using our Inbox<\/a> product) use either the Android or iOS app.<\/p>\n

    Getting started<\/h2>\n

    For every new project, designers at Intercom create a simple list of high-level goals that reference the problem they’re trying to tackle. This helps guide you when thinking of high level solutions. Ours looked something like this:<\/p>\n

      \n
    1. Raise adoption<\/strong> for users who have not completed or partially completed their profile.<\/li>\n
    2. Educate users<\/strong> on the importance of public profiles.<\/li>\n
    3. Make it easy for users to edit their profile<\/strong> at any time.<\/li>\n<\/ol>\n

      Thinking in systems<\/h3>\n

      To start off, we took the profiles apart\u00a0to help the team understand the system\u00a0and to decide which specific components needed priority. That meant mapping out an inventory of parts, states, rulesets, etc. Here’s an example of something that would have been up on the wall in our war room.<\/p>\n

      <\/p>\n

      Ideas come from anywhere<\/h3>\n

      These system docs helped the team\u00a0discuss technical constraints early on, and even at this early stage the engineering team was offering suggestions that the design team<\/a> might not have thought of. For example, someone mentioned that we could\u00a0draw from existing data sources to pre-populate certain components within the profile. Since we have a person’s name when they log into the mobile app, why not carry it over to the profile and save them the time of manually entering in that data?<\/p>\n

      After sketching out a few directions, we met with Emmet<\/a>, our Director of Product Design, to get feedback and decide on next steps. Here were the four options that were presented:<\/p>\n

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

      The crucial ingredients here were disruption and education. We didn\u2019t want this to be too easily dismissible, and we needed room to properly educate users on the importance of the profile and each of it’s components. However, we knew high disruption meant more aversion (i.e. users wanting to skip), so we wanted to keep the number of steps within any walkthrough as low as possible.\u00a0In the end, we decided to go with the simple walkthrough option.\u00a0 Below are the decisions from the meeting. Progress!<\/p>\n

      <\/p>\n

      Designing the solution<\/h2>\n

      At this point, we had decided two things.\u00a0We would add a simple walkthrough to our app on startup which would ask for any missing profile components to be filled in (disruption and education).\u00a0Our third goal was adding the ability to “edit your profile from anywhere”. We decided to work within our current navigation pattern and add a simple edit icon within the nav drawer which would trigger the walkthrough.<\/p>\n

      Note: <\/strong>One of our core values here at Intercom is \u201cthink big, start small\u201d. We had been planning a navigation update for a while at this point.\u00a0Moving from the drawer to the tab bar would be great for a variety of reasons, but would have been a ton of effort engineering wise at the time and we needed to ship fast.<\/p>\n

      \"\"<\/p>\n

      Current navigation (left), planned navigation (right)<\/em><\/p>\n

      At a system level, we established three states for users which would dictate their position within the walkthrough. From the chosen high-level direction, we knew that\u00a0the the flow\u00a0would consist of three primary steps (see diagram below) which we wanted to make as easy and lightweight as possible.<\/p>\n

      <\/p>\n

      Walkthroughs are pretty straightforward in terms of system design. They are a fixed pathway from beginning to end, but the logic gets more complex when taking user states into account. We\u2019d want you to skip straight to the most relevant part instead of forcing you to go through the entire walkthrough. It’s also very important to consider platform specific steps such as camera permissions. Not every step is a new screen.<\/p>\n

      Again, these diagrams were printed out and put up in our war room. Engineers\u00a0would often be at the wall scouring through the flow, and a few times they would spot an edge case that would require us make changes together.<\/p>\n

      \"\"<\/p>\n

      Final flow for the walkthrough<\/em><\/p>\n

      Execution<\/h2>\n

      By now we had the skeleton to start fleshing out each part. Visual and interaction design happened simultaneously, with the knowledge that we\u2019d continue to tweak visuals as we build.\u00a0We’ve found that finalising the details around any complex interactions or animations should be done as soon as possible (which is why high fidelity prototypes are great). It’s much harder to change\u00a0these later on as opposed to visual design tweaks such as updated assets, colours, etc.<\/p>\n

      We used Framer JS<\/a> as a way to prototype early interaction ideas, discuss with engineering and agree on what could be done. Here\u2019s an example of our final iOS flow after around 12 prototypes.<\/p>\n

       <\/p>\n