Web App

WellMetrics Event Planner

Web tool for ADURO Clients, Account Managers and Event Managers for creating, requesting and scheduling biometric screening events.

Role

Research

UX Design

Problem

ADURO's Wellmetrics business offers biometric screenings to clients to measure employee health. As the business grows and matures, we face challenges with scaling. In this project, the process of clients scheduling these biometric screenings was identified as becoming unmanageable. Massive excel sheets with multiple drafts and versions were being passed around between clients, account managers, and our Wellmetrics event managers.

In this project, I addressed the following question:

How might we design a web based tool for ADURO Clients, Account Managers and Event Managers that improves the current workflow for biometric screening event scheduling, while building the foundations of future event planning functionality?

I faced two significant challenges with this project:

  1. The whole project could only last 12 weeks for research, prototyping, development, testing, and deployment.
  2. Identify key MVP functionality, and design a tool that future capabilities could be built into.

Research

Understanding the current workflows and opportunities

The first step was understanding the currently process, identify stakeholders and responsibilities. We established three primary stakeholders early on: Clients, Account Managers and Wellmetrics Event Managers.

The old workflow had clients submitting event requests on a complicated, messy Excel sheet to their Account Manager, and they would email back and forth until the Client was satisfied. Next, the Account Manager would pass the Excel document to the Wellmetrics Event Manager who would check to see if these dates were possible to accommodate, based primarily on equipment availability and staff availability. The issues were sent back to the Account Manager and communicated back to the client -- this would occur in a loop, with sometimes hundreds of events to keep track of. After the error prone communication was settled, the Client would digitally sign off on the order and the Event Manager would schedule the events manually. With hundreds of events a month, the sheer volume of work, errors, and frustrations compiled.

Revising the workflow

We recognized that with a proper submission and approval system, inclusion of the Account Manager was typically unnecessary. Additionally, if we had an approval process from the client, we wouldn't need to use third party digital signature software. Below became the new standard workflow, and capabilities per stakeholder.

Stakeholder goals and capabilities

Client

  1. Schedule Wellmetrics events
  2. Submit change orders for scheduled events

Event Manager

  1. Manage and approve submitted events and change orders
  2. Act on behalf of client if necessary

Account Manager

  1. Schedule Wellmetrics events
  2. Submit change orders for scheduled events

Ideation and prototyping

Due to our expedited timeline, we had to focus on creation and stakeholder buy-in as quickly as possible. After hitting the ground running by sketching some very basic ideas and information to be included with the product manager, I jumped into low fidelity interactive mockups with Sketch + Invision to establish new workflows and review with stakeholders. Due to our expedited timeline, we had to focus on creation and stakeholder buy-in as quickly as possible. After hitting the ground running by sketching some very basic ideas and information to be included with the product manager, I jumped into low fidelity interactive mockups with Sketch + Invision to establish new workflows and review with stakeholders.

Initial collaborative sketch

By working through possible layouts and information needed to be included with the product manager, we were able to synthesize the information we had been collecting. It may not look pretty, but it was instrumental in aligning vision!

Low fidelity mockups

Transitioning away from submitting 100+ events at once for the entire year brought with it the effect of allowing a rolling event submission for our clients. I was excited about this opportunity and tried to design around that shift in paradigm, offering an interface that emphasized each event was individual and could be dealt with on its own. I learned through evaluating this prototype that actually lead to a clunky experience for clients with hundreds of events. Also included in the low fidelity mockups that did not make their way into the final version is cost estimation per event – What seemed like a straightforward pricing model actually was dependent on many factors we deemed too time intensive to work through on the MVP. However, the feature received great feedback, putting it on the roadmap for future iterations.

Design and documentation

After rounds of feedback, I had a good idea of what the final design should look like. Taking that into account, I created a design guide for developers to follow alongside the high fidelity mockups for final revisions and developer communication.

Documentation

My design guide includes layouts, components, buttons, object styles etc. I used Invision as the primary way to communicate workflows, so if necessary developers could use the "inspect" mode that allows checking of colors, text styles, spacing and more. I used the guide to document patterns and all possible styles to avoid requiring hunting through individual screens. This communication was important because our development team is in Vietnam, making communication challenging.

Visual Design

I made the final designs in Sketch, and used Invision and Flinto to communicate important interactions to stakeholders and developers. I used colors and typefaces from ADURO's brand guidelines while being fluid with the rest of the design.

Final word

This project was driven by constraints, beginning with the limited timeframe and resulted in a challenging scope reduction exercise. I just a few weeks to do research, create prototypes, test, and create and communicate the first version of the final design spec. It took careful planning to figure out what needed to be done now and what could be done after development had started – including The success of this project is entirely due to thoughtful planning and intense collaboration across all involved departments.

In the end, we have a tightly focused MVP to begin adding more capabilities to, like integrating stock, staffing, and automated scheduling.