Internal Tool used to align conversations around new product launches. It is used primarily by product managers and consumed by all aspects of the business.
Roles played: User Research, Prototyping, Design Lead, Testing
Project done in 2017
It was determined that speed to launch was a pain point when we interacted with new clients or new products by speaking to various parts of the business.
The design team partnered with Product managers and took a look at how we were currently handling the process. They found out that Product managers were utilizing a massive spreadsheet to communicate out differences between products. This had a high margin for error and required users had the most current version of the spreadsheet.
This team created a bare-bones MVP.
So where do I come in?
I was put onto the project post-MVP launch to continue growing it's features and to take the lead in design thinking.
The first thing I did was partner with another designer and create a heuristic evaluation to determine key usability issues. The original team had been taken off the project before being able to address some key issues, and we switched from having off-shore contract developers to an in-house developer. I partnered with the in-house developer and our new product lead to discuss some of the key issues. We identified issues such as missing buttons, inconsistent CTAs. We identified over 40 issues that needed fixing.
A snippet of Internal Tool Heuristic Evaluation
After fixing some of the key issues and designing some fixes for some bigger problems I decided it was time to talk to some people who would be using the product. I facilitated 5 user interviews and discussed their experience with the MVP. We found consistent findings with the heuristic evaluation, as well as a multitude of issues with the navigation. One issue we discovered during the heuristic evaluation specifically was the navigation system the previous team had designed. It was not obvious it was clickable, user testing this specific feature showed people had no idea how to get from place to place, which made them have to go through multiple extra steps to find what they were looking for. They also couldn't navigate to specific areas within a category.
We decided to focus on navigation as our primary usability opportunity.
I generated multiple solutions, shared them with stakeholders and our design team, and iterated upon them until they felt polished enough to share.
I had prototyped 2 potential fixes and user tested them. Overall people definitely could find what they were looking for much faster, however it still wasn't quite right, and technology had some complications when it came to showing what section users were currently on.
I partnered even closer with our technology team and discussed some other options for the navigation.
Final decision for naviation
We ended up deciding on the navigation you see above based on user feedback and testing. Of course we are open to re-evaluating as time goes on if the data required to launch a new product out-grows the navigation. This solution is the most future-proof when new features are added. It also makes it the easiest to navigate quickly to what users are looking for.
There have been countless other items worked on for Internal Tool (creating a summary page, redesigning the homepage, etc.) One item that came up in our user interviews was that we heard that every time someone had to redesign a program it was particularly confusing and took a lot of time. In a large organization like we are there are a ton of moving parts and people can be affected by the smallest decision made by another team, so ensuring the right information is collected and communicated out is a big deal. We knew we had to get the right people involved, and we wanted to avoid having countless meetings to talk about the same idea, so I decided to facilitate bits and pieces of a design sprint. Please see the videos below.
When I left the project we had a prototype that we were running through rounds of User Testing and revisions. The best thing about utilizing this method was that we got stakeholders involved and bought in quickly and we were able to move quickly on the project. One particular finding was that it was a big deal for product managers to understand their action items and what impacts their decisions made to other teams, so we added the ability to see the impacts each change made. We also determined it was important for them to be able to utilize that information offline and allowed them to export it.