OVERVIEW
A B2B knowledge graph platform with docs that users couldn't navigate.
Stardog is an enterprise data platform used by organizations like NASA to work across massive, complex datasets.
The technology itself is powerful, but the documentation experience made that power hard to access. A lot of the existing experience assumed users already understood the system before they even started learning it. Navigation was inconsistent, information felt dense, and newer users often didn’t know where to begin.
As part of a collaborative redesign effort, I worked on rethinking the documentation experience to feel more approachable, structured, and easier to move through, especially for people still building confidence with the platform.
Midway through, research forced us to shift our original model — click here to read about The Pivot.
THE PROBLEM
Documentation written by engineers, for engineers.
The docs weren’t technically broken. The issue was that using them felt overwhelming.
People could eventually find answers, but it often took too much digging, too much context-switching, and too much prior knowledge. Even simple tasks could feel intimidating if you didn’t already understand how the platform was organized.
Through conversations with stakeholders, a few patterns kept coming up:
Slows learning
New team members leaned on the docs to get up to speed. The docs assumed they were already there.
help meee
Increases support load
Nearly half of customers were emailing Stardog staff before ever opening the docs.
Blocks adoption
Business-side users hit dead ends early. Stardog's reach beyond technical users was shrinking because of it.
DISCOVERY
We started by listening.
A lot.
USER-CENTERED RESEARCH
9 interviews, 62 survey responses, and 200+ affinity notes later:
Before sketching a single screen, we spent months just trying to understand the problem. That meant stakeholder interviews, internal surveys, competitive analysis, heuristic evaluation, and a lot of affinity mapping.
One thing became clear: the experience relied heavily on internal knowledge. Expert users could navigate the docs fairly easily, but newer users often lacked the context needed to build confidence early on.
9
1:1 Interviews
With 5 internal Stardog employees & 4 external clients
62
Internal survey responses
Across various role and tenures at Stardog
3
Audits completed
Content, IA, Heuristic
5
Competitors analyzed
Palantir, Neo4J, Amazon Neptune, Ontotext, Graphwise
EXPLORATION
Iterating on role-based navigation
& other early ideas.
EARLY DESIGNS
Role-based, glossary, navigation
After brainstorming possible design directions based on our research, we met with our client to discuss which to prioritize.
Of the 7 we proposed, 4 were chosen as priority based on client preferences and engineering bandwidth.
We then spent the next sprint creating low & mid-fidelity designs, iterating based on client feedback & team critique sessions. Even as the role-based structure got more refined, a question kept resurfacing in critique: would users actually know which role to pick before they'd even found what they needed?
Role based entry points and dropdown:
Glossary & critique session:
THE TURNING POINT
Continued research
changed our role-based course.
THE PIVOT
Role switcher → Jobs-To-Be-Done
Originally we designed a literal role picker: route the user by persona, serve them persona-based content. After client feedback and early usability testing, we reframed it entirely. Users don't think in job titles. They think in tasks.
BEFORE + AFTER
From "who are you?" to "what do you need to do?"
Card sorting & usability testing told us most users grouped documentation pages by what they were trying to do, not by product or feature name. The persona model was organizing content around a question users weren't asking.
Who are you?
Business → Business docs
Developer -> Developer docs
Data -> Data docs
Users couldn't find what they needed
What do you need to do?
Model my data → data modeling
Query my graph → query tools
Deploy my app → deployment
Users quickly orient and see their workflows
VALIDATION
We tested with the same kinds
of users who started us here.
USABILITY TESTING
20 sessions. Six tests. One anchor insight each.
Testing happened mid-process, before final designs were locked -> 20 internal Stardog sessions across technical and non-technical roles. Each test gave us one clear thing to act on.
CARD SORTING
Users group pages by task, not product
Most users grouped pages by what they were trying to do, not by product or feature name.
MENU NAVIGATION
No clear starting signal
The navigation didn't clearly signal where different user types should begin.
SEARCH EXPERIENCE
Role filters didn't work
Filtering by role wasn't intuitive. Users responded better to filters by content type or task.
HOMEPAGE
Toggle alone wasn't enough
Users wanted task-oriented entry points, not just a role label.
CONTENT PAGE
Orient before diving in
Tags, callouts, and a visible legend helped users orient themselves before reading.
GLOSSARY
Inline definitions work
Hoverable term definitions made unfamiliar concepts approachable without leaving the page.
FINAL DESIGN
Navigation built around
what people actually do.
WHAT WE BUILT
MOVE 01
Restructured IA
8 categories across the top nav, grouped by user progression.
MOVE 02
Two-level search
Popup for quick context-preserving queries. Full-page expanded search with four faceted filter dimensions for depth.
MOVE 03
Homepage as a discovery surface
JTBD toggle, quick links, tagged task cards, and a guided "Start Your Journey" path for users who don't know where to begin.
MOVE 04
Glossary integration
Lifted to top-level nav. A-to-Z filter, term reference cards, and backlinks to every page a term appears on.
MOVE 05
Content page anatomy + overview
Breadcrumbs, plain-language overview, page tags, inline term tooltips, and an On This Page TOC on every content page. Overview page for every section providing brief, guided introduction to content without needing to sift through.
MOVE 06
Inline content components
Standardized code blocks with one-click copy, and three distinct callout types: notes, tips, and warnings.
ACCESSIBILITY
I pushed for WCAG-recommended line height (1.5× minimum) across the board. It came up in design review when a tighter version was proposed — dense technical content needs that breathing room.
OUTCOME
Research-validated results
across 20 usability sessions.
40%
faster task completion in usability testing vs. the original experience
6
redesign moves
20
usability sessions validating the work across technical and non-technical users
REFLECTION
What I'd do differently, and what I'd do again.
What worked
What I'd do differently
If I could, I'd measure…
Search abandonment rate, time-to-first-successful-page, and support ticket volume.
AI in this project
Check out my other work!
