Admin/End User Design Sprint

Summary

User: End users who need admin-like capabilities in a native Cloud offering
Problem: Splunk admins carry the burden of performing all administrative actions in the product, while end users are not empowered to control their Splunk experience.
Method: Design sprint
Solution: Low-fidelity prototype

Problem

Splunk Enterprise was originally developed as on-premise software, allowing administrators to have full access and control over all of their data and Splunk components. These controls included managing system performance and storage, getting data in, maintaining user roles and access, developing apps, and more. End users didn’t have these capabilities; if they wanted to accomplish something in the product, like installing a dashboard, optimizing data models, or creating user groups, they would have to ask their admin to do it for them.

As Splunk’s business shifted towards a Cloud-first model, admins began to expect SaaS experiences with Splunk, which included empowering end users to perform some tasks that are usually reserved for admins only. Admins wanted two things: 1) to empower their end users through self-service administration, but also 2) to retain their own streamlined system and resource management experience for remaining system admin needs.

Product management and the design team (consisting of myself and several other designers) participated in a 2 week design sprint to create a new solution that would meet admins’ needs.  Our primary goal was to design a solution that would increase the number of end users, by:

  1. Enabling end users to perform admin capabilities through self-service administration, which reduces bottlenecks in customer organizations.

  2. Freeing up admins’ plates by modernizing and streamlining their remaining tasks.

My role in this project was to focus on the first goal — enabling end users to perform admin capabilities through self-service administration. I collaborated with 2 designers to conceptualize and design solutions for this goal during the sprint.

Process

In the grand scheme of a Splunk deployment, there are countless areas of management for admins to control, so we needed to narrow our focus to several topics before we could begin the sprint.  Product management drove this conversation and decided to focus on areas that would create the most value: app management, alerting & communications, configuration & data management, and monitoring.

Then, the design team stepped in to depict how we would improve self-service management of these 4 areas and integrate those solutions into one prototype. Our end goal was to develop enough detail in this prototype so that we could validate our ideas with user research later on. To further distill the desired outcome into actionable parts, we rooted our design work in several user stories, which we fleshed out together with product management:

  • An end user can browse and install content from Splunkbase — our app marketplace (app management)

  • An end user has insight into helpful information regarding their workspace, such as new features available, system downtime, etc. (alerting & communications)

  • An end user can monitor the performance of searches and workspaces (monitoring)

  • An end user can create and install workspaces (app management)

  • An end user can customize workspace settings (configuration & data management)

  • An end user can share workspace with other users (configuration & data management)

We split user stories into 3 sub-workflows so that each designer could focus on one area in the initial process. My focus was on the user stories around configuration, data management, and monitoring.

The next 2 weeks revolved around design iteration, starting with sketches the first few days, and ending with a low-fidelity prototype. My personal approach in this sprint was to divergently sketch ideas, to keep options open-ended, especially with so much ambiguity around where my workflows connected to my teammates’ workflows. I wanted to create an opportunity to converge designs based on how my teammates were approaching their problem solving.

Every afternoon, we had a team critique where we would start linking our stories together and provide design feedback to each designer’s screens. I leveraged this feedback to iterate on my designs and develop consistency in interactions with what my teammates were designing. At the end of each day, we formally presented our day’s work to another team that was running a concurrent sprint, to further drive consistency with them.

conclusion

The final product of this sprint was a low-fidelity prototype and presentation to our stakeholder group. The prototype included a full end user administrative workflow, connecting my designs with the designs of my two teammates, that we all collaborated to connect and critique together.

This sprint taught me a lot about teamwork — not in the traditional “efficiency, productivity, and communication with your team members” sense, but more so in the realm of designing with an open-ended approach when your work is dependent on someone else’s work. At Splunk, I’m accustomed to driving my own decision making while incorporating feedback from my team along the way, since our organizational structure puts designers in silos, each individual focusing on their own products and services. I don’t often have a chance to work on one component of a service, while my teammate works on another. In this sprint, I balanced solving pain points and meeting user needs, while avoiding being too prescriptive with my solution — this helped the team have more productive conversations day-by-day.