TeamToolKit Prototype v3.0 clickable demo used in the next iteration of client and usability testing (2006).

TeamToolKit final prototype (2006).

Intermural Team Management

TeamToolKit (TTK) is a sports management dashboard aimed at intramural coaches. In particular, the intramural coaches that run organizations that use terms like “little league” and “pee-wee” in their titles. I was hired by a marketing firm located in Portland, Oregon, to help the team validate TTK’s core problem and develop a clickable prototype.

The idea was to give these coaches a tool to manage their teams and leagues without having to depend on paper and pencil documentation or schedules. But this was 2004 — back before Facebook was big, email notifications were the norm, and every productivity tool needed to be online.

Validation of the problem was not difficult. We made several observations during separate site visits that recorded the pain  — the pain that the marketing firm’s paying client was experiencing firsthand — in all its glory. What we discovered was that the team management issues were not the client’s immediate problem. All the coaches observed appeared to be very skilled at organizing and managing kids. However, we learned that the parents were the ones having major difficulties with understanding the management of the team.

Mapping and Persona Creation

You can just see the personas forming in real-time when you read the problems out loud:

“Who was supposed to bring the refreshments? Not me! I thought it was Ann?”
“Why can’t Billy get to practice on time, Jill?”
“I didn’t get the schedule in my email again. This is the third time!”
“What do you mean dues are being collected today. Nobody told me!”
“Which Johnny is starting on Saturday? Johnny A. or Johnny B.?
“Sorry. I thought he needed his Away jersey today. Why didn’t you call me?”
“Did you know the practice was canceled? Because I didn’t!”

The coaching dilemma within intramural sports management is a delicate balancing act between on-field youth performance and entitled parental diplomacy. Coaches enjoy the on-field part of the job, hence, a reluctance in wanting to replace their clipboard with an online dashboard. That’s the part they can control. Managing parents, however, is the part of the job they have problems control. It is not only unpleasant but at times redundant. Each parent asks the same questions and usually when the coach is actually trying to do the coaching part of the job.

Yet, coaches understand that without parents, the kids don’t make it to practice or games. Next to athletic ability, parent management is essential to intramural success. It’s as simple as no parents, no kids.

This was a huge observation made while crafting an experience map of the problems encountered. Yes, coaches did need some help with basic sports management pain: a central place to keep and share all of the team’s player and contact information. But what they really needed was a central place to keep their team parents organized. This included everything from updated schedules and availability to refreshment rotations (i.e. team refreshments being a particular sensitive pain point where parents either did not bring refreshments when asked or brought refreshments on the “No-No List” due to Little Billy’s nut allergy).

Coaches needed a place to point the parents so that they would do the one thing every coach wishes his team parents would do: stop asking questions every 5-minutes!

And there is was — the top goal for addressing the top pain point of the coach persona! It had simple metrics too:

“The correct Refreshments show up to each game.”
“All players show up on time for each practice.”
“All players show up on time for each game.”
“All players show up to team events in the correct team uniform.”
“Coach receives 50-percent fewer information calls from parents per week.”

This manifested into five (5) key personas for the project:

Coach Bob — He just wants to teach kids who want to have fun playing a game.
Parent Ann — She needs to know the schedule because her day is crazy busy.
Parent Jill — She doesn’t do anything unless Coach Bob asks her to do it.
Parent Matt — He doesn’t remember what he ate yesterday and forgets everything.
Little Billy — He wants to play but always tells his Mom information that changed.

What started as a sports team management problem focusing on concepts for coaches, quickly pivoted into a parent-friendly communication tool. Repeated observations of team parents interfering with the coach’s work changed the team’s initial assumptions and allowed for the creation of personas that put more weight on the comments from the team parents than from the coach or players. Although coaching-specific features (e.g. Game Statistics) did make it into the final storyboards, the majority of the requirements centered around a common theme:

How to give the parent personas enough information to make the coach’s persona happy while also giving the coach persona the right amount of resources to be useful to their overall goal: managing an intramural sports team without friction.

This resulted in the creation of scenarios that explored seven (7) key features: Games, Practices, Rosters, Availability, Payments, Statistics, and Photos. Each of these features provided the groundwork for a Parent-Based Dashboard that communicated all of the essential team activities.

Paper Prototyping

What I loved about participating in the TeamToolKit creation process was gaining a clear understanding of why we were building this application, who it was for, and what needed to be included in the design. Unlike many of the other projects that I had been a part of before TTK, the WHY and WHO had never been shared. I had been living only in the WHAT part of the process (in the days of Water-SCRUM-fall and before Agile or DevOps). The advantage of being a part of the HOW behind the WHY and WHO parts were in how it made the creation of the WHAT almost second nature.

TeamToolKit Homepage Placeholder

TeamToolKit Homepage Placeholder (2004)

The first paper prototypes were variations on what a parent would need to see that a coach could provide with minimal effort. We sliced many of the paper prototype features down into three categories: Essential, Maybe, and Nice-to-Have. Many of the features that didn’t make it into the minimal viable prototype were connected to coaching tools. Things that the parent personas didn’t need or would not find value in knowing. What did remain were the scenarios that resonated most with what information parents wanted from their coaches:

Games — When is the next game?
Practices — When is the next practice?
Rosters — Who’s playing what position on the team?
Availability — Who can play when and who needs to sub for who?
Payments — How can I pay you without using cash or bringing a check to practice?
Statistics — How is the team (or my kid) doing?
Photos — Where can I share photos of the kids playing?

Next, I took what we had created in our Experience Mapping and Scenario sessions and organized all the outputs from the consolidated Story Map:

Early TeamToolKit Story Map (2004).

The TeamToolKit Story Map took all the best ideas from the scenarios and applied them to each of the seven (7) features. The map also identified core functionality that was explored in earlier concepts but not included in the feature list. This included the typical application patterns such as Accounts, Authentication, Setup, and Help/Contact. These were all consolidated under one global feature called Manager.

Manager — How do I control all this chaos within the app?

The final consensus for TTK’s feature list included almost a UX design that had 80-percent of the UI features targeted towards parents while roughly 20-percent (with some overlap) useful to coaches. On the other hand, the information provided to parents gave coaches a 2-for-1 benefit in ending all of the annoying calls, repeated questions, and overall improvement to team communications.

Prototype Iteration #1

Version 2.0 of TTK was where I would have normally come into the process. It was surprising to learn how much work had taken place before this point. Only now I was able to understand (and appreciate) the UX background work behind the problem we were solving.

It was now time for me to pick up the ball and utilize my web development skills (mainly PHP and MySQL) to start rapid prototyping a clickable prototype based on the paper version. However, this was the first project that I didn’t need to ask questions about the purpose of this feature or that button. I already knew WHY it was there, WHAT it was for, and WHO would be using it. I already had buy-in via participation in the process. This made the medium-fidelity part of the prototype design easy to conceptualize and build.

A designer from the marketing firm created the UI elements (buttons, icons, tabs) and I built a web demo with a semi-usable interface. The result was TeamToolKit Prototype 2.0:

TeamToolKit Prototype v2.0 (2005)

TeamToolKit Prototype v2.0 (2005)

As I established more and more of the functionality, TTK came to life. Process flows and bottlenecks were corrected, UI elements were tweaked to account for worst-case interface scenarios, and security was applied to allow the marketing firm a chance to demo it via their development server. As we started to understand the relationships between features, the complexity of the new prototype also required me to rethink the database schema:

TeamToolKit Database Schema (2005)

TeamToolKit Database Schema (2005)

The final clickable prototype was demoed to the client in 2005 and received excellent feedback. Seeing the application go from an idea to a paper concept, then to an almost usable website, was exactly what the client needed to see. It also set the stage for usability and acceptance testing. Volunteers that were very close to the personas that were crafted earlier in the process provided invaluable feedback to TTK. They pointed out what worked well, showed us where they became confused, and where we needed to improve.

All of the UX design work, early prototyping work, and usability testing showed us that TeamToolKit was unlike other sports management applications. We had done our homework and understood the problem that TTK was meant to solve.

Prototype Iteration #2

All of this rich client and user feedback from the TTK prototype v2.0 was taken back to the team and synthesized into the current prototype. The initial UI that featured only tabs added a homepage with big buttons and clear descriptions. Additionally, an “at-a-glance” status area was added to the application’s homepage so that parents didn’t need to go searching for answers. Everything they needed for the coming week was right there.

The next iteration of the clickable prototype was cleaner, easier to use, and removed much of the friction experienced in early prototype designs.

TeamToolKit Prototype v3.0 UI mockup incorporating client and usability feedback (2006)

TeamToolKit Prototype v3.0 UI mockup incorporating client and usability feedback (2006)

I applied these same lessons in the overall application, CRUD process screens, and overall usability. Unfortunately, version 3.0 of TTK came with a new challenge: feature creep. Once the new UI mockup was released it started a new conversation in button hierarchy (which button should go where and why), payment API gateways, and messaging.

TeamToolKit Clickable UI Demo shown during the usability tests (2006)

TeamToolKit Clickable UI Demo shown during the usability tests (2006)

While Payments was identified as a core feature during the UX design process, how it would be implemented became an issue. Would it be a way of collecting dues or would it be more robust and allow teams to collect money for all sorts of needs (e.g. uniforms, greens fees, refreshments, end-of-year parties)? The solution was to release only one way to pay now (collecting team dues) via a PayPal API gateway and let the team manager and/or coach decide what it was for. But we all acknowledged that it would require more research and testing before this feature was complete.

The Messaging feature was a new addition to the interface. It had come and gone multiple times during the prototyping process. First, we wanted it, then we didn’t. Now, it was back to stay. Remember that in 2006, texting and SMS messaging not as widely used as it is today. The TTK Messaging feature was supposed to act as a message board. Coaches and/or parents would post questions, comments, or concerns on the board and allow other users to comment back. Since the global idea was parent communications, this seemed like a must-have feature.

Finally, the UI button hierarchy discussion was very contentious. Should the Games be at the top or should Roster? Turns out that Messages and Payments were the winners of the button lottery. Since they were the places that the client felt parents needed to go the most, it stood to reason that they would be at the top. Unfortunately, client input also impacted the placement of the remaining buttons as well. While the UX design team had strong opinions about button placement, ultimately everyone resigned to let usability testing and user feedback make the decision.

The final version of the TTK Prototype v3.0 included Messages and Payments at the top with the remaining UI buttons grouped next to similar categories (e.g. Games and Practices, Roster and Availability, Statistics and Photos):

TeamToolKit Prototype v3.0 clickable demo used in the next iteration of client and usability testing (2006).

TeamToolKit Prototype v3.0 clickable demo used in the next iteration of client and usability testing (2006)

Prototype Delivery and Reflection

The final prototype was delivered to the marketing agency with high praise from the client. As I off-boarded from this project, I had a good feeling that the UX design and prototyping iterations delivered most of the value needed to validate a minimal viable product.

Which is exactly what happened.

After leaving the project on good terms I discovered that the co-owners of the marketing firm had rebranded the application and spun it off into its own company. I also learned that they took the existing prototype and rebuilt it in 2007 using Ruby on Rails (Rails). I imagine with all the new capabilities that Ruby on Rails had at the time (and the popularity of 37Signals’ Basecamp application).

I strongly believe that if your work is good enough to spawn a small business then it is an excellent indicator that your efforts were successful.

However, the story didn’t end there. What I didn’t know (but would later find out) is the business created by the TTK prototype would explode into a big company. The co-founders sold the company in 2009 to a third-party investor and by 2012, the company (now under new ownership) transformed a prototype sports management application into the US$45-million Software-as-a-Service company supporting over 24-million customers year.

I check into the company from time to time to see how the current version of the application stands up to the original concept we created back in 2004. All the core features are still there proving how vital they were to solving the original problem. Although the company mission and vision have slightly changed to take on a more holistic approach to team management software (coaches, administrators, players, and parents), I still see that parent communications are at the heart of what is still being used today.

Role and Acknowledgements

  • The “Marketing Firm” presented the original problem to solve, designed all the high-fidelity UI mockups, and create the initial UI interface.
  • I participated as part of the design team in the creation of the user experience map, personas, and scenarios.
  • I handled finalizing the UX scenarios, handled all the gnarly UI design problems, developed the clickable demo prototype application (Using PHP, SMARTY, and PEAR), built the MySQL database, and worked through all the CRUD interactions that the paper prototypes always seem to leave out.

Related Links:

#ux #prototype #prototyping #project #teamtoolkit

Last modified: July 15, 2021

Comments are closed.