ServiceNow: Dependency Feature
Simplifying the dependency feature on a roadmap tool
At a Glance
My Role: Sr. UX Designer: Interaction & Visual Design, Research, Prototyping
Timeline: 6 Weeks
Team: Lead PM, Lead Designer of the Alignment Planner Workspace, Dev Lead, Sr. Developer
Problem
ServiceNow’s Alignment Planner Workspace (APW) has many tools to let users, primarily C-suite execs and EPMOs, strategize and align on planning items across their departments and teams goals. Most planning items either depend on other planning items, have items that depend on them, or both. APW has a feature to create a dependency between two planning items, but it’s slow and takes many steps.
I needed to enhance the dependency creation flow by providing a more streamlined experience within the roadmap tool.
What I Did
I owned and led the visual and interaction and design of the dependency creation flow. I conducted research, defined visual direction, interaction patterns, prototypes, and created the documentation for the roadmap component for ServiceNow's internal Design System.
Impact
25%
Decrease in time to create a dependency on the roadmap tool.
25%
Decrease in time to create a dependency on the roadmap tool.
25%
Decrease in time to create a dependency on the roadmap tool.
Understanding the Roadmap's Interactions and Components
I needed to understand how the dependency feature and roadmap exist currently and what other projects and changes were being proposed for the roadmap.
Existing flow and anatomy
A planning item has a badge on its left and right side for its dependents and dependencies.
A planning item, the core object on a users roadmap.
Clicking on a planning item brings up a popover with metadata about the planning item and its dependents and dependencies
Users can also see dependencies in a side menu and edit them there.
The current create dependency flow takes multiple steps and requires multiple modal inputs.
Scope and Constraints
Beyond creating the dependency feature, there were many other high-level changes happening inside of the APW, so I needed to learn about each of these projects to better optimize my design direction. These changes included:
Changes to the data models of planning items and the way they’re grouped
Changes to the page header for APW which contains product navigation & primary & secondary actions
Adding support for more dependency types between planning items, such as start-to-start.
A large scale visual redesign was planned for the roadmap tool, which limited how much I could change with the existing elements on the roadmap.
Design Approach
The roadmap tool has many visual elements going on all at once. Simplifying my design was key to making sure I wasn’t complicating the interface further.
My main goal was to reduce the amount of effort and time it took users to create a dependency. Given the visual complexity and compactness of the roadmap I focused on two different design principals to guide me:
Understandable
Make the feature discoverable and clear on what actions users can perform while utilizing the dependency creation feature.
Understandable
Make the feature discoverable and clear on what actions users can perform while utilizing the dependency creation feature.
Understandable
Make the feature discoverable and clear on what actions users can perform while utilizing the dependency creation feature.
Simple
Keep UI elements and interactions as simple as possible to avoid adding extra elements to the interface.
Simple
Keep UI elements and interactions as simple as possible to avoid adding extra elements to the interface.
Simple
Keep UI elements and interactions as simple as possible to avoid adding extra elements to the interface.
These principals were at odds, so I started my design explorations focusing on understandability and simplified the UI over time.
Working within the Design System
One challenge to solve while creating the designs was making sure elements I was designing fit into and align with ServiceNow’s design system. APW touches a different product area than the rest of ServiceNow, which is primarily an IT focused company with its pages being lists and forms. As a result, APW tends to need to create our own components as the existing SN design components do not create an ideal user experience for us. I based my designs off existing components that were similar, such as gantt roadmap component and the node map components.
Starting with Understandability
I broke the feature into two different steps, the control to start the dependency creation process, and creating the dependency between two objects.
Initially while exploring the ways users could start the create dependency flow, I made the controls visible on the roadmap to avoid discoverability issues. I learned several data points on the way to inform my designs.
Different explorations playing with placement, style, and shape.
The roadmap page has many UI elements, such as the milestone bar that exists on top of each planning item. This meant I couldn’t put the add dependency action near the top of the bar as that would create confusion as to which feature the add action referred to.
Additionally, adding UI above or below the planning items would require more vertical space, which was already at a premium for our users, so I moved away from these patterns.
Another design pattern I explored to build in support for multiple dependency types as well as the ability to add milestones directly on the roadmap. However, I learned that this design solution was out of scope for this project dependencies but was good consideration for the upcoming redesign of the roadmap tool.
I explored building in support for multiple dependency types as well as the ability to add milestones directly on the roadmap. We deemed this out of scope for now due to the large-scale upcoming redesign of the roadmap tool.
I explored building in support for multiple dependency types as well as the ability to add milestones directly on the roadmap. We deemed this out of scope for now due to the large-scale upcoming redesign of the roadmap tool.
I also created a secondary flow for creating dependencies between planning items that are not close together on the roadmap, but was deemed this design out of scope.
Prototype Testing: Dependency Creation
Once the user started drawing the dependency line, I wanted them to be able to know they’re in the draw dependency state and be able to follow where their cursor is. I explored multiple stylings and different aspects of the design including the line type, width, color, scrims, and transparency outlines in clickthrough and coded prototypes.
From the testing, I found users were able to easily follow the cursor and so I shrank the line and removed the scrim to reduce visual noise.
Simplifying the Final Design
To simplify the visual elements of the roadmap I put the create dependency action behind a hover state on the dependency badge. I originally was concerned about discoverability and accessibility, but found through research this is an interaction pattern similar to many diagramming tools, which our users are familiar with and use on a regular basis. By getting to test with coded prototypes, I deemphasized the hover and cursor states during the “draw” step and used a combination of lightweight hover & cursor states to allow users to easily track their cursor along the canvas. I aligned closely with the node map components visual styling, but had to make some properties more prominent due to the roadmap being more visually busy.
Originally, I had made the create dependency flow to support multiple different dependency types (finish to start, start to start, start to finish) but our data showed that 98% of dependency types are finish to start so we scoped the original release to just support that dependency type. I also created designs to support multiple dependency types whenever it’s prioritized.
Additional Features
Editing and Deleting Dependencies
Along with quickly creating dependencies, I gave users quick access to editing dependencies from the planning item popover that appears on click. Previously, users took more time to do this as they needed needed to navigate multiple menus to perform these actions.
Since these were secondary actions, I put these actions into the popover rather than on the roadmap canvas to reduce visual noise. Given that delete was a very uncommon action and I didn’t want to elevate destructive actions so we left that action out of the popover, using friction to reduce accidental deletions.
An early exploration with delete on the canvas.
Edit was built into the planning item popover, but I left delete off to avoid accidental deletions.
Usage Guidelines and Handoff
Along with doing handoff with the immediate dev team, I worked with ServiceNow’s Usage Guidelines team, a team dedicated to building out our internal development and design system portal, to make the entire Roadmap component and the dependencies functionality easily accessible to the entire ServiceNow Organization for use in other products and features.
Along with doing handoff with the immediate dev team, I worked with ServiceNow’s Usage Guidelines team, a team dedicated to building out our internal development and design system portal, to make the entire Roadmap component and the dependencies functionality easily accessible to the entire ServiceNow Organization for use in other products and features.
Along with doing handoff with the immediate dev team, I worked with ServiceNow’s Usage Guidelines team, a team dedicated to building out our internal development and design system portal, to make the entire Roadmap component and the dependencies functionality easily accessible to the entire ServiceNow Organization for use in other products and features.
Along with doing handoff with the immediate dev team, I worked with ServiceNow’s Usage Guidelines team, a team dedicated to building out our internal development and design system portal, to make the entire Roadmap component and the dependencies functionality easily accessible to the entire ServiceNow Organization for use in other products and features.
Along with doing handoff with the immediate dev team, I worked with ServiceNow’s Usage Guidelines team, a team dedicated to building out our internal development and design system portal, to make the entire Roadmap component and the dependencies functionality easily accessible to the entire ServiceNow Organization for use in other products and features.
Impact And Learnings
I brought our users the ability to create dependencies on the canvas, a much requested feature.
15%
Support Calls
Billing related customer support call volume decrease
15%
Decrease in support calls related to billing
Learnings
If I were to do this project again, I would push harder to test with a variety of users. User testing for this project was done by me with internal guerilla tests and by PMs in client meetings, neither of which are like a real world scenario, leaving me to still have doubts about the discovery of the feature.
One key take-away was that sometimes it makes sense to prioritize the short-term and ignore the long-term. There were many tradeoffs or edge cases I had to learn to ignore which made sense due to the upcoming visual design refresh and from a business perspective.