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.

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.

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.

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.