Rally Framework

Context

Rally is a 17 year old SaaS tool; it is an Agile lifecycle management application and helps organizations manage hierarchies of people, work and time. It serves multiple personas and supports several methodologies: SAFe, SCRUM, Kanban and Objective-Driven.

The legacy tool, has about 30+ core pages (plus a lot of reports and artifact pages) and allows organizations create infinite amount of custom pages. Because there is little to no management of custom pages, the tool can quickly become bloated for some customers. Our core pages tend to be very redundant, some of them slight variations of each other. Additionally, some of the legacy pages were written in ext.js and tps.js which had really poor performance especially for our XXL enterprise customers.

Challenges

Simplify the hierarchies of people, work and time across multiple processes for companies ranging from small start-ups to giant enterprises with 10 of thousands seats. Our largest customer has 30K users and that’s a lot of data to handle!

Make the tool feel like a one-page app that’s configurable and flexible enough to handle all use cases across all personas.

Problems with the legacy app

  • Overwhelming information architecture that hadn‘t scaled well over the decades of the product life-cycle.
  • Stiff hierarchy in our data model prevented us from solving new use cases for our largest customers.
  • Tech debt and producing à la carte customer requests led to the production of pages that were slight duplicates of one another, yet did not maintain parity in functionality.
  • No unified vision driving the product, resulting in a feature-bolting development approach. 
  • Outdated UI, no consistency across pages.
  • Many customers created their own custom pages and apps, to meet their unique use cases which lead to unmanageable information architecture for large organizations.
  • Which brings me to: pages and pages and pages–too many of them!
  • Performance, or I should say lack thereof. One of customers’ top complaints
  • The powerful complexity of the tool was perceived as bloated and convoluted by our users.

Results

  • Rally was the first out of 16 SaaS products to implement the new design pattern library, a modern UI and gives our brand a fresh new look.
  • By creating a one-page framework, it eliminates the need to support and keep functionality parity on multiple pages.
  • Using a modern component approach increases flexibility and speed in future design and development.
  • Allows rich flexibility for users to customize their pages to their unique needs eliminating the need to develop a la carte pages for customer requests.
  • Performance was significantly improved by
    • Replacing slow ext.js and tps.js pages with modern react libraries with support and tooling
    • Moving toward a more ReSTful API.
    • Single-page app development uses common data between pages without having to reload from server.
    • Move from compound to solidified data model to reduce complexity.
  • During user tests the “pageless navigation” tasks got a ease of use score of 6.125 on a scale of 1-7
  • 4 of the 8 participants unprompted said pageless navigation was simpler/intuitive

User Test Quotes

I feel this new pageless nav is more intuitive. I remember feeling overwhelmed (when I was learning the current app) and frustrated at first. There’s less stuff on the page, which is also visually appealing.
This makes a lot of sense...I feel like I know where I’m going, as opposed to digging for the right page for the right job
It’s nice that this view lets us focus and put stuff away
Definitely simple relative to what you’ve got now. I think this would resonate with my teams. The simpler the better, as it can be difficult collaborating with onshore and offshore

My role

Once I drove the cross-functional definition the larger product strategy for the relaunch of Rally, I lead the UX team (2 researchers and 2 designers plus myself) through activities such as: user journeys, defining customer pain points, competitive analyses, prioritizing use cases, writing hypothesis statements, whiteboarding, and coordinated the work amongst the team.

We wanted to design a new tool that was extremely powerful, customizable, but felt simple to the user. Our goal was to transform a tool that has (potentially) infinite amount of pages and build a framework that feels like a one-page app to be built with flexibility and extensibility in mind. The framework should allow the user to look at their data in “views” that best suits their tasks based on role, organizational needs, process, and level of hierarchy they are managing.

In order to scale agile at every level (from small teams to orgs with 10’s of thousands of users) we needed a way to seamlessly traverse up and down the different levels of hierarchy as roles require. In doing so, organizations will be able to leverage the information they need at every level.

Our Researcher created personas based on jobs to be done after a lot of collected research to help communicate the different needs of all the roles at every level of the organization.

Our research findings and usage data suggested that most users have <5 pages that are relevant to them in our app. We wanted to reduce the perception of complexity in the information architecture, and still allow users to endlessly customize their experience. Our approach was to design what would feel like a one-page app that users could tinker with and save the settings that work best for them.

As we worked through the various workflows and user journeys, it became obvious that we could show the data in 3 different views: a list, board, timeline (with the ability to add more in the future) and give users to be able to scale up and down the hierarchy of the organization and work.

We also needed a way for users to quickly perform their tasks of “Prepping”, “Planning”, and “Tracking” their work in a seamless way that would prevent them from losing context. These similar activities happen at the team, program and portfolio level, we hypothesized that the templates could be the same and we could just adjust the hierarchy of people to get to the correct hierarchy of work items.

We created an information architecture that communicates a consistent pattern of agile at scale. The pattern is mirrored up and down the organizational levels. The granularity of the content adjusts dynamically based on those levels.

Through a lot of whiteboarding and iterating we landed on a way to collapse views based on their activity based tasks.

As our hypotheses were validated and becoming solidified, I met with engineering regularly to discuss and influence the new data model in order make sure the new structure would allow us to solve use cases we defined.

I created a clickable mega prototype of an end to end experience for multiple use cases in order to communicate the UX vision and aid the technical implementation strategy for PM and engineering. Engineering especially found it very useful to understand the intent of the framework, how to build the components and structure the backend. View the prototype.

A high fidelity, clickable prototype to test out the panels, hierarchy and toggles.

It was of utmost importance to implement reusable components and modern code libraries in order to improve performance, create flexible layouts that can be easily changed and expedite the development process.

I helped define the UI using the newly created pattern library (by the centralized design team), making sure it became a visual language with consistency and flow. I pushed pixels to create perfect mocks for engineers to develop and provide support and QA during implementation.

New Designs

This is a prep (backlog) view at the portfolio level. We consider the backlog a special widget that collapses and expands depending on the activity, in this case, fully extended

This is a planning view at the program level. The split view allows users to drag work from the backlog widget over to their preferred view (list, board timeline) to plan it.

This is a tracking view at the team level. The expanded ``planned`` work panel allows users to track their work or progress in their preferred view (list, board timeline). In this case a team Kanban board

Screenshots from current app.

Current Backlog page, under the navigational item ``Plan.`` This page is list of user stories, defects, and defect suites. To create a portfolio backlog you would have to go to different page.

Current Portfolio item timeline. It has very limited functionality, it's static, has no ability to make changes in real time, no ability to drill in or see which teams are doing the work among other limitations.

Current Team board. Individual Contributors hate using the app, most of them will avoid logging in, therefore the data rollups are never accurate making planning really difficult for orgs.

User Test Quotes

For someone coming in, they wouldn’t have to worry about which Plan page they want like today’s Rally.
I like the concept, and there are a lot of pages in Rally with the same functionality, so I like the simplification.
I think it’s good that it can be configured. You need the balance of flexibility with not getting lost in the details(...) If the base templates are pretty good, and I’m just tweaking them around the edges, then that’s better than what there is today.
This makes a lot of sense. The freedom to group in different ways makes a lot of sense. We typically have so much WIP, the board views get problematic, so teams run out of screen real estate. I have others that are mainly Kanban, and they’d love a better way to manage their work. No matter what we create for standardized use, there’s usually always at least something that doesn’t work for everyone.