The Portfolio of Matthew Almand

Case Study

Asset Details

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

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.
The mixed use layout of the current asset details can vary wildly between companies and types. Yet the two main activities are pretty consistently stated by users across companies.

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:

  1. Story writing, discussion and planning using the description field 
  2. Adding and updating story details 
  3. Estimating stories
  4. Reviewing conversations related to the asset
  5. 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.
The proposed changes gives the description field more space and prominence in the layout. Read-only information is separated away from the editable content.

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.  

Note the name includes "heavy data" in the title. Building the prototype in code meant easy data population of fields.
When a story is new only the initial required fields are filled. By forking the prototype I can easily present the different states for the developers to refer to.

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.