AgileAssets, needed a mobile app to provide access to key features of their browser-based Roadway Maintenance product. Most road crews were scheduling and recording work done in the field with pen and paper. Info gathered was entered into the main system back at the office at the end of the day, often by a clerk, who was not at the work site. A mobile app greatly reduces the likelihood for errors, or failing to record tasks, which is common with a paper-based processes.

A small group, made up of product managers, designers, and subject matter experts (SMEs), worked together to understand user needs, prototype & test solutions, and work with developers to implement a functional app.

After gathering an initial understanding of the work order process from internal subject matter experts, UX lead teams went to several client locations to see how they worked. Through a combination of ethnographic observation, contextual inquiry, and round table discussions; we gained a deep understanding of user needs, and empathy for the pain points they experienced.

I, and another designer, were accompanied by other team members on these visits. This assured that everyone connected with customer issues by directly interacting with the people that use our products.

In this way, the team came to a collective understanding of, and investment in customer needs through shared experience. I've found this more effective than the handoff of a design spec to a development team to build.

The Crew Leader (named Gibson) was the primary persona defined, based on field research. Relevant identifying characteristics of that persona include:

• Strong sense of community: Many DOT workers expressed pride in, and commitment to safety in their community - similar to first responders. Because of this, they see time with digital devices as a distraction from their primary responsibility.
• High mechanical aptitude: DOT maintenance workers fix things, often with limited resources and guidance. They are problem solvers, primarily in the physical world, but will apply that skill to software when needed.
• Love and respect for the outdoors: DOT crew workers did not take the job to be in an office, in front of a screen. They enjoy being on the road, in all sorts of conditions. Conditions that are not always conducive to digital devices.
• Late technology adopters: The Crew Leader persona is not averse to digital technology, but they are conservative consumers of it. They are often a few generations behind the latest hardware and software. They are also unlikely to be familiar with mobile features, and gesture navigation options.
• Middle age male demographic: Many crew leaders are 40+, and predominantly men. This influenced considerations about eyesight (reading vision & colorblindness), as well as dexterity with mobile devices, due to large fingers, and hand fatigue from manual labor.

After spending time at several DOTs, several common and essential features stood out.

• Offline operation: DOT workers in the field cannot count on an internet connection. Our app functioning offline was a must have.
• Map based interface: Workers think about and manage what they do based on location. Everyone wanted to be able to see and interact with work on a map.
• Cross platform operation: DOT crews have little influence over the mobile devices provided to them. Android, iOS and Windows all had to be supported, with a near identical user experience.
• Responsive UI: DOT workers want to be able to manage work in the field with a smartphone, tablet, or notebook. Our app needed to responsively optimize its layout for each format.
• Show user's tasks: DOTs are large organizations. Our app required authentication to show only the tasks and functions appropriate for each user.
• Quick input of work: If it takes minutes to enter work info, people are more likely to skip it. Our goal was to log work in under 30 seconds or less.
• Fast sync: When syncing a mobile device to the main system, we need to only update what's changed, to make that process painless for users.

With the learning gathered from user research, the team used design techniques to model, and validate their understanding. Early on, we created a story map of the end to end work order process. From that we identified those user activities specific to mobile (our immediate focus). This let us see where mobile fit in the big picture, and identify the incoming and outgoing channels for a mobile app.

Next, I lead the team through sketching, storyboarding, and other gamestorming exercises to generate ideas for a potential product. Our goal was to rapidly come up with and explore lots of possibilities. As key concepts emerged, we validated them with internal SMEs and users, to assure we were on the right path - and correct course as needed. This gave us confidence in our understanding of the problem, before jumping too quickly to a solution.

Rough sketches quickly evolved into wireframes. These let us experiment with, and test page layouts, navigation mechanisms, and workflows. I create clickable prototypes early on, which we used in formative user testing sessions (mostly conducted remote, via online meeting). That allowed us to iterate and refine aspects of the design that needed improvement. Meanwhile, in parallel, the team conducted technical investigations, built out system infrastructure, and implemented UI features the team had reasonable confidence in.

With each testing iteration, prototype fidelity increased, and implementation advanced, until we were mostly testing and iterating on the pre-release product. With this, we were able to evaluate map interactions, object crud operations, performance parameters, and other important aspects of the product experience that could not be readily simulated with a prototype.

Early in 2017, AgileAssets released the Work Manager app. This is their first cross platform app (prior apps were iOS only), developed using Xamarin, to speed the implementation process. Design patterns and technology pioneered in Work Manager laid the groundwork for additional AgileAssets Mobile Solutions.

The app functions 100% offline, except to sync. This assures it always works, and performance will never vary, based on connection speed. When users sync, data packets are kept to a minimum, only transferring what has changed. Because of this, most syncs take less than one minute to complete.

With this app, users can see their work on a map, and as text, in both lists and forms. In just seconds, DOT workers can add, edit, and delete information, such that they track what they are doing, as it happens. This is a huge advance from the error prone, paper-based process many had been using.

The Work Manger app leads the way in a new mobile centric direction for AgileAssets operational product line.

At AgileAssets, we identified a demand for a mobile companion to our browser-based Fleet product; one specifically targeted at shop mechanics working on vehicles and other equipment. Mechanics wanted a way to quickly see maintenance required on a vehicle, view past history, and log new work from the shop floor, out on the repair lot, or from an offsite location.

Many DOT shops have one or two shared laptop or desktop PCs in an office area, off the shop floor. This makes it inconvenient to check information during a repair. A mobile app would help with that problem. It also provides use of the device's camera, which can be used to scan barcodes, and take photographs as part of a repair order.

I worked with the team (eliciting input from internal subject matter experts, and customers) to draft scenarios, storyboards and other design artifacts that helped us understand the user's point of view on the problem. We regularly showed what we created to stakeholders to test if our conceptual model was correct, or not, and adjusted accordingly.

We also reviewed the data model of our current browser-based Fleet product, to understand what information the mobile app needed to work with.

Taking all this information together, we experimented with page content, layout patterns, and workflow paths until we had an initial plan we we're happy with.

With a first draft plan in hand, we immediately began implementation. Since the current Fleet product lacked what an external mobile app needed to get and set information, the project required significant API effort. While part of the team progressed on that front (using the data model information we identified as a guide), I worked closely with our UI Dev Lead to build out the front end, using simulated back end data.

This process allowed us to prototype in code. We would discuss design direction once or more per day. He would make changes, and I would walk through scenarios, and conduct formative testing with stakeholders on the latest updates. My findings would driver further discussions between myself, the UI developer, and the rest of the team - improving the product with each iteration. In parallel, we would integrate live data as parts of the API were completed; thus, avoiding a big (often bug ridden) integration stage at the end of the project.

In late 2015, AgileAssets released their Fleet Maintenance Manager mobile app on iTunes.

Quoting from the iTunes app store description for Fleet Maintenance Manager

The Fleet Maintenance Manager App enables a technician to view the details of a vehicle with a simple lookup, giving them preventative maintenance, vehicle details, or warranty information at their fingertips. They can enter information about labor, materials and equipment as they work, which improves visibility to progress while ensuring that you have the latest information on your fleet.

The App is a companion product to the AgileAssets Fleet & Equipment Manager module.

Features & Benefits

• Search vehicles by VIN, name, license plate or barcode scan
• Look up vehicle information
• Add vehicle repair orders
• Modify/Delete non-approved repair orders
• Edit current odometer reading