The Portfolio of Matthew Almand
TeamRooms
Providing a focused space for teams to practice Agile ceremonies.
Platform
VersionOne Agile Web Application
Problem
The largest user base in the VersionOne application is team members. The main application has so many features in so many areas that development teams cannot focus and perform team ceremonies easily. Teams must navigate, filter, and customize pages to perform daily tasks and updates.
Goals
The TeamRoom is a scoped view of a team’s backlog, stories, and tasks in a walled-off area so that teams can organize, focus and coordinate around their work and Agile ceremonies.
Team
Project Manager, Lead Developer, 8 Developers, 2 Testers, 2 Designers
Note: Our team lacked a UX Researcher so these tasks were handled by the PM and Myself
My Role
Lead UX Designer
Project Status
Released
UX Phases
User Interviews, Customer On-Site Visits, Analytics Review, Competitor Analysis, Sketching, Card Sorting, Wireframing, High-Fidelity Mocks
Section #1: Planning
Before there was the concept of a TeamRoom we needed to understand how the developer role used our product, where their pain points were, and what tasks they needed to complete daily, weekly, and only occasionally. We gathered this info via customer calls with direct users (not company reps), and through company on-site visits.
During the on-site visits, we attended daily stand-ups and sat with developers and product teams to discuss how they did their work and where they interacted with the VersionOne product.
Through these discussions, the daily tasks became most important to them because these tasks took the most cumulative portions of their time. Tasks that the team members only completed occasionally became difficult due to their infrequent nature, which usually resulted in the user forgetting how to complete the steps needed for the task.
From the discussions, we identified the following problems developers face in their day-to-day use of the product.
Developer / Team Member Problems:
Upon gathering the data and setting up an ideation session with the team the idea of a room was formed. The goals of this room were:
With the goals now defined for the room concept, we next looked at just what would go into the “panels” that would be shown/hidden as needed. This list was:
Section #2: Concept
Now that we had the goals and tasks completed I built a prototype in Axure to convey these concepts along with how we would handle their display and layout. The above screen shows the early Axure prototype.
Initial ideas like collapsing columns and drag progression were pulled from competitive analysis of other tools with these patterns.
I presented metric data and team members along the top as fixed so that while users might toggle panels visibility these pieces of information were always available.
Due to the fixed view nature, I made the team members’ avatars clickable to filter the panels just to their data. This would later prove to be a great feature for our users.
With the initial prototype, we went back to our users and walked through the concept with them. After two or three rounds we had enough feedback to build a high fidelity prototype of a TeamRoom.
Section #3: High Fidelity
I then created the mockups with the additional functions determined from the user reviews including the ability to add to the backlog directly, The ability to filter the view on a team member, the introduction of the team mascot, top panel view toggle, and the ability to toggle the panels view state directly over the panels.
Section #4: After Release
The TeamRoom and Room concept has been one of the most successful features of the VersionOne product even to this day. Teams love TeamRooms and are always asking for additional functionality so that they do not have to leave their rooms to perform additional tasks validating the goal of keeping the data in one view.
More recently with companies adopting SAFe as their method of Agile, it has become more prevalent that Team Leads, Scrummasters, and Product Owners, while not the largest user base, are the most frequent and heavy users of the tool. As a result, a re-thinking of Rooms is needed to evolve the tool further. We have begun this process in the first quarter of this year. However the Project Northstar is a very large undertaking so just as with the original TeamRooms it will be handled in Release waves.