Chronosphere - Info Model
End-to-End UX Design
Description: Chronosphere is a scalable, reliable, and customizable monitoring solution built for cloud-native applications. The product is built on top of M3, a scale metrics engine developed at Uber.
I joined the Chronosphere team right after its series B funding as the second UX designer. I led the first product redesign and transformed the product’s organization to mirror the team environments of our customers.
My Role: Lead UX Designer
The Team: 1 Product Manager, 1 Engineering Manager, 8 Engineers
My Responsibilities: I worked on scoping the project, crafting personas, customer research, creating user flows and wireframes, and designing rapid prototypes for product showcasing and user testing.
Tools: Figma, Miro
Basics
Company Overview
Chronosphere is a digital monitoring company for the cloud-native world that was founded in 2019. The company founders recognized that today’s monitoring tools are not equipped to handle the complex and dynamic nature of cloud-native environments. Open source tools help get companies started but they do not scale effectively to fit the customer’s needs. Chronosphere delivers scalable, reliable and customizable monitoring for companies adopting cloud-native.
Chronosphere not only allows customers to store and retrieve massive amounts of data but also does so in a cost efficient manner. Chronosphere lets customers understand and control their spending, even as the data continues to grow. This level of visibility and control is the first of its kind and can help reduce monitoring costs by up to 10 times.
Chronosphere is provided as a hosted service which eliminates the need to manage a monitoring infrastructure while still maintaining compatibility with cloud-native standards like Prometheus, PromQL and Grafana Dashboards.
Design challenge
When I first joined Chronosphere, there were only two designers in the company. We were spread across the multiple workstreams and had to manage multiple projects at once. On top of this, I was conducting the first round of user research and drafting the company’s personas. Through this process, I learned more about the problems our users were facing.
When Chronosphere was first designed, we allowed every user to see every part of their company’s system. This worked great for small companies who didn’t house loads of data but as our customer base grew, so did the size of the companies. Large companies have many teams that look at a lot of data, dashboards, monitors, and rules. Logging into a system without a scaled-down view was challenging as users had to rifle through a lot of information to find the data that they needed.
We needed to design a model that:
allowed users to create their own view so that they could quickly see the data that was relevant to them
provided users with context about the entities (monitors/dashboards) that they were viewing
decreased triage time
In the previous design, all users would log into Chronosphere and see the same dashboard. This dashboard displayed general documentation and overall system data. Nothing was specific to the user, therefore nothing was relevant. To see a more specific dashboard, the user would have to use the dropdown at the top of the page. For larger customers, this dropdown could contain hundreds of dashboard names making the scroll process rather tedious.
This image shows the previous design of the alerts page. The user could see every alert in the system and there wasn’t a way to search through it. If the user needed to change or delete an alert, they would have to navigate through all of them to find the one that the needed. This was not only time-consuming process but also one with many errors. The user could easily delete another team’s alert. Other pages in the product had similar functionality in which the user could accidentally mess with another team’s information.
Process
As the lead designer on this project, I had full control over the design process. I thought it was important to start with a full research deep dive so I could understand the landscape and the need for the major design upgrade.
Once I had a strong understanding, I created user flows and personas which were verified by the project’s PM. I then collaborated with the UI engineers to create designs that were easy to understand yet fit our strict timeline.
Since the project affected almost every part of the Chronosphere, I received a lot of feedback from executive leadership and engineers on other teams.
Research
Personas
Chronosphere relies heavily on product personas to help articulate user needs, customer concerns, business goals, and inform product design decisions. When I first started this project, I used personas that had been crafted around the job titles of our users (as seen below). However, we revised our personas during this project in order to better reflect the goals of our users. The revised personas can be seen here.
Service Expert
Service experts have a strong understanding of the company’s infrastructure and are often utilized when problems arise that require deep expertise. Sharing information can be challenging. Info model allows service experts to organize information by service and share some of their understanding with other users.
On-Call Engineer
When an engineer is on-call and receives an alert, they need to respond to and solve the issue as quickly as possible. Having all the relevant monitors and dashboards in a single space allows engineers to quickly find, diagnose, and triage the issue.
Assumptions
I collaborated with the product manager and engineers at the start of the project to list out our assumptions. These assumptions were based on customer feedback, preliminary research, and the engineers’ own experiences. We used the assumptions to guide our research and initial designs. As we worked, we validated and adjusted our assumptions regularly based on user feedback.
We believe that organizing observability data into a Team(people):Services(software) model will provide the context needed to help our average customer triage faster, because it will help them know where to start
Organizing data into the Team:Service model will also help members of other teams find data, because this organizational model is familiar to them
We believe that service context matters during triage, and so we make it apparent what collection a monitor belongs to
Putting initial curation in the hands of the Service Experts benefits everyone, because it makes their already needed tribal knowledge more easily and asynchronously accessible
Design
User Flows
I spent a lot of time crafting user flows alongside the product manager. We wanted to ensure we were creating an intuitive design that met all of our user’s needs. Creating a navigation pattern that balanced our current product offerings as well as future features was a challenge.
The user-flows helped me not only identify and define each step in a user journey, but also gave the team insight into potential pain points. The flows were also used by the engineering team to ensure their code matched my solutions.
Wireframes
I use low-fidelity wireframes to start my design process. This allows me to get my idea down without having to fuss with the intricacies of pixels and spacing. Sometimes these low-fidelity designs are used to start discussions with the team before I move onto designing in higher resolution.
Throughout my design process, I like to collaborate frequently with the engineering team. For this project, I had weekly design office hours which allowed me share any new updates or insights. This time also allowed the engineering team to ask questions, get feedback on their code or ideate alongside me.
Design Studio
Chronosphere is a product created by engineers for engineers. I utilized my teammates as much as possible for design ideas since they had a lot of product knowledge, applicable experience, and opinionated ideas. Throughout the project, I hosted many design studios with the team. We regularly utilized the “Crazy 8s” method to quickly generate ideas and collaborate on our path forward. Since the sky was truly the limit on this project, I structured our design studios with clear goals and expectations to keep the ideas on track.
Design studios not only helped me with ideation but also helped bond the team. The engineers wanted to express their opinions and create the best possible solution. Involving them as much as possible throughout my design process helped build rapport.
Iteration
Navigation Prototypes
The hardest problem we tackled during the project was navigation. We needed clear navigation that emphasized the hierarchy of teams and collections and allowed users to quickly access their own resources while not restricting access to everything else.
Introducing teams and collections meant deprecating other parts of the product. We needed to make sure the new navigation felt somewhat familiar so users weren’t nervous when they first encountered it. Through testing we learned that a new UI can cause some initial stress for users because they think their old data is missing.
To validate our assumptions and test ideas, we completed user testing on an almost weekly basis. We test with internal users, external users (non-customers) and customers in order to get an un-biased and varied opinion. We tested everything - functionality, discoverability, terminology - and tested with all user types to ensure the product was as functional as possible. These tests not only helped us identify friction points but also got our customer excited about upcoming features. We often times completed A/B testing and ended up building a C prototype.
User Feedback
The product manager and I used research learning maps for each round of user testing. Before we would start a test, we would list our research objectives, hypotheses and metrics of success.
After completing our tests, we would map our findings to the initial objects and would note any action items. These maps were shared with the team engineers to help lead design discussions as well as provide evidence for our decisions. These maps were also used to educate executive leadership.
Results
Final Design
After many, many design iterations, we landed on a final design that featured left-hand navigation. Through our testing, we found that the left-nav was familiar to our users. When we made significant changes to the navigation, users were worried that their data had been lost.
Our new design also had a prominent global search which allowed users to access anything from anywhere in the product. Including a keyboard shortcut for search was an added and appreciated bonus.
Our new design made many improvements as shown by the metrics below:
Decreased search time: Organizing team entities on home pages significantly decreased the amount of time users were spending sifting through artifacts. On average, users were able to find the correct artifact within two mouse clicks. Previously, it took users an average of 4.5 clicks.
Decreased triage time: Organizing team entities also helped decrease the amount of time that users spent triaging an issue. Users no longer had to bounce around large lists of entities but could instead find everything in a centralized space. Users reported that average amount of time spent triaging an issue was nearly cut in half.
Tradeoffs
Although this project was considered a success, we had to make many tradeoffs based on time, resources or other leadership objectives. The biggest tradeoffs are highlighted below:
Data visualization library - When Chronopshere was first launched, the product used embedded Grafana dashboards. The dashboards were functional but this approach lacked meaningful integration and resulted in a fragmented user experience. When a Grafana introduced a licensing update, Chronosphere was compelled to create its own data visualization library. For the first few months of the info model project, the team was working collaboratively with a visualization team. Many of the homepages were centered on the visualizations crafted by the team. However, we realized that creating a competing library required more engineering that we initially planned for. This put the dashboard library projects on the back burner and ultimately affected some of end designs.
Personal home page - Users requested a personal homepage that allowed them to store test dashboards and monitors. In theory, this seemed like an easy build however sharing permissions quickly complicated the design. We scrapped this idea until we had more time to think through all the implications.
Design Library - As I was working on the information model project, I was concurrently owning the Chronosphere Design Library (learn more about my process here). Both projects required a lot of design, but I placed a larger priority on information model since it was a big product differentiator. Many of the final designs for information model are busy since we hadn’t finalized our design patterns for the library yet. Since information model has been released, many patterns will be revisited to help clean up the final designs.
Reflection
Next Steps
Info Model Everywhere (AI): The current design of Chronosphere allows users to quickly access related resources as long as teams and collections are manually maintained. In the future, we’d like to introduce AI to help with collection maintanence. AI can prompt users to add and/or view related artifacts based on similar metrics, similar user paths, etc.
References: The current model of Chronosphere only allows for entities (monitors and dashboards) to be owned by a single collection. We know that our customers want more. Users want to be able to view entities owned by up/downstream services to understand their health and how they are affecting the services that the users own. Being able to “reference” an entity on another team or collection homepage brings greater visibility to the user.
Personalization: Many users at Chronosphere create limited-use dashboards and monitors to test their code. These dashboards have to live in a collection and can sometimes clutter other user’s views. We want to allow users to create personalized spaces to put their test entities as well as bookmark any favorites. This will not only allow users to quickly access the things that they care about but it will also help clean up team spaces.
Takeaways
Find balance: Chronosphere has a number of different customers ranging from new startups to industry giants. When looking for new product features, it’s important to design solutions that meet the needs of every customers and not just the needs of our most dominant customers.
Be vulnerable: I joined Chronosphere as a UX designer with very little technical experience. In some ways, this was an advantage as it really allowed me to consider the whole picture and question every decision. It also was quite challenging as I had to ramp up my technical knowledge quickly. I learned to be vulnerable and allowed myself to ask “dumb” questions.
Ask questions: Chronosphere is a product that is primarily used by software engineers. When working on new features, the design path was sometimes prescribed by the engineers that I work with. It can be challenging to find the right design route when your co-workers have already “solved” the problem. In these instances, it is important to ask questions and gain a full technical understanding to ensure we’re designing the best solution and not just the easiest design.
Follow the map (loosely): We created a roadmap based on customer and business goals at the start of the project. This helped us make design decisions but we routinely reevaluated the roadmap to ensure it was still meeting user/business needs. We sometimes had to pick a less ideal solution in order to accommodate features further down the pipeline. These conversations were conducted with the entire team to ensure we were taking engineering and business goals into consideration.