B8 — UGO II — our product is: Imagine Scrum
The transition of many companies to remote-only work during the COVID-19 pandemic has showcased why remote team building is so important for today’s work culture. Without it, remote workers spend most of their time working alone, and the time they do get with their teams is spent in rigid meetings. The limited interaction can reduce social connection and engagement from employees.
Even after the pandemic becomes a thing of the past, many companies are continuing remote work. The next few months are a perfect time for UGO II to offer a permanent solution that bridges the gap between remote and in-person work. The solution should offer some mechanism to continue team building outside of meetings, and provide space for team members to build closer connections with each other.
While these are difficult problems to solve, the reward is great. If remote work can be brought on par with in-person work, then people could work from anywhere. We would no longer be limited by location when pursuing work we truly enjoy, nor be treated differently based on our proximity to the office.
Our product, Imagine Scrum (IS), solves these problems for agile teams by adding to the traditional scrum experience. IS is a video-calling application with an integrated scrum note-taking feature — an appealing solution for teams looking to conduct scrum remotely. Once in the application, team members encounter IS’s team-building features.
During the process we learned the importance of user feedback. Despite our preconceived notion of what our product would be, feedback from users still gave us essential information which we used to improve the product.
Background
In the switch to remote, many companies quickly adopted tools for virtual meetings and work sessions. In our time working during the pandemic, the members of UGO II have personally experienced a variety of these tools. However, the same tools lack facilitation for team building, culture formation, and physical connection compared to in-person work (Morrison-Smith & Ruiz, 2020).
Messaging platforms such as Slack offer quick text communications for both team-wide and private discussions. However, the asynchronous and persistent media does little to reproduce the live audiovisual experience one would have speaking face-to-face.
Google Meet and Zoom are popular video call solutions. At face value, they simulate the audial and visual experience of holding a meeting in person. However, they do not do enough to encourage socialization and team building. If any, that initiative must come from the users of the platforms. Many teams lack such initiative.
Anecdote: We held our weekly project meetings on Google Meet. We are all friends outside of the course, but our team cohesion declined over the term, as we began to associate the group calls with work. It took everyone’s commitment to continue engaging socially.
Finally, sites such as gather.town offer a novel and innovative way to create virtual spaces that mimic a physical environment, while integrating the features of a video call. They do well at prompting team-building and socialization, because users get an extra dimension of interactivity: motion. However, we think these products may fail to attract companies because the simulated environment is rarely needed in most serious meetings — they serve little more than a visual distraction.
Some tools fail to establish spontaneous, casual, and welcoming conversations. The solutions which do, seem to have trouble being taken seriously. Imagine Scrum solves both issues by balancing the two uses: team event planning, and scrum meetings. Due to this, we believe IS has greater potential than existing alternatives to bring remote team-building closer to the in-person experience.
Context Study
Profiling Users
From our project topic, we created personas to identify the main users of our product: members of remote teams that lack cohesion. They are willing to put in some time and effort into improving team building, but might not know where to start. Within that description, our three personas covered a variety of perspectives.
Persona 1: As an engineering lead, Dave Barn’s responsibility included guiding his team through the transition to remote work. He noticed that his colleagues’ morale has taken a significant hit due to the lack of social opportunities. Dave wants to help his team improve their cohesion. However, since he has other responsibilities, he needs a solution that would be easy to integrate with his team’s daily workflows, not consume too much time, and be as accessible as possible.
Persona 2: Jason Winger’s persona helped us outline the potential fears and obstacles that users would face if they were to adapt our product. Jason is a young student, who is part of a virtual team project with a group of classmates. He believes some sort of team building activity could unite his teammates and make them work more productively together, but he lacks the initiative and boldness to solely organize his team.
Persona 3: Lily Perry’s team lacks proper cohesion. As a new hire, she is unable to navigate the complex organisational structure of her company and feels alone and misplaced. Not being acquainted with her teammates makes seeking help even more difficult. Lily would significantly benefit from a product that could both help her with her work responsibilities, and bond with her work colleagues remotely.
User Interviews
Our user interviews aimed to gather opinions on existing team building solutions, as well as what they think is effective team building. Our three main questions were
- When obstacles have you faced while trying to team-build remotely?
- What do you want to get out of your team?
- What does your remote team look like in the ideal world?
To go into depth, we asked
- How important is cohesion/team-building to your team?
- How satisfied are you with your current team cohesion?
- Do you feel your team has been provided with sufficient resources to support team-building?
- Do you feel you can fulfill your job responsibilities fully in a remote environment?
- Do you think your team members have fulfilled their responsibilities?
- Do you believe you contribute more than your team members?
All of our interviewees felt there was a major discrepancy between their team’s productivity and its cohesion since the shift to remote work. While they were satisfied with their team’s ability to accomplish work-related tasks, they did not feel their team’s cohesion was adequate. This confirmed that existing tools did not do enough for team building.
Affinity Diagram
We collected our interview notes for a more detailed analysis with an affinity diagram.
From the categories, we discovered a formula for effective team-building. Meetings that encourage team building and cohesion must foster an interactive and casual setting. They should be attended by as much of the team as possible, especially including management. Otherwise, team members would suspect that they are judged by their colleagues and managers for wasting company time on social activities. If this environment is achieved, it can foster organic and effective team building.
These descriptions reminded us of scrum. Scrum meetings are attended by the entire team, and already tend to be less formal than less frequent meetings. This pushed us toward the idea of leveraging scrum meetings as a basis for team building.
Hierarchical Task Analysis
In our hierarchical task analysis, we specifically continued to investigate scrum, alongside onboarding and team-building.
While coming up with tasks, we realized that management users and regular employees would do different things because of their differing responsibilitites. This is reflected in our diagrams.
Since ease of integration and accessibility was important to our users, we decided to design our login and onboarding flow to utilize existing wildly used products for logins, meeting creation, and scheduling. In addition, our base-scrum feature itself would be minimalistic to ease the transition from existing products into Imagine Scrum.
Design
We ideated four main features to tackle the problems we identified:
- Base scrum is the range of features that make our product usable as a scrum note-taking tool for agile teams. It is meant to attract users like Dave Barns who are worried about balancing productivity and team-building. Our minimalistic view of scrum reduces it to two simply questions asked of each team member: What DID you do, and what is there TODO for you?
- Off-topic scrum uses prompts and soft interruptions during scrum meetings to trigger non-work-related conversations. The conversations would hopefully help members learn more about each other, and make the meetings more engaging to participate in.
- Sharing who we are is an important part of team building. Setting up social profiles is a way to bring external information about each team member into our application. This also lets our solution integrate with third-party apps.
- Social event planning prompts team members to engage in both the planning and execution of team-building activities outside scrum. It gathers event suggestions from team members and makes it easy to schedule popular event ideas.
In our final design, all four features are implied to exist. However, we did not have the design resources to tackle all four. We needed to explore the ideas in more detail to see what to prioritize as core features of our prototypes.
Storyboards
First, we pitched storyboards showing how different features of our solution would handle the needs (user stories) of our target users. We referred back to our context study to stay focused on our users. For example, we built the storyboard for off-topic scrum using a tale of ourselves and our persona Lily Perry.
Lily Perry: As a team member, I want to ask my teammates non-work-related questions without feeling embarrassed about the content, and without feeling guilty about taking up team time.
Crazy 8s and User Flows
From here, we used crazy 8s to quickly come up with multiple (eight) initial sketches for each feature.
As a team we then picked the best sketch of each crazy 8 to develop into a more refined user flow.
By the end of the early design phase, we knew what to focus our limited design resources on. Base scrum was the basic part of our product needed for the productivity of our user s— without it, nobody would adopt it. Setting up social profiles, for now, would be an implied part of our design which assumes that social profiles have already been set up. Since it only happens once, we realized it was not actually as important to get right. Between off-topic scrum and social event planning, the simpler flow and concrete actionability of social event planning made it better suited for an initial product with only novice users. Thus, our prototypes would focus on base scrum and social event planning.
Implementation & Test
Our final design looks only somewhat like our user flows. We iterated heavily on the design as feedback came up over time, both from our own internal “eureka” moments, and from peer groups like Team Pear.
Low-Fidelity (Paper) Prototypes
To start, we turned our the user flows for base scrum and social event planning into low-fidelity Figma prototypes. Though intended as paper prototypes, we built them in Figma in order to make them shareable online for virtual user testing. The goal of this stage was to get a testable interactive design of our application and use the findings to refine our design decisions. While we had already tentatively decided on some high-fidelity aspects like colour, shapes, and shadow, we deliberately held back for this stage. We wanted our test users to guide us to the final product, rather than our preconceived designs.
With the first low-fidelity prototype complete, we created a test script consisting of a series of tasks to perform on the prototype — e.g. adding a DID, removing a TODO, responding to team-building prompts. In our three tests we focused on whether our app’s affordances were clear to the user, and whether the user could understand the purpose of Imagine Scrum. We received useful feedback, such as on the ordering of Past TODOs, DIDs, and TODOs, resulting in their complete rearrangement in the next prototype.
High-Fidelity Prototype
In our high-fidelity prototype, we added colors and shadows to make many of our affordances more obvious. With that came branding to contribute to the completeness of the app. We cleaned things up in accordance with Gestalt principles to make the UI highly discoverable. For example, we applied similarity by turning scrum and event planning (which were previously separate prototypes with completely different looks) into two tabs that conveyed their distinct but equally-important purposes.
Making our high-fidelity prototype fully interactive was extremely challenging because Imagine Scrum is nonlinear — the user can add, remove, or edit any DID or TODO of any team member, in any order. How we achieved this in Figma is a topic for a separate Medium article.
The final round of testing included heuristic evaluation and cognitive walkthroughs. This stage of evaluation was the final check to affirm that our product aligns with real world users and their problems while offering a satisfying, error free, consistent experience. The user should be able to recognize elements of our application and be able to efficiently use our application while being able to recover effectively from errors.
Given a detailed script of tasks to walk through, our heuristic evaluators focused on match between system and real world, user control and freedom, and aesthetic and minimalist design. Unfortunately, some of our users still fell into error states that they did not know how to recover from due to a lack of signifiers. This is amended in the final version of the prototype.
The cognitive walkthrough had less-detailed tasks. The aim of this evaluation was to monitor a novice user’s thought process. One thing we found was that the user’s desire to explore is being limited by the social event prompts, which disable interaction with the rest of the screen. This is unfortunately a limitation of Figma rather than our design, but it still affirms the direction we have to take if we implement social event prompts in a finished product.
In both the low-fidelity and high-fidelity prototype tests, it was hard to get users onboard with the idea that the app would be used while interacting with other people, when they were testing alone. Our scripts tried to simulate the behaviour of the other users with painstaking detail, but it is hard to test team-building without a team! One thing we could have done to make this better would be to participate in a mock scrum meeting with our users.
Final Prototype
Conclusion
Reflecting on our design process: user feedback is essential. Even before the ideation stage, user interviews gave us valuable information on what users wanted from a product in this space. For example, the importance of manager buy-in made us consider integrating team-building with a productivity app and led to our whole product idea. User evaluation of prototypes allowed us to refine the purpose of Imagine Scrum and how we communicated it. For example, the ordering of DID, TODO, and Past TODO sections in scrum was a shortcoming we were blind to due to how long we had been working with it — it took a user to point that out to us. Moving forward with Imagine Scrum and other projects, we will set aside time to engage with users to get their valuable feedback.
Imagine Scrum is not perfect, of course. One of the major limitations of our product is that it is a separate platform. Modern workplaces have a plethora of digital platforms and applications all designed to assist with modern work activities. As our user interviews showed, adding another product to this mix is a tall order. It’s for this reason that one of our future extensions is integrating our product into major video conferencing platforms, so teams can use our product with the platforms they already know and support. Hopefully, this will allow us to make remote work easier and more fulfilling for everyone.
Just Imagine.
