The original version of their product needed a facelift and advanced functionality to match competitors, so we were brought in!

We wanted Roadsider to retain a lot of the same "look and feel" as the original, since most users we talked to enjoyed the old experience. So we kept similar colors and styles, while updating and modernizing the details.

Invoicing is at the heart of a tow company's business, both feature wise and revenue wise. Since it's the core of the product, starting here uncovered a lot of questions and details that would help us develop other parts of the platform.

This was a huge undertaking to redevelop an entire product from an engineering, design, and functional perspective, so we needed a plan that everyone could agree on with Invoices as our first major feature.

Organization of such a large product was critical. More details on the PRDs to come in the next section!

A PRD (Product Requirements Document) is foundational to how we approach product. It contains the background of why we are developing a feature, what it does, who it's for, and what the core goals of the feature are. Completing it requires a deep discovery and effort from both the development team and client.

Since we weren't experts in the towing industry coming into the product, we decided to leverage the knowledge and experience of the experts. We even interviewed one user more than 10 times because he loved being up to date!

Once we found an initial "look" that everyone was happy with, we start rapidly designing and expanding the new Roadsider ecosystem.

A dashboard with advanced analytics, cash tracking tool, and a way to visualize the core finances of the business were the top requested features amongst the users we surveyed. We delivered on all of them, plus a customizable dashboard using widgets!

This screen has a lot of complicated integrations: map view with automatic address matching, License plate database to pull vehicle details, request customer location feature, and a document uploader.

Adding various states, pages, components, and building out a design system along the way.

Imagine you have several different drivers exactly the same distance away from someone who needs a tow. How do you decide which driver to automatically suggest for pickup?

Until the feature is complete and ready to review with the team!

Each feature needs a completed PRD before we start designing so that we know exactly what the designs need to do.

The process is repetitive, but never dull. Every feature has it's own challenges and unique solutions.

Engineering Documentation spells out details for engineers that are not directly evident in design, the various design states and how a user moves through them, and all the small details engineers need to actually understand the product.