The Portfolio of Matthew Almand
Menu
Case Study
Asset Details
Solving the challenge of managing the details of Agile Stories and Tasks
Platform
VersionOne Agile Web Application
Problem
The asset details view is the most used view of the whole VersionOne application. It houses the details and description of any asset type whether a story, defect or task and offers various customization (per asset type) to serve companies in their needs such as field enforcement. However the asset view has UI challenges regarding the description field, clarity of editable fields and layout problems.
Goals
The asset details update concept seeks to focus users to the proper view based on tasks to be accomplished allowing easier interaction and separating editable fields from read-only.
Team
Project Manager, Lead Developer, Project Lead, Tester, Designer
My Role
UX/UI Designer
Project Status
Phase 1 Released
UX Phases
User Interviews, Analytics Review, Competitor Analysis, Prototype, High-Fidelity Mocks
Section #1: The problem
UX Rot
The asset details view in the VersionOne tool has seen many iterations and revisions over a number of years. The current version of asset details has seen two UI visual refreshes but its UX has not been updated to address usability issues created from UI visual design changes and additional features introduced in the view.
Customization abilities provided to the end user, company requested features such as “important fields” as well as custom fields means the asset details view can vary dramatically from asset to asset and company to company. This has always meant a real UI challenge when attempting to layout the content in a logical and natural way.
Problems to resolve:
- The description field is hard to identify at times based on content amount and is sometimes pushed below the fold due to customization and the number of details fields present.
- Users identified the two most common activities as editing the description field and updating details and struggle at times to do so given the mixed nature of the layout.
Section #2: Proposed Changes
Understanding JTBD and top tasks
From tracking analytics via Pendo, users’ feedback through the ideas portal for VersionOne, and direct discussions with our biggest customers we identified the top tasks on asset details as:
- Story writing, discussion and planning using the description field
- Adding and updating story details
- Estimating stories
- Reviewing conversations related to the asset
- Checking status and reviewing details
With continued discussions and review with our customers as well as team discussion given our domain knowledge and Agile practices experience we came up with a list of proposed changes.
Proposed Changes
- Better use of columns to present separation of content based around tasks to be accomplished as well as editable fields vs. read-only
- Visual changes to read-only content to easily identify it vs. editable areas
- End-user defined view customization stored in the users’ profile to remember layout preferences when moving from asset to asset.
- Clear delineation of description field from details fields to support task completion.
- Reordering details fields to place “required” and “important” fields at the top.
Section #3: The Prototype
Using code to build the samples
Since the proposed changes would be built into the existing UI design of the product, the content amount would vary dramatically and the main changes would be interactive, I chose to build the prototype directly with HTML/CSS. This allowed for freedom of easily filling fields up with data vs. having to build these in Figma, and allowed me to understand how content would flow in relation to panels being open vs. closed. In summary it was faster than building in Figma with the benefit of interaction.
For this I chose codepen for its ability to share both the prototype and the underlying code very easily.
If you interact with either prototype you will be able to test functions such as opening/closing the conversations panel, swapping the description and details columns and resizing those columns to various degrees.
Note that this prototype only uses HTML and CSS. Since it is a prototype I was limited in functionality but the goal was to convey the concepts and how they would function. Given that the code already existed the developer did not need full specs to be able to sucessfully recreate these views in the app. I did originally build a version using javascript that would allow users to actually drag to resize the width of the main columns but we determined it was not needed as the set sizing was enough to give users the customization they needed. Draggable Version
Section #4: Follow up & Review
Findings & Discoveries
Receiving follow-up feedback from users, we discovered that most users appreciated the changes (especially the ability of the tool to save layout preferences across assets). We did have a handful of support tickets from users, however, that did not like the fact that the description field no longer spanned the full width. I and the Project Manager had proposed during the initial queries, the idea of allowing users to fully hide sections not in use so that they would have two or one column(s) to work in. So users confirmed the idea based on their feedback and so now we can look to build this function into a future version.
Due to a lack of resources, we did not set up a success criteria plan to be able to track and measure whether these changes improved the experience or not so we only have verbal feedback about their experiences with this change.