The Project
Team Connect is an all-in-one solution for sports teams to collect information, communication, photos, and schedules. It had long been a valuable tool for sports teams, from players and parents to the coaches and managers. It exists as Android and iOS apps, as well as an app on the web. Ambitious teams can add more powerful administrative functionality by connecting their Team Connect and Club & League Connect accounts.
Team Connect was one of Stack Sports’ most popular consumer-facing apps and was to be the central hub for a plethora of further integrations. But before doing so, it had some problems that required addressing. We quickly determined to scrap the existing app, and from the ashes, we would assemble Stack Team.
Goal
Rebuild a consumer-facing sports team app from the ground up for mobile devices.
My Role
I designed many sections of the app and did user testing for each.
Results
The app is not yet released.
The Problems
Although a useful tool, Team Connect had many significant issues.
Every corner of the web app was uniquely bewildering, and the mobile apps were missing huge chunks of functionality present in the web version.
- The web app was not even a little bit responsive. While there were native mobile apps, they had vastly inferior feature sets.
- Less obvious and even less surprising for an app of its age, there was an endless variety of confusing interactions, wording, and UI elements peppered throughout the app.
- Team Connect wasn't much to look at and was long overdue for a visual refresh.
- Most glaringly, there were three different messaging hubs inside the app, and they all worked slightly differently.
Just Communication
My time working on Stack Team, although not consecutive, adds up to nearly two years. I don’t want to write a 300-page book about it, so I will be detailing the process of creating one core element: the communication feature(s).
The messaging functionality was one of the most evident signs that something wasn’t right with Team Connect. It was first brought to my attention by a developer on the project, JD Cochran. We spent the next couple of hours bemused, trying to decipher the intertwined methods of communication in the app.
What's wrong with the communication features?
There are two places inside the app where communication can be received, the Team Feed and within the Messages feature.
The Team Feed
The Team Feed is the homepage of each team and where users land after selecting one. It collects communication as well as miscellaneous updates, e.g., photo uploads.
Strengths
- Users can find team updates and certain kinds of messages in one place
- Teammates can leave comments on things in the Feed
Weaknesses
- You can't add things to the Feed from the Feed; you have to go to a separate screen
- It's difficult to predict what will and won't appear in the Feed
- Each team's Feed is independent, so it isn't a reliable way to send/receive important info
The Messages Feature
The messages feature self-contained and team independent. With this feature, people can send and receive messages to and from all of their teams at once.
Strengths
- It sends and receives private messages
- Capable of sending emails
- Users can receive and respond to announcements and comments
Weaknesses
- Choosing to send an email triggers two identical emails to the recipient unless they've turned off email notifications
- Replies and comments appear without context
- The feature is entirely absent from the mobile apps
Separation Anxiety
These features, independently, have serious but addressable issues. Put them together, and you get some record-level discord and an endless cacophony of alerts.
- When creating an "email/announcement," the resulting message will appear in three places: the recipient(s)'s email inbox, Messages inbox, and on the Team Feed.
- When viewing the message in the Team Feed, users can comment on the post. Where do notifications go? Everywhere. Comments show up as new messages, separate and without context from the original, and each time splintering off into more and more notifications and messages.
Thanks to the above, even a small amount of activity can get out of hand real fast. The animation illustrates the chaotic flow of the communication features and just how easy it is to lose the plot while using them.
Laying the foundation
At this early stage, the UX team was in constant discussions with stakeholders, developers, and anyone else who would talk to us. Though we started with a pre-defined list of must-have features (the core features of Team Connect), how exactly we would put them together was very much up for debate.
One of our most useful practices during this period was holding “design studios,” in which we would bring stakeholders, developers, and bystanders together to brainstorm solutions from many perspectives. These sessions were an enormous asset and ensured that all parties were on the same page while providing the design team with valuable insight and keeping proposals in scope.
Big questions & small answers
The leftmost is a flowchart of the original app flow. First, a user starts the app, then selects a team, and chooses an activity to perform, e.g., writing a post. The action is the end of the original flow, and if the user wishes to, e.g., write another post for another one of their teams, they must repeat the actions from the start.
The flow on the right, the new flow, again starts by starting the app but then gets straight to picking the activity. If they’re on more than one team, they will choose which team at this point. Either way, there’s potential to save a lot of repetitive tapping and clicking with this simple change.
Building the core
After answering some core questions about the app’s fundamental structures, it was time to decide what functionality would make it into the MVP.
Using extensive archives of user behavior, the product and UX teams determined that the Team Feed functionality was much more valuable to our users than its competitor, Messages. We decided to rename the Team Feed “Posts,” and improve it to be more streamlined and versatile, akin to modern social media apps. We didn’t completely remove Messages; instead, we would pare down some of its heft and transform it into a more straightforward notification hub.
Designing for all kinds of content
As mentioned previously, while the team feed’s main point was to read and share text, it also pulled other things into the feed, e.g., photo album and event updates. It was essential to keep these features, but we also wanted to kick them up a notch, making them more useful and usable.
Some of the scenarios explored below include standard and repeating events (and RSVP handling), posts with link previews, and then a lot of different strategies for different numbers and orientations of images.
Wrapping up
After the wireframes were approved, the high fidelity designs came together quickly. The team aimed for a relatively lean development process, utilizing React Native to simultaneously develop the app for iOS and Android devices. For that reason, we on the design team tried to shoot as straight down the middle as possible without favoring one platform’s UI elements too strongly. We used each platforms’ native UI where possible but did adopt some elements to use across both platforms, such as Material Design’s FABs (Floating Action Buttons) and the Segmented Controls from Apple’s Human Interface Guidelines.
Lessons Learned
This project was the first time I contributed to designing a (fairly large!) mobile app from scratch, so I learned a lot. Here are a few that stick out.
Working with developers is as tricky to get right as it is rewarding when you do get it right. One of my overarching personal goals during the project was to make the handoff documentation “bulletproof,” so developers wouldn’t need to ask any follow-up questions. An impossible task, maybe, but it pushed me to get better at predicting what questions developers would have and saved all involved a good chunk of time and effort.
Working with designers is somehow more challenging than with developers, which I blame primarily on the design tools at the time. The two most useful tools for our team were adopting an 8-point grid system to help keep our layouts consistent, and Abstract, to help us put our work together without accidentally overwriting each other’s work (too much). New tools and the maturity of design apps like Figma have fortunately made this aspect much more straightforward.
Lastly, and most tragically, but most importantly: the market rules all. Anything made for business is at the mercy of what makes the most sense for business. While working on this project, I learned that priorities might change quite quickly and without warning. These priorities massively shifted as we were very near to completion, significantly lessening the app’s importance. As a result, I can, unfortunately, share no data reflecting any effects of this project because there just plain isn’t any.
