Appian Docs Redesign

Addressing Usability Concerns: Modernizing the Navigation Experience

A user survey (n=118) showed that 44% of users experience difficulty navigating the site. Describing the “ideal docs site”, 95% of users prefer a book-like structure, with chapters and topics.

I approached the redesign first via this analogy: books follow a tree-like structure, with sentences as leaves connected to paragraphs, chapters, and sections.

Unfortunately, Appian Docs uses collections and cannot support breadcrumbs.

I focused on the next-best solution: improving navigation by unifying and enhancing the site's information hierarchy.

Navigation Bar Redesign

How can Appian Docs navigation provide users with enough information so that they know where to go?

With my UX collaborator, we reviewed 20+ documentation sites, noting that many use a "mega menu" style. A "mega menu" is a navigation tab that expands downwards, spanning the full width of the screen, and is able to support additional context to items.

While maintaining consistency with Appian.com, I adopted a similar approach for Appian Docs.

How can we ensure navigation remains usable on smaller screens? About 15% of Appian Docs users (~20,000) access the site on mobile devices.

I defined breakpoints for Appian Docs based on popular device sizes and Chrome browser breakpoints. Chrome is the browser most used to access Appian Docs.

On smaller screens, visible items are enlarged and lose context (a “parent” item, for example). To address this, I added breadcrumbs to the navigation bar. Breadcrumbs strengthen users’ mental map of the navigation hierarchy and eliminates the need to remember their precise location within this menu.

I validated these design decisions through usability testing, where 6 participants completed information-finding tasks on a mobile device. I wanted to ensure that

• users are able to orient themselves on this navigation
• there are minimal surprises to how it works
• there are no difficulties or inaccuracies in tapping/swiping interactions

The new navigation bar met user expectations: all participants were able to find necessary information on the redesigned Docs Site, even on a mobile device. Participants particularly appreciated the faux-breadcrumbs!

"On mobile as you click you forget where you are, so breadcrumbs were really helpful"

With UX stakeholder feedback, I made additional styling improvements to finalize the design.

Content Browser & Table of Contents Redesign

Within content pages, the Content Browser and Table of Contents components guide user navigation — showing related topics and enabling in-page section navigation respectively. However, their outdated design complicates usability: hallway test users (n=4) are confused about the difference between the navigation components.

I began the redesign with a competitive analysis of 10+ sites and a design audit of both components. I identified three main usability red flags:

• Unclear information hierarchy. It is unclear how these two components support each other and with the content of the page.
• Visual overload. The varied font sizes, weights, and variety of colors contribute to visual noise.
• Lack of appropriate design analogies. The table-of-contents component interaction/animation does not map onto its intended behavior, leading to user surprise.

Addressing these issues,

My redesigned Content Browser uses varied font weights, colors, and indentation to communicate information hierarchy across articles and topics.

To minimize visual noise, the Content Browser uses a subtle color palette and includes controls to collapse the component.

I mimicked scrollbar designs in the Table of Contents component, signaling its purpose (exploring contents on the page).

I validated these design decisions through usability testing. Aiming to verify that the visual affordance of these components align with users’ expected interactions, I asked 4 participants to interact with a static prototype. Their responses confirmed that the new navigation components were effective! 

"I expected to go to another article if I click [on a title in the Content Browser]."

"Clicking on [section title in the Table of Contents] doesn’t actually take me to where it is supposed to go [...] I expect to go to another part of the page, below."

Option A: Dropdown Content Browser.
The product version dropdown is accessible within the page.

This design uses an intuitive dropdown interaction, which I expected to invite user engagement. However, I was concerned about the crowded top-right touch area. Additionally, placing the version selector within a page could lead users to think it only affects the current page, not the entire product topic.

Option B: Sidebar Content Browser.
The product version drop down is nested within content browser.

This design uses a less common interaction pattern - a secondary sidebar - which I anticipated would be less interactive, especially for older users. I traded off the product version selector's discoverability in favor of creating a better mental model for how it impacts the content.

I took notes of users’ reactions, actions (tap, swipe, etc.), and questions and organized my findings in an affinity diagram.

Most notably, I found that the "most interactive" design is not the most effective. In detail:

• Option A is more interactive, allows for greater margin of error in interaction and less accurate understanding of Appian Docs and Appian solutions. 
• Option B is less interactive, communicates better touch targets and conveys more accurate understanding of Appian Docs and Appian solutions.

With these insights and feedback from key stakeholders, I refined the design to its final version!

Addressing Accessibility Concerns: Image Zoom

To address these issues, I worked closely with our Accessibility Auditor and studied a11y best practices. My design process always starts with an audit of the current design, testing specifically for accessibility concerns.

This zoom-in functionality on images suffers from several accessibility and usability issues: the overlay has no visible exit controls, users cannot exit the overlay using their keyboard (“esc” key), and the content behind the overlay retains interactivity.

I created an initial design to address accessibility issues and tested it with 4 participants aged 20-45 (elicitation studies). I showed participants an “expanded” version of an image on Appian Docs and asked them to describe behaviors they expected to have caused the enlarged image.

This informed the final design, which uses the most common user interactions. I then worked with developers to integrate accessibility features into the zoom-in functionality, documenting these in the design spec.

Addressing Outdated Interactions: Code Box

I redesigned the code box on Appian Docs to deliver a more enjoyable experience to users with varying backgrounds in computing. 

In the previous design for the code box,

• the "copy" icon doesn't resemble common icon designs, making it less intuitive
• the layout of this component creates "stacking" between code and the "copy" icon
• the color contrast and lack of white space makes this component visually overwhelming

What makes a code box “modern”? I conducted competitive analysis on other documentation sites and abstracted the elements that contribute to the modernized look and feel. 

• These code boxes all have a utility bar above the code section, separating functionalities (copy, reporting errors, switching to dark mode, etc.) from its contents.
• These code boxes all have a unified color scheme, with minimal color contrast between the code section and the utility bar.
• The "copy" icons are more common designs.

With insights from competitive analysis, I came up with a new design – a complete UI refresh: updated color scheme, new "copy" icon, revised tooltip design, and a programming language indicator.

I conducted usability testing with 4 participants to validate that users can successfully interact with the code box. Post-task, I prompted users for more specific feedback.

While most found the design utterly unremarkable (“I guess it just looks like that…”), one participant appreciated the language indicator, particularly as they were unfamiliar with programming. This suggests that what seems boring to experienced users can be reassuring and user-friendly for new users. Boring can imply ease and trust.