ServiceNow: Dependency Feature
Simplifying the dependency feature on a roadmap tool
Note: Due to NDA, some designs have been omitted.
Case study focus: Visual Design, Interaction design
Timeline: 6 weeks
My Role: Sr. UX Designer
Team: Lead PM, Lead Designer of Alignment Planner Workspace, Dev lead, Sr. Developer
Challenge:
Enhance the dependency creation flow within the Alignment Planner Workspace roadmap tool by introducing a new feature that enables users to create dependencies directly on the roadmap, providing a more streamlined experience.
Problem:
ServiceNow’s Alignment Planner Workspace (APW) has many tools to let our users, primarily C-suite and EPMOs, strategize and align on planning items across their departments and teams goals. One common attribute of most planning items is that they 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. My goal was to create a feature where users can create a dependency between two planning items directly on the roadmap to save users time and effort.
Discovery
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 details about the planning item with a list of dependents and dependencies. Clicking a planning item brings the users into a details panel that appears above the roadmap.
Users can also see dependencies in a side menu and edit them there.
The current create dependency flow takes multiple steps and requires multi-modal inputs.
Scope & Constraints
Beyond creating this 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.
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 clarity 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 also created a secondary flow for creating dependencies between planning items that are not close together on the roadmap, but we deemed this design out of scope.
Creating the dependency
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.
Simplifying the final design
While I was able to test these in clickthrough prototypes I built in figma, I got extremely useful data from getting to use a coded prototype from a dev who did a spike on the project. Utilizing this coded prototype I found the cursor was still easy to follow, meaning I could shrink the lines and remove the scrim to reduce visual noise.
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 & 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.
We built edit into the planning item popover, but purposefully left delete off to avoid accidental deletions.
Usage Guidelines & 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.
Retrospective
I brought our users the ability to create dependencies on the canvas, a much requested feature. 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 exactly like a real world scenario, leaving me to still have doubts about the discovery of the feature.
Additionally, I feel like there were many tradeoffs for short-term gain over long-term since there was an upcoming visual design. The decision to focus primarily on short-term, quick win product changes made sense from a business perspective since our developers focus was on the backend and data model changes. However, I would have liked to be able to explore alternative flows not just for dependencies on the roadmap, but also for creating milestones and other planning item properties in a cohesive pattern.
Since I created new components and interaction patterns that currently did not exist inside of ServiceNow, I went through a 5 step process with ServiceNow’s Design Review board for approval which involved a meeting with the design review team, an accessibility team, and a visual experience team review that oversees all products across ServiceNow. The accessibility team was incredibly great to work with, and helped me create designs and documentation on how to scale the feature to be usable beyond its current mouse/trackpad-required design and support keyboard-only users as well.