Too Many Clicks!
Problem to Solve
Rally is an industry-leading enterprise application for managing agile software development. At its core, Rally helps software development teams, programs, and businesses increase efficiency, predictability and alignment of work to strategic goals. The rollup of data depends upon team members updating the status of their work on a daily basis. Not surprisingly, the most frequently used pages in the application are detail views of artifacts like user stories, defects, tasks, and features.
The often repeated task of updating the details of a work item were slowed down by the clumsy interface that required too many clicks: Select the item to edit -> View the details -> Select the option to edit in the Actions menu -> Edit the field -> Save changes -> Hit the back button to return to the original context.
Previous version of the detail page and edit modal:
More than 14 different types of artifacts in the application used the same page flow and interface for viewing and editing details. Rally needed a consistent and modernized UI for creating new work items and updating them quickly across the entire product.
The solution had to be scalable to handle many types of artifacts with varying amounts of information displayed including lists, forms and charts. Some items had a dozen or so sub-views of related information to be viewed and edited. Very often, the sub-views contained tabular data that was displayed in an older UI framework that did not resize well and required as much horizontal space as possible. The first increments of the design could not depend on those tables being updated.
A small group of enterprising developers at Rally started building a new framework for editable detail pages as a hackathon project. Their working prototype was a great starting place to begin the design research.
Internally, we used the hackathon project with real data for several months. Opportunities to improve the experience surfaced organically: Are separate view and edit modes necessary, or can updates be made instantly and saved automatically like the rest of the application? Are the most frequently modified and viewed fields positioned for easy access? Does a modal window ease customer concerns that they can easily get back to where they started? I set out to answer these questions and more with interactive prototypes tested with our staff in hallways, and with customers in person and via WebEx.
Flow diagrams of the options to test:
We tested 3 different options, and iterated on the designs based on feedback. While the modal option gave users more comfort by preserving their context, the horizontal real estate was highly desired and not worth sacrificing with a modal design. Plus, detail pages are frequently linked to from emails and thus needed a URL of their own to copy, paste and view separately.
Various versions of the prototype tested:
Navigation between sub-views was also tested using icons only and icons with text labels, positioned horizontally as a ribbon, or as a left sidebar. The fields to make most prominent were discovered through metrics and customer interviews. The auto-save function was also tested through wireframes that explored options for indicating the saved status and error handling on required fields. Collapsible groupings of related fields were also tested for usability and customer value. The addition of a Done button instead of Save was also validated.
The new functionality was rolled out out to customers as an opt-in beta. We gathered tons of feedback on actual usage of the user story detail page, while the dev team expanded the updates to tasks, defects and features. Our data scientist monitored usage patterns and adoption rates as we addressed feedback concerns.
Here’s how the editable detail pages look now across various artifact types:
The most surprising theme in the feedback was an issue of trust. The majority of users greatly appreciated the speed with which they could make updates in the new version. Users who were primarily consumers of the information and rarely edited had a fear of accidentally making a mistake. The auto-update model of Google Docs was not comfortable for some users, who preferred a view mode and save button. Before closing the beta, we added an Edit/View toggle that could be saved as a preference to increase customer trust.
As the remainder of the 14 legacy pages for other artifacts continue to be updated, we’ve also learned that designing for the most complicated use case (the user story detail page) doesn’t always result in the most optimal experience for simpler detail pages. Consideration of the entire ecosystem at play is critical to maintaining a consistent experience that does not have to be relearned over and over again.
Wendy Constantine, ux design lead
Many thanks to the collaborative efforts of:
— Andrew Homeyer, developer
— Even Flow dev team, Raleigh NC
— Michael Fleetwood, ux researcher