Rhumbix Time Card

Role:

I led the UX and visual design, which included collaborating with our Design, Engineering, Product, and Construction Teams in order to ship.

BEFORE: RHUMBIX WEB APP MVP

When I first started with Rhumbix, they had built and designed a strong mobile app to help increase productivity on the construction site. Workers would record their hours and field data on their mobile phones, and send it directly from the job site to the main office. By making the delivery of this data to the construction office faster and easier, administrators could save time by avoiding re-entry of paper forms and managers could make more informed project planning decisions.

Along with a mobile app, the team had also already built a web app to display workers' hours; however, the app only showed total hours for each worker. We needed to update our web app to reflect our ability to capture an hourly breakdown by specific task, or cost code, which was valuable to administrators and decision makers.

In order to solve the problem of how we would display time cards in our web app, I worked with the team to first understand the problem and users, ideate possible solutions, refine, implement and then iterate on finished designs.

Process

Understand:

First we needed to understand and define the problem. As more features had been added to the mobile app, we were able to collect data that needed to be shared with our administrative users through the web app. We defined the problem simply in the voice of one of our users: 

Early on we had a team meeting with our Product Manager and Construction Team to identify who we considered 'administrators' and what information each user needed to see on the web app. We identified these three main user groups:

Ideate:

After we had identified the core users, I started thinking about the visual design by looking at what and how our current app and existing paper time cards displayed data. From there, I made some quick sketches.

Design Decision: One of the things I wanted to experiment with was how to represent the breakdown of hours into straight, over, double, and total time. This distinction is important to communicate since it affects a worker's pay rate. I was inspired by how the cells of the periodic table present information in a clear and structured hierarchy, and tried to apply a similar structure to a time card.

With some ideas generated from my sketches, I started to play around with different ways of displaying data in low fidelity wireframes. I shared these early sketches with the team for their feedback.

REFINE:

Based on initial feedback from the low fidelity wireframes I continued to refine these layouts. I continued to explore how to represent the data from the time card in ways that were easier to parse. One key idea that was surfaced during this time was that on paper you could see all of the information at once, whereas the screen allows you to conceal and reveal information to your user as necessary.

Design Decision: With this in mind, I tried to reduce the visual clutter of a paper table by only showing workers' total hours and defaulting them to standard time unless a worker had worked extra hours. In that case, I would show a breakdown of straight, over, and double time below their total. I also used typography to develop a visual hierarchy depicted in a key rather than label every field on the table. 

These refined mockups were again shared internally and externally with early stage partners for feedback by our Sales and Product Teams. 

Implement:

Once we had a pretty solid framework in place with the wireframes, I shifted my attention to higher fidelity visual designs. Since hiding and revealing information to users would be an important component of this design, I used InVision to share these interactions in a prototype with the engineering team during our final conversations about implementation.

Released Design:

Features

Notes

Workers are able to record notes and photos from the field which are displayed as a part of the daily time card on the web app. 

Test/Iterate:

Before and after developing this feature we met regularly with potential customers and early stage partners to collect their feedback and insights. One of the things that we left out intentionally, but knew would be important to users, was the ability to edit and correct mistakes on time cards using the web app. We were able to build in this functionality when we introduced editing to daily time cards on the web app. 

Summary & Lessons Learned

One of the successes of this feature was that we were able to show data in different views depending on the user's choice and role. This is something we continued to receive positive feedback on from customers and has remained relatively untouched since its release. I attribute this fact to defining our users and their different needs early on in the design process. We also worked closely with our Customer Success Team and Product Managers to continue incorporating user feedback into the working design of the web app views.

After this update had launched, there were also some things I would have done differently. First, I would have made the table more dynamic and scalable. We saw situations and edge cases that we had not anticipated such as: cost codes that were twenty characters long, crews who only worked on one cost code a day (which caused the table to looked strange or unfinished), or the opposite where crews would work on twenty cost codes a day which required that we make the table scrollable. Continuing to talk and work with members across the teams helped me to keep improving and refining the daily time card.