Equipment360 Mobile Mechanic Redesign

Redesigning an iPad application used by mechanics, managers, and foreman to add and carry out work orders on equipment that require repair, maintenance, replacement, etc.
Due to a non-disclosure agreement, I am unable to publicly discuss this project any further than the information provided and I am also unable to provide further visual design work, at this moment.

For such situations, I have created design slide decks that I can share with recruiters and interviewers when requested. Please reach out to me at

UX Designer and User Researcher at HCSS



Google Docs and Sheets



May 2019 - July 2019



User Research

UI Design


Problem Statement
Conduct research on the current users of Equipment360 and find out what are their pain points regarding the application and report the findings.

Identify and fix all user workflow issues, eliminate unnecessary functionalities and improve the usability and efficiency of the app, and also look for opportunities to add new functionality.

Reduce the clutter in the existing UI of the app and add marketing specific brand colors to make it look modern.
This was my first time ever working with another UX designer intern, Isabel, on a large-scale redesign project. We divided our design tasks, worked collaboratively, and we were able to meet the desired business goals and deliver high fidelity prototypes.

Besides working with another designer, I also got the experience of working directly with stakeholders like Project Managers, Developers and QAs. They were the subject matter experts (SMEs) of Equipment 360 and were always there to provide constructive feedback on our designs.

To improve efficiency of our design tasks, I also came up with a "reusable component"-based styleguide using Figma. Throughout the project timeline, I was in charge of maintaining consistency of our styleguide. If my partner made any changes to the components on the screens she designed, I had to make sure the original component in the styleguide was updated as well.

The project also made me understand just how important a Customer Service team can be. They were our source for user research because they were always on call to answer every customer question.
Scopes and constraints

We were given a timeline of three months. We also had to be very careful with the screens that we built, as anything that looked like it would require more development time would not be built at all.

We were not able to directly interview the users. So we did secondary internal research with Customer Service Specialists, Software Trainer and subject matter experts

From the start of the project, we were told that our designs would not necessarily reflect what the final product will look like.

Prototype Overview
Here are some screengrabs from Figma that showcases our component system and the interactions between each screen for a particular function.

I was the UX Design intern at HCSS when I was assigned this project. My primary responsibilities included user research, wireframing, and high fidelity prototyping.

This was a collaborative project as I was paired with the new UX Design intern, Isabel. She took the lead on the user research portion as she was more experienced at it.

We collaborated on the design heavy tasks as well, such as wireframing, building and updating the style guide for the project and creating high fidelity prototypes.

We also took turns running design review meetings with key stakeholders such as Product Manager, Lead Developer, and QA specialist.

User Research
We conducted internal user research. The Product Manager and Software trainers are always in contact with the customers so they were able to provide us with the information we needed.

The Customer Support specialists are interacting with the customers the most, listening to their every feedback and complaints. A bulk of our research data came from them. We discovered a few key facts about our users:

  • Most are less hands-on with equipment work orders.
  • Their job is to keep track of work orders and ensure smooth work flow at construction sites.
  • Depending on the size of the organization, there would be Manager-Mechanic hybrid because of lack of personnel.

  • Identify work orders for equipment on construction sites and carry them out.
We also discovered that age was a big factor. The younger mechanics were more tech-savvy and would use the Equipment360 application as they completed their work orders.

The older mechanics with less technical experience would rely on pen and paper as much as they could and would enter all their hours and work order information at the end of the day.

We showed our findings to our senior Designers, and the Product Manager, Lead Developer, and QA specialist for Equipment360. to determine that we were focusing on both the business and the user needs. From there on, we would set up weekly design review meetings, sometimes 2-3 times a week, to make sure we were on track with our visual design work.
My partner, Isabel, and I were given two iPads with the Equipment 360 app installed and we started playing around with the application. We made a list of all the issues we came across.

Isabel was pursuing a Cognitive Sciences degree and introduced me to research and interview techniques that we were able to take advantage of, such as the Nielsen-Shneiderman Heuristics, a tool for evaluating product usability. It helped us identify key functions of the app that we needed to fix.

As a way to better understand the software and its uses, Isabel and I also had a session with one of the software trainers. These learning sessions are offered to clients when they purchased a software license, so we got to understand the process.

We also cross-checked our findings with the Customer Support team. We did not have direct access to the customers, so they became our user proxies. They had the most access when it came to customer feedback.

We were able to then determine the critical aspects of the application that we should focus on solving. We also had access to user insight thanks to our other key stakeholders; Product Manager, Lead Developer, and QA Specialist.