Summary
When asked to define what it means for our users to be engaged, our product team started with defining what an engaged user should be doing within our mobile app. One of the actions we defined as what an engag on was that users should be engaging with our mobile dashboard.
Discovery: Google Analytics, user interviews, field observation.
Solution: The solution included surfacing the most important information, allowing users to search for projects on the dashboard, and adding the ability to work offline.
Design: Ideation session, two rounds of ideation, two round of testing.
Outcome: 206% increase in unique dashboard usage.
Overview
Team: Product Manager, Co-designer, Developers, Sales, and Users
Role: Research, Facilitation of Design Session, Wireframes, Design, Prototype, and Usability Testing, Acceptance Criteria, User Stories
Outcome: Updated Dashboard
Timeframe: 2 Months
Research: 5 users
THE Hypothesis
We believe that a dashboard exposing the most important information Will result in a better mobile experience For our field users because analytics shows that few users take advantage of the dashboard and the user interviewed reported that the dashboard was overwhelming and not helpful
Discovering the problem
Google Analytics
Upon investigation of the analytics, we discovered that we only had 378 unique actions on the dashboard, which was way below what we had assumed, so we decided to dig into what our users needed by conducting user interviews and field observations.
User Interviews
I conducted five user interviews and observed two different teams in the field. The following were the top issues I discovered:
Data Usage
Users were worried that too much data was being used by our software and that they were worried that the documented work wouldn’t be saved if they lost data connection.
Searching Projects
While observing users on mobile device, I noticed the first thing they did was to use the bottom navigation to go to their projects page to search their projects, they weren’t even looking at the dashboard. It was just another click for them.
Checking on Issues
When I asked users to tell me about their day, they all said they looked for emails, texts, and phone calls to see if they had received a punch list, or a list of items that were forgotten, or completed rejected by their construction manager.
Overwhelming or Useless Information
When asking interview questions like, “what does your typical project assignment process look like?” I learned that their jobs were awarded to them in the beginning of the year, so seeing that they had 2,000 tasks to complete was useless and overwhelming.
design session
After we discovered the most important information to include on the dashboard, I facilitated a design workshop which included our product team, sales, a developer, and an outside participant.
The design session included the following exercises:
Sharing ideas
Co-Design
Presentation of ideas
Synthesizing data
Sharing research with the participants
Set goals for the session
How might we statements
Individual sketching
The solution Proposal vs. What was developed
After presenting a collaborative sketch to our stakeholders based on the ideas generated from the research and ideation sessions, we were told that they loved the design, but that some items on another feature came up, and they had to take some of the velocity from this project had to be allocated to another one, so we had pare down on our features and compromise on the MVP of others. The following were the proposed vs developed items:
Offline Mode
Proposed: Our users are often times without data, and typically are responsible for paying for their own data usage, so we proposed the ability for our users to work in in offline mode.
Developed: To save some work, we allowed for favorited projects to be cashed for offline mode.
Load Projects by Proximity
Proposed: We wanted the projects that were closest in proximity to the users to be filtered to the dashboard and top of project list.
Developed: Because this included the ability for our app to geolocate, we weren’t able to get this in. We decided to allow our users to manual favorite projects to filter projects to the beginning of the projects list.
Searching Projects From the Dashboard
Proposed & Developed: Finding and working on projects seemed to be the most important task when on the mobile application, so surfacing a search of projects was approved.
Creating a Rejected Tasks Button
Proposed: Because users want to take care of any issues first thing, we surfaced the rejected completion steps on the dashboard.
Developed: Because logic had to be changed to separate completion steps from tasks, this was a ver heavy lift, so I proposed that we could flag In Progress tasks with a count of rejected completion steps within them.
Taking Away Unimportant Information
Proposed & Developed: In order to help users see what they were working on and projects that had been assigned to them, we wanted to only show the tasks most relevant to them.
Redesign of Dashboard
Proposed: A full redesign of the dashboard with a totally updatedUI.
Developed: Because the a new design didn’t directly affect our users or functionality, we decided to make small changes to what already existed.
Filters State Saved on Dashboard
Proposed: If a user filters project on their projects list, it will be reflected on what shows on the dashboard.
Developed: This did not make MVP.
Outcomes
Three months after the mobile dash was deployed, the use of the dashboard skyrocketed from 378 unique actions to over 1,150 unique actions - a 206% increase in usage.
Feature Retro
What went well
Use of the dashboard went up and exceeded our expectation.
Thinking creatively on how we could surface rejected tasks without adding a massive amount of scope, but still alerting users that they had rejected items on the dashboard.
Using the ability to favorite a project to enable users to work offline.
Great design workshop with people from throughout our company as well as a guest.
What could have been better
Asking more questions with our stakeholders, product manager, and developers, and understanding scope before the ideation session.
Better animations and feedback of favoriting projects actions.
Better communication with implementation when rolling out favoriting, and how that allowed users to work offline.
What we’re doing different
So we didn’t waste time over designing in the future, I implemented a pre-elaboration with developers and product manager to ensure we understood scope.
I am currently working along side our developers to create documentation on a better handoff process and ways they can take animation .json files and plug and play them into our code base.
As of this past quarter, we are creating animated release notes with how new functionality works. We have also hired a customer relations person to close the loop on user feedback, so they know when things they’ve requested are developed.
