Solving the challenge of managing the details of Agile Stories and Tasks
VersionOne Agile Web Application
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.
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.
Project Manager, Lead Developer, Project Lead, Tester, Designer
Phase 1 Released
User Interviews, Analytics Review, Competitor Analysis, Prototype, High-Fidelity Mocks
Section #1: The problem
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:
Section #2: Proposed Changes
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:
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.
Section #3: The Prototype
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.
Section #4: Follow up & Review
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.