Splunk Developer Program
summary
User: Developers who make Splunk apps
Problem: Existing developer documentation & tooling experience is fragmented, difficult to navigate, difficult to learn from.
Method: Iterative design approach with foundational user research, prototyping, and concept validation
Solution: Unified site that houses all developer resources in one place, with improved experience and interactions
problem
At Splunk, we love our developers. They help create hundreds of tools for public consumption that we could never churn out alone. So we it was time to give them the support they deserve — a newly-imagined, one stop shop developer portal for our core products (Enterprise and Cloud) where newcomers can get their feet wet with tutorials, experts can deep dive into our API reference, and everyone in between can grab tools to start building their own apps and add-ons.
Splunk already had tons of developer resources — the issue is that they were spread out across multiple sites serving drastically different user experiences. Our* goals in this project was to create a cohesive experience for all developer resources in one location, and to incorporate Splunk’s new design system for a refreshed look and feel.
*The team initially consisted of a principal UX designer, user researcher, product manager, documentation writer, and myself (engineering was brought on later). When referencing design work by saying “we”, I’m referring to the principal designer and I.
the Process
Understanding the user and existing experience
First, the principal designer and I needed to understand the wide range of tools and content we offered, their purposes, and how our developers felt about the current experiences. Our team worked with a user researcher to understand developers’ needs, pain points, and app building workflows. Through multiple rounds of foundational interviews led by our researcher, we learned that developers primarily 1) have trouble learning from and navigating through the existing fragmented documentation, but are also 2) motivated by their customers’ needs, and 3) want lower barriers to entry for creating apps.
Initial design
With these findings in mind, we prioritized presenting clear documentation, making value props clear, and surfacing quick start tutorials. Categorizing existing content helped us create a navigable information architecture highlighting 4 categories: Documentation, API Reference, Tools & Downloads, and Examples. We then explored ways to enhance the home page with first time user experiences, selling points, and visuals. Building from this, we sketched and wireframed content, layout, and structure for pages lower in the hierarchy.
Concept testing:
Once we fleshed out enough content to turn wireframes into higher fidelity prototypes, we were ready to validate them with developers. In the first few rounds of validation led by our researcher, we received positive reactions about larger scale improvements, like providing “quick start” tutorials and use case-based code examples, but also smaller experience boosts like including an interactive table of contents per page. On the flip side, we received negative feedback on information display and syntax clarity on the API Reference, as well as a lack of supplementing visuals across the site. With each successive round of validation, we worked with the larger stakeholder group to smooth out issues, integrate feedback, and increase design fidelity.
At this point in the project, I was taken off the project to work on something else, so the project continued on a significant amount without me. I’ll cover what I was asked to help with once I returned.
I came back to help out with 2 new stakeholder asks: 1) scale the site so that it can house developer documentation for multiple products, and 2) adapt Splunk’s new design system to the developer portal.
The top priority problem to solve was: how do we make sure developers are where they want to be, and can quickly find what they’re looking for? I worked with the same designer to thoroughly explore different types of visual indicators, labeling, and navigation to orient our developers to the right resources. The challenge was making sure the solution we picked was engaging and communicative across every page in the site.
Scaling the site
Similar to our original process, I started by sketching and wireframing, followed by mocking up navigation solutions for better user orientation. We took a risk by challenging developers’ mental models of our existing site structure; we changed our original home page and split it into one parent home page that led to separate child home pages for each product. Developer feedback validated the branched home page experience, color coding, and text labels as the most effective product differentiators.
Tying it together with our new design system
While I was away, the team asked a visual design agency to help us adapt Splunk’s new design system to the developer portal, by way of a style guide and a few example pages. I then applied and changed styles to our site as needed for full effectiveness, due to recent changes in page hierarchy and navigation.
Conclusion
The final product lives at dev.splunk.com today. Some changes have been made ever since I left the project, but you’ll be able to see the impact of some of the work I discussed above.
The impact of this product is quite large — dev.splunk.com has traditionally been our most important resource for developers since its inception, so the redesign and information captured within touches every developer who seeks assistance on app-building.
The most significant takeaway I gathered while working on this project was the importance of scalability. When thinking about user experience, it isn’t enough to consider the best experience today; you have to understand how the product space might change over time. Products don’t exist in a static space — they constantly evolve to meet changing user needs and business requirements, so it’s important to take that into consideration when problem solving.