ESTIMATOR
A tool that manages resource library and determines project cost
Target and Challenge
Scientists from Oak Ridge National Laboratory estimate their project cost in order to apply for research funding. The existing tool had a very complicated user interface, which was not only overwhelming for beginners but also pretty difficult for an experienced user to use. The new Estimator needed to be easily understandable by scientists without any specific finance knowledge, and to be extremely easy to use.
This was a project I started working on since Feb, 2017, first released on Jan, 2018. As the UX and visual designer, my effort was mainly put into creating the overall user experience, redesigning the flow and interface based on qualitative UX research. In the design phase, we spent a lot of time defining "how things work" rather than how things look.
Proposal ways to estimate
Our client came with a clear vision, which was to estimate a project based on activities. It let users to follow a linear flow with the purpose of guiding novice users through a clearly instructed process:
It could be one way to do estimate, but we didn’t know if it fit users’ mental model with exploring on our own. We interviewed researchers in their working environment to understand the context of project estimating. We found that our users:
Would like to estimate efficiently in order to focus on their research activities
Sometimes estimate based solely on resources
Would like to collaborate with co-workers and to get estimate reviewed
Design for flexibility
Based on our findings I proposed 2 different models to show our users different possibilities. One is a Activity-based approach : 1) A non-linear approach allowing users to start with either resources or activities 2) Flexibility which enabled user to create/edit resources on activity screen.
The other model was Resource-based approach by 1) focusing on showing the allocation of each resource across project. 2) allowing users to assign activities to each resource
I took inspirations from tax return apps and explored multiple wireframes for each model through fast iterations. I walked the team through the options. The project manager, data analyst and development teams gave their feedback and rationales. Together we picked one design for each model by evaluating:
Their potential to be developed into a complete user flow
The ability to scale.
We invited users for focus group and presented them our concepts. We were especially interested in their first reactions when seeing the screens.
Our users were leaning towards Model 2, which could better handle the project scale and flexibility in estimating. Meanwhile, we dug into user feedback to see what elements of each model our users liked and the way they pictured themselves using it. We found out a few issues and made them into objectives:
How to walk through the first time users and keep them engaged?
How to enable both efficient and detailed estimating?
How to let users know enough but not overwhelmed with financial details?
I kept working on Model 2, came up with different user scenarios, discussed with the team and nailed the user flow:
Feature Walkthrough
An overview of the application
▍Create Resource Dictionary
Balance between Simplicity and Possibilities
Before designing started, we first sat with finance officers to understand the ins and outs of how a resource cost was calculated. From the experts we understood that a resource could be identified with a default category (w/o unit cost) with the possibility to be customized into a rated resource.
How should we present the possibilities to the users? And how do we balance simplicity and possibilities? While it depends on each individual’s estimating preferences, our goal was to make users: 1) understand the difference and connection between the two types of resources 2) easily pick the type they wanted. I brainstormed for 2 iterations and came to several options:
I built clickthrough prototype for each option. When testing with our users, we asked them to think aloud their reactions, thinking process and actions. We found that:
It was pretty hard to make the design self-explanatory without guidance.
Users were more likely to estimate every a few months instead of daily basis. They might need to learn the tool again.
Therefore it was more critical to minimize the information load when landing on the screen and put customization as a secondary feature. We went for option 2. To ensure a smooth experience, I integrated visual guide to walk people through the process.
▍Estimate Activities
Although timelines are always tight, we believe that we can, and should ship great products. To enable the flexibility in estimating, I designed the full capability for users to create the entire estimate from one place.
Through prototyping and usability testing, I defined edge cases and interaction details through trial and error. It was challenging to create data editing with heavy information load.
Delivering Design
This application was launched by Jan 2018. There were ongoing design requests which led to variations and nuances in the interface. I detailed out the changes, versions and specs for the development team.
Impact
We received continuous user feedback after launching the app. With the old tool users ended up having to contact finances or business partners for guidance about how to do an estimate. The new tool was far more error prone. It also allowed for a guided experience that assisted the user to produce an accurate estimate by themselves with confidence.
TEAM: Ken Lowery, Mike Ellis
MY ROLE: Wireframing, Prototyping, UI
TIMELINE: 02/2017 - 01/2019