Secure by Design: Delivering Incremental Value to Duo Customers
We’ve been hard at work improving our reporting capabilities in the Duo Admin Panel, which we introduced in May. We’ve talked about some of the technical aspects of building the data visualizations as well as how we improved our data pipeline to make the visualizations possible.
Now that we’ve talked about the tech, let’s talk about how we decided what to build in the first place from the Product Design perspective. I’ll give you a glimpse into how the teams at Duo work together and the process that we go through to solve customer problems.
How It All Began
It all started with the initial goal of making the dashboard useful. We hadn’t updated the dashboard to reflect our new features in quite some time - the metrics at the top were stagnant numbers and we frequently heard that the World Map was pretty to look at, but not very valuable for day-to-day administration and monitoring.
Like with all of our design projects at Duo, I started with the Discovery and Research phases. The goal during these phases is to gather as much information and context surrounding the project as we could.
I started the Discovery phase by collecting examples of data visualizations and dashboards from a variety of industries. When searching for inspiration, it’s helpful to look outside of industry competitors. In addition to security dashboards, I looked at examples from sports, banking, marketing, social media and even our own users’ custom dashboards.
Next, we worked on the Research phase, where the goal is to uncover customer problems. My engineering lead, product manager and I interviewed a dozen of our customers to understand what we could do to make the Duo Admin Panel dashboard more useful. At the mention of the word “dashboard,” many were kind enough to share their custom Excel charts and Splunk dashboards they’d made in lieu of Duo’s lack of robust reporting.
Tip of the Iceberg
It quickly became clear that Duo’s dashboard was the tip of the iceberg. One of the guiding principles of the Duo Product Design team is to “Make data actionable.” The more customers we talked to, the more it became obvious that making data actionable went much, much deeper than the front page.
Not only that, every event or object in the Duo Admin Panel is inherently related to one another, which meant that when an admin investigates an issue with one, they want to figure out if it’s part of a larger trend. Authentications are created by users who are using devices to get into applications.
If we wanted to make the dashboard more useful, we’d need to start a level lower by looking at the overall reporting capabilities of the Admin Panel. So, we massively increased the scope of the project. I was lucky enough to have an extremely supportive product manager and engineering team who told me, “Shoot for the sky, Lulu, and we’ll catch up.”
Synthesis and Ideation
Upon realizing the much larger scope of the problem, I did what every stereotypical designer does. I broke out the (virtual) sticky notes.
I worked with another designer to take all the findings we had gathered from our interviews and started clustering everything into themes. These groupings helped us break down the problem into discrete, smaller problems that we could tackle.
After understanding these themes, we started sketching and putting together wireframes. We worked closely with the developers to review the ideas, so they could build the right supporting data structures and we could design something technically feasible.
But there was a bit of a problem. Engineering knew we would have to make a huge move to a new database structure (thus extending the timeline), and Product knew that customers needed better reporting very soon (thus shrinking the timeline). This resulted in the perfect storm of “Important” vs. “Urgent” work.
So we put a plan together to provide value to customers based on existing technical constraints, as the overall engineering team was working on figuring out the right database to build and migrate toward to support our long-term aspirations.
As a designer, part of my job is to take the constraints given by my partnering teams and make designs that fit those, while delivering value to the user. So, what could be done?
Start Simple and Build Up
Looking at all the wireframes and themes and sketches, our team started with what we could do right now, while still building toward the final vision. This allowed us to lay down the groundwork for more sophisticated reporting, all while providing incremental value and testing our designs to see if we were on the right track.
We started by giving the Authentication Logs (shortened to Authlogs) a seemingly simple facelift to increase the readability and comprehension of the data. Under the surface, we were actually setting up the page on React to build the foundation for future reports.
Along with these visual updates, we added “Admin Accelerators” throughout the Admin Panel. These were snippets of aggregated data that made the user’s job more efficient.
Things like:
- Surfacing the number of users in Bypass or Locked - Out status (Users page)
- Showing how many licenses were left (Dashboard)
- Showing how many bypass codes existed, who made them and pointing out the riskier ones (Bypass Codes page)
Although these seem like small features, we were solving real customer problems incrementally, and each step helped to build our technology stack to support the larger vision for reporting.
Data is Served!
When the new database engine was ready to use, design was ready and raring to go. We had been sitting on all these amazing insights about the most impactful data our customers wanted. I immediately wanted to jump into designing reports that showed suspicious authentications, blocked activity, and bypass risks! But slow and steady wins the race, and the best method was to continue delivering incremental value to build up to the bigger picture.
First, we addressed our customer’s biggest challenge with our Authlogs by building robust filters - based on time, type and events. This was a huge win for our customers that relied on the GUI reporting to investigate errors or suspicious events.
At the same time, we began building our first report: the Authentication Summary Report, which shows a higher level view of a customer’s environment. After that, we built the Deployment Progress Report, which shows the progression of customer’s adoption of Duo. Following that, we created the Denied Authentications Report, which dug deeper into just the adverse actions like denied authentications and why users were failing to authenticate. You can read more about these reports in this overview blog post.
Each report required a little bit more functionality to be added on top of the infrastructure we built, but we were able to release them incrementally and provide value to customers instead of waiting until all parts were complete. As the reports were being released, we continued to interview our customers about their value and usability. These continuing interviews helped us adjust the designs and also informed our future roadmap for reporting.
Back to the Beginning
Finally, like a heroine arriving home after a long, long journey, we returned to the start: Duo’s dashboard. In truth, the dashboard didn’t get a giant facelift or a big bundle of new features. We rebuilt the dashboard on top of the new structures and swapped out some of the metrics for new, more meaningful ones. The cherry on top of a brand new beginning.
In conclusion, this was a huge, huge team effort. There were lots of other designers, developers, product managers, managers and customers involved. We hired a lot of people throughout the process and even spun up two new teams, Data Engineering and Data Science, to work specifically with data, and even hired a product manager just for this function. Looking to the future, we’re continuing the journey by building more reporting capabilities, improving the existing ones, and leveraging our data to further help customers secure their users. Thanks for sticking along for the ride!