PROCESS
While every project is different, the process for building a design solution usually follows the same set of steps. The following is a brief study of the creation of a dashboard web app for truck drivers.
01
RESEARCH & PROJECT DEFINITION
Competitive Landscape

Interviews & Surveys
Understanding the client's business needs and pain points is critical to building a contextual framework for developing the ultimate solution. I find that drilling down to find the root causes of a problem is one of the most fun parts of any development work.
​
For this project, the client was struggling with driver dissatisfaction with their driver portal website. While the portal offered all the tools a driver would need to retrieve payroll, mileage, and load assignments, users often avoided using the site, preferring instead to call in to dispatchers or the payroll department to find answers their questions. This usually meant that staff available to speak to drivers on the phone was rarely a match for the call volume coming in to the business.
​
Surveys were sent out to the driver fleet to get feedback on the current portal. We measured the number of visits per week, which tools were most used, and satisfaction ratings on ease of use, quality of information, and how it compared to competitor tools.

Current State
If I'm redesigning an existing solution, I will fully immerse myself in it's current workings. I perform a thorough top to bottom analysis of the existing features and functionality to understand how users interact with the product. Anything the end-user struggles with, I want to experience firsthand.
​
In this case, I was definitely feeling the pain. Frequently used tools were buried under a mountain of menus. All data was presented in table format. Links to outdated company initiatives were sprinkled throughout. And worst, the site was in no way responsive.
​
​

Analytics
Studying usage analytics, whether for a website or an app, provides valuable insight into which parts of a solution are valuable and receive the most activity and which parts lead to user abandonment.
​
We were able to establish pretty quickly which tools the drivers used most often. However, more critically important was the discovery that the overwhelming majority of site traffic was coming from mobile devices. While mobile workers using cell phones to access the site wasn't exactly a divine revelation, it did demonstrate that a mobile-first redesign of the driver portal would go a long way toward improving the user experience.

Competitive Analysis
Assessing competitors strengths and weaknesses can help identify targets for market disruption and features that will attract new users.
​
The competition for driver-facing mobile apps was surprisingly minimal. Visibility into those tools was equally limited. However, this gave the team an opportunity to develop an industry-leading platform for professional drivers to find all the info they needed on the road.

Personas & Journey Maps
Before jumping into design, ​it's critical to take time to understand who is using the product and what makes them tick. Business requirements are important, but building empathy with the people using your design on a daily basis will result in a much more successful solution.
​
The main users of the dashboard would obviously be drivers, but drivers come from all walks of life and have different goals in mind when they pick up their devices. We used digital surveys and in-person interviews with drivers to understand their needs and how they used the existing website. We used those interviews to create a series of "driver personas" and followed up with journey maps of the existing processes to identify opportunities for improvement.
02
DESIGN

Wireframing
I start every design project with a drawing. If I'm working with a team, that means lots of whiteboard sketches. On my own I like a trusty paper notebook. Keeping about a dozen different colors of highlighters or dry erase markers on hand provides for some truly sparkling paper prototyping.
​
Shown here is the initial mockup of a communications calendar containing events that would be relevant to drivers.
​
Using an iterative prototype and test process, I designed individual chunks of the overall portal and met with stakeholders to review the interaction flows and get buy-in on proposed solutions.

Style Tiles
When starting a project from scratch, it helps to get a feel for the colors, typography, and interface elements that will be used and get buy in from the client. Style tiles can be especially useful for developing and maintaining brand identity on a project.

Prototyping
Once I'm satisfied that I have a good hand-drawn concept, I typically move to a high fidelity digital wireframe or prototype. I like to build these in Sketch so that I can build vector graphics which can be reused in the final product.
This mockup represents the initial attempts to conceptualize an interface that organized data scattered across dozens of menus and tables into easy to digest cards. Later iterations continued streamlining the presentation based on feedback from drivers and executives.
03
DEVELOP

HTML / CSS / JavaScript
I take a mobile first approach to web design and aim to keep my work as progressive as possible. I love some good clean markup and can write CSS all day long.
For this project I was the sole front-end developer collaborating with a team of back-end developers to retrieve everything I needed to put on the screen.
​
The front-end of this app was built entirely in jQuery, using AJAX to consume RESTful API's on the back-end.

Graphics, Icons, and Data Visuals
In an enterprise environment where number crunching is king, data visualization is essential for an uncluttered and easy to use interface. However, I've found a well placed burst of animated confetti can be just as important to bring a smile to a user's face. I create most of my visuals in SVG using Sketch, and incorporate them into the web page using imported fonts and CSS.

Collaboration
During the development process it was critical to maintain open lines of communication with the server-side programmers to define data needed to build out the interface.
It was super gratifying to brainstorm ideas with the architectural team, discussing ways to bring my visuals to life and associating data in ways that were never accessible by an end user.
​
For example, a feature that I felt would be extremely useful for drivers was being able to connect past trip records with their corresponding payroll. I developed a interaction flow that would allow drivers to quickly jump from their mileage records to the paycheck where they were paid for them. Drivers were very enthusiastic about the idea because there had never been a way for them to see that connection between effort and reward. The dev team and I worked out a retrieval system and successfully implemented the feature.
04
DEPLOY

Usability Testing
The success or failure of a project largely comes down to how much testing is done. I like to sit down with users and watch them interact with the product. It usually doesn't take long to fill a notebook page with unanticipated bugs and minor UI tweaks. In an agile environment, functionality is deployed a piece at a time so that users can have immediate value while the bugs are fixed and the next feature set is developed.
​
Since the dashboard we created was divided into individual interface cards based on user stories, deployment and testing were straightforward and easy to organize. We ran a series of new interviews with drivers to observe how they interacted with each new piece of functionality and how quickly they were able to perform tasks. We defined those tasks based on their most common "phone home" issues, as well as most commonly used features of the current site.

Iterate
After gathering user feedback and collecting usage analytics, I return to the design stage to adjust layouts and interactions to improve usability. In this case I was also the primary front-end coder, which meant fixing a lot of my own bugs. After several months of iteration we were able to launch the full dashboard to a collection of trusted users, followed by the entire fleet.
05
MEASURE RESULTS

How'd we do?
After deploying the dashboard to the entire fleet, we measured our success based on three criteria:
​
Criteria 1 -
Did drivers use this app more than the old web portal?
​
Results - After 1 month, analytics showed over 800 daily active users on the new dashboard versus an average of 350 on the old portal.
​
Criteria 2 -
Did driver feedback of the app indicate an overall improvement in satisfaction?
​
Results - Surveys indicated a marked improvement in satisfaction ratings, going from an average 2.3/5 rating to 4/5.
​
Criteria 3 -
Did the number of driver support calls go down?
​
Results - After 3 months, the number of driver support calls reduced by 20%. On a side note, operations and payroll staff discovered that drivers now had better information in the dashboard than they had in their own systems!