Defining an MVP

Defining an MVP for this project was a new challenge for me. I had worked on MVP’s of new features or redesigns, but not an entire enterprise application. But due to our tight development time of 6 months to ship a first release, it was critical to clearly define an MVP — so I turned to our users for help.

I decided to host a version of a user story mapping workshop, called “Buy a Feature”. This workshop started with user stories that I had written based on my research. After allowing my 17 participants to review and add user stories, I gave all participants a limited number of sticker coins in which they could “purchase” features that were most important to them.

The outcome of the workshop was a clear list of prioritized user stories, as prioritized by users themselves.

Iterative Design & Testing

The challenge of designing RFQ was creating a universal structure that could accommodate five different team’s workflows, while selectively accounting for differences. Because of this, it was important to transition from low to high fidelity mockups, reviewing with users at each phase of design. Specifically before transitioning from medium to high fidelity mockups, I conducted usability testing with an InVision prototype with users from each team.

With my list of prioritized user stories for the MVP, I began with low fidelity wireframes.

Contract Page Structure

Each contract had a dedicated sub-page and was accessible from the home homepage. It was important for the design of the contract sub-pages to have flexibility and centralization.

Flexibility was important because certain teams had additional workflow steps that other teams did not. For example, the Truckload team allocated work within a contract, whereas in other teams, one team member managed one whole contract. To account for this, I decided on a dashboard layout. With a dashboard layout, we could easily add/remove a widget depending on on the user (team) type.

It was also important for this page to contain all the documents and data relevant to the contract. One big pain point of the legacy tool was that the commenting and documents features were unreliable. As a result, users relied on email and Slack for communication and sending documents back and forth, which was a security issue for the company. To account for this, I added a widget for messages (as opposed to comments) with the UI of a recognizable chatbox, as well as a widget for uploading and downloading documents.

Notifications

Because messages and documents were contained within individual contracts, it was important to have a robust notification system. In fact, one of the main reasons that users relied on email/Slack for communication when using the legacy tool was that it lacked any form of notification capabilities.

Unfortunately for the initial MVP release, we were only able to implement email notifications. However, in our post-MVP work, I designed a notifications panel, accessible from the main navigation. There are two main types of notifications: messages and tasks.

As mentioned, contract opportunities move back and forth between teams, so it was critical to inform users of certain tasks awaiting them. For example, if a Sales user creates a new contract opportunity, we would auto-trigger a notification to the respective Pricing team, communicating that a new contract has been created for them to review. We called these task notifications because they were events with a required follow-up action.

Given the consideration that most RFQ users would not be on the page constantly, we also implemented browser notifications that could be managed from a notifications settings page.