Resource Health

The approach

Concept testing to understand user needs

I only had two weeks to do exploratory research so I used the competitor experience and adjusted it to our environment to quickly test the concept and understand what features were important to our customers. Since we were doing this view for EC2 instances which is another service in AWS, I reached out to that team early to gather past research and understand what customers needed in terms of monitoring. The researcher from that team also helped me recruit the right customers.

I created low fidelity Balsamiq mocks and prepared the interview script. I wanted to learn more about how customers solve the problem today but also get some quick feedback on the conceptual designs. Talking to customers opened some new ideas and I was able to get a lot of insights and understand more about the core problem. I also learned about some competitors features that didn't make sense for our customers and some other ones they really needed:

• Customers didn't find it useful to resize the nodes based on another dimension. The visual representation was too confusing for them so we opted in for sorting instead
• Customers had their own meaning of healthy, so we wanted to give them the ability to set up their own thresholds and choose their own colors to represent those
• Customers wanted an easy access to additional information so we chose to provide quick glimpse of main details on hover

Sharing research results and ideating

I put together a research report with learnings including some customer quotes and quick video snippets. I usually involve stakeholders in the customer calls but this time everybody was on other projects so I needed to find a way to help stakeholders empathize better with the customers and quotes and videos really helped there. I presented the findings to product and development teams as well as EC2 team in order to get their buy in to explore different concepts rather than fix on one solution that worked well for the competitor. I got support to continue exploring different options that were more in line with what our customers wanted and needed, but was again given a tight deadline as the development team wanted to start as soon as possible.

Defining user journey and brainstorming with the team

Research Insights helped me put together a quick user journey as well and it was clear that the user's starting point was not CloudWatch at all but EC2 service and there were many other touch points with different services within CloudWatch as well so I realized I'd need to map these out to ensure we link between those services and embed the information where needed.

With research insights and high level user journey in place I got the team together to start brainstorming. Everybody was already familiar with the competitor solution but all the insights gathered really helped us think outside of the box and consider different options. I involved the EC2 team in the brainstorming sessions as well to get more insights about the service itself and understand their point of view.

I prepared, facilitated and participated in those sessions. We did crazy 8s and then split into multiple groups to work on a more final solution out of all the quick ideas. In the end we voted on the ideas we felt were the strongest ones. I chose a decider who was listening to the reasoning behind the votes and was in charge to pick the direction based on all the information he got from the rest of the team. The most innovative idea was the "smart recommendation" that would suggest to the user how to group their EC2 instances so that they can correlate the issues more quickly.

Prioritizing the user stories and feasibility check

We had a lot of ideas on the table with varying levels of feasibility. The team was already behind on some other projects so we really needed to scope this one down into the most basic but still meaningful MVP. I got together with the team and decided to play some monopoly. Each stakeholder was given the same amount of money and they were asked to buy the features they really wanted to have. I included all the features, starting from the most basic ones to very challenging ones to understand first what we felt was the most important and to help us draw the line. Because of the time constraints, I couldn't reach out to external customers but I included 5 internal customers into this workshop and gave them twice as much money so their "votes" counted more.

Creating a road map

The above exercise helped us narrow down and prioritize ideas but we still didn't want to lose sight of all the ideas we had and we wanted to make sure we build enough stories in each area so that the MVP is still fully usable. Together we build a user story map by defining each area of the product and listing all the ideas we had and drawing the MVP line, but also V1 line and defining what needs more exploration as some ideas were very high level and needed more customer input. This was a great exercise that allowed us to see if we were investing too much into certain area of the product while keeping the other area underdeveloped.

MVP needed to be fully usable from the start so even though the team felt really passionate about certain customization options we had to make some trade offs and leave those out. Creating the road map was the most time consuming part of this project as it was difficult to get everyone to agree on the MVP scope. With limited resources we need to make a lot of trade offs so we had several meetings to discuss and iterate. The most proud moment for me was when one of the team members was bringing up a customer quote from research presentation while advocating for a particular feature.

Creating high fidelity prototypes, usability testing and preparing functional doc

I was working on high fidelity designs in parallel with the road map discussions. This sped up the process a lot and allowed me to include more features in the design than what we were planning to build in the first phase. I wanted to do the usability testing sessions on more complete designs so that I don't have to do it twice. This time the team was asking me about usability testing sessions and wanted to shadow and even though we were under a lot of time pressure they encouraged me to take my time with the testing because they could do some backend work in the meantime. During usability testing sessions I got some ideas for improvement which we addressed in the final design:

• users didn't see the settings page so I made it more accessible and easily discoverable
• uses with too many instances were not happy with the limitations so we made sure to include a quick breakdown of thresholds
• users couldn't figure out how to get to the dashboard page so we made that CTA more prominent and clear

I put together a functional doc detailing all the edge cases and different scenarios and behavior in each to make it easier for the development team. I offered support during implementation to answer questions and review the implemented UI to make sure everything is pixel perfect. I also defined client metrics (clicks to track in the UI) and together with the PM we defined success metrics. We decided to use the adoption rate as our main KPI.