SR PRODUCT DESIGNER
Previous mobile application suffered countless engineering and user experience issues due to no previous designer and a solo developer over the course of around 6 years. Neverending bugs, non-ideal framework, inconsistent and abnormal user patterns would be just scratching the surface on issues with the previous app.
The design was not human centered but served more as a contact list with all product funtionality stuffed into an ellipsis per contact.
Brutally common feedback in Net Promoter score
JobNimbus as a company was also trying to tackle a massive churn issue as well as increase number of users.
- User interviews via zoom and phone call
- On site interviews and shadowing at business locations
- Breakout sessions, and casual chatting at crew events (we would bring in 60-80 users together each month for trainings and feedback)
At the time, the only users of the product were owners and office managers (realistically, only the office managers).
Sales reps were always on the go and would generally be sent out with their work orders and tasks for the day on paper. They were also known to be transient across different companies as they would relocate chasing storm damages across the nation.
Sales reps would be ideal primary user of mobile app since they would most utilize the mobile device, represent their business professionally being more customer facing, and would be a huge opportunity in increasing number of users once the app truly provided them value.
I collaborated with my team of a product manager and 8 engineers to determine key features for an MVP in order to provide concrete user centered value and a concrete foundation to grow the app's features and functionality post launch.
A view of "today's tasks" that the sales rep can view at a glance.
A map view of all added and documented jobs and contacts with a list view as well so they could see where they need to go as well as who is nearby.
After many product demos with stakeholders and users, this MVP proved more than sufficient value to launch and be available for our users.
We decided to keep the old app in the app store until we released (an improved) feature parody before sunsetting the old app.
From the job overview page, a user can navigate to an overview of financials respective to the job. Here, the user can view, add, and update all necessary financial documents related to the job.
Each of the different financial documents shared similar line items and structure but would differentiate in purpose and output. If a roof was estimated to have a specific asphalt shingle, it would reflect on the material order to purchase and receive that product for the job, then the work order would show the asphalt shingle to use during the process of installation, and the invoice would reflect the final cost and purchase of that said asphalt shingle.
Because of this, the sales rep is able to save an estimate as a template and insert that template in each given document and make adjustments along the way.
This is why it made sense to keep UI consistent across each document with subtle differences in functionality and calls to action.
First phase in creating an invoice promotes user to build off job's existing estimates (it was possible to have more thn one per job).
Empty state of invoice
Ability to change template within the create state
invoice with line items filled
Pattern: Due date chip selected, different payment terms and due date can be changed on a card.
Date change UI
Terms change UI would appear to slide to user's right.
Change of terms to "Split" payment
Created / Saved invoice
Selected Works
JobNimbus Mobile AppProject type
DOMO Goals AppProject type
PayLockProject type
Alliance CounselingProject type
AssembleProject type
GOJIProject type