Context
Machines break, pipes leak, AC units malfunction. When it happens, technicians come to the rescue.
However, managing dozens of technicians across multiple locations can be challenging, especially considering each job comes with unknown circumstances — sometimes they’re a quick fix, sometimes they require additional parts and multiple visits by different technicians.
Makani is a platform that makes it easier to manage all that.
Back-office workers use the web app to manage work orders and schedules. Technicians use the mobile app to receive work order details, request parts, facilitate communication with the back office, and document their work.
The team that built the MVP consisted of a Back-End Developer (who also acted as Project Manager), a Front-End Developer, and a Product Designer. The project was completed in 3 months, and the client — a general manager at a refrigeration service company in Hawaii (USA) — implemented the solution internally.
Challenge
As the MVP met the real world, the client realized that the web app was missing an important feature: a calendar view of work orders.
This was a pressing matter for the client, but the original Product Designer could not take this on, so she recommended me for the job.
I had one week to deliver the designs.
Solution
To kick things off, I met with the Product Designer and the Back-End Developer/PM to understand the project’s context, requirements, and constraints.
I received access to the original Figma files and the system’s test environment. Then, I started organizing ideas to translate the requirements into an intuitive and coherent interface.
In parallel, I gathered references for the calendar UI and, based on information from the client and project manager, I established the information granularity for each timeframe (month / week / day).
The UI ideas and refs were then discussed with the development team to gauge what would be realistic to implement in the established timeframe and budget.
After this alignment, I started sketching potential solutions using the project’s UI kit and style guide.
Once I had a promising solution for the monthly view, I shared it with the Product Designer and developers for validation.
I had suggested adding the calendar view as a separate menu item, as that would be the quickest and easiest solution. However, a better solution would involve some improvements to the header UI, which would impact other screens and require additional development work.
The developers agreed with the changes, so I updated the screens. See the before and after below.
Once all the screens were updated, I created a prototype to communicate the expected behavior across the feature, recorded a video waltkthrough, and handed over the Figma file to the developers.
Reflection
This was my first experience working with a product “in the wild”, with real-life limitations and expectations from all stakeholders (client, teammates, and users).
Time was the main constraint, so we had to be agile and cut a few corners. Not optimal, but life rarely is, right?
Ultimately, what matters is that the client was happy with the quick development of a much-needed feature (see his comments about the UI below), the technicians benefitted from more organized management, and the developers got the Design support they needed.
If we had more time, I would have liked to push for a fully responsive solution, but unfortunately that was not in scope. Hopefully, as the MVP matures into a full-fledged product, this need will be addressed.
