Written by Process Design, UX Design

Catching Lightning in a Bottle

A story about the one project that ultimately convinced me to pursue User Experience (UX) Design as a career.

From Experience Map to Prototyping

My Adventures in Prototyping

I am enthusiastic about sports technology, which is another way of saying that I’ve tried a dozen or so different applications and products designed to automate sports management. When I was the cycling coach for George Mason University, I liked the concept of making a coach’s job easier with data. Data-Driven decisions are very useful in gauging improvements in athletes. Unfortunately, my enthusiasm only goes so far. The sad fact is that most of these software solutions suck Why? Because they try to solve problems coaches don’t have. They are bloated, field-heavy online forms designed for a profession that has managed just fine with paper and pencil for decades. In essence, they are applications trying to solve a problem coaches don’t have.

Unfortunately, this doesn’t seem to stop dozens of software companies from creating unusable “kitchen sink” sports management dashboards. These are the applications that promise to make a coach’s life easier so long as they buy the consulting that goes with it. I see these products are artifacts to an industry that thinks it’s a good idea to shove every Nice-to-Have feature into an application. The end result is a “feature-rich” interface that looks like something that came off the Roswell Crash.

What’s worse is these software products are usually marketed to a profession that hates — and I mean HATES — technology: coaches. Sure, many professional sports have begrudgingly adopted data collection as a means to an end. But if you go watch a movie like Moneyball you soon learn firsthand how hard it is to change an industry that resists technology.

A Problem Worth Solving

There are moments, however, when you get to see behind the curtain and experience a problem worth solving. I’ve known for a long time that sports management software needs some love. Mostly because, as a member of their target audience, I would often wonder WHO these applications were created for versus WHY they were created.

This curiosity was created during my first User Experience (UX) design project in 2004. Initially titled TeamToolKit (TTK), this project took all the divergent skills I had been collecting for the first 20-some years of my life and harnessed them into an edge. At the time I had been freelancing as an Information Architect and LAMP-stack (Linux, Apache, MySQL, PHP) website developer. Little did I know that when a marketing firm out of Portland, Oregon, hired me to join their team to help create TeamToolKit (TTK), that it would become start a life-long journey into UX design. 

Early Observations

The first hurdle with this project was in shaping the problem. It just so happens that TeamToolKit started off as one of these sports management dashboards aimed at intramural coaches. In particular, the intramural coaches that run organizations that use terms like “little league” and “pee-wee” in their titles. 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. Sound familiar? But this was 2004 — back before Facebook was big, email notifications were the norm, and every productivity tool needed to be online. 

To validate this problem — a problem the marketing firm’s paying client had first-hand — we needed to go into the field and observe intramural coaches in their natural habitats. It is during these site visit observations that the pain could be experienced. It turned out that team management was not the emergent problem. Coaches appeared to be very skilled at organizing and managing kids. It was the parents, on the other hand, that were having the major difficulties!

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 prototypes 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 all the marketing firm 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.

If you remember my earlier rant about sports management software then you might recall that I am no fan of “kitchen sink” sports management dashboards. Unfortunately, this is what the company spawned from TTK has morphed into. I am sure a decade of customer feedback, pivots, and competition has played a role in this application’s UX lifespan. While it does still maintain many of the features I build into the original prototype, they’ve bolted on a dozen more to account for all aspects of team management.

Kitchen meets sink. <sigh>.

The runway the TTK concept provided this company cannot be ignored and I still cannot begrudge the success it has had over the past 16 years. Watching something I helped bring into the world become a multi-million dollar success IS a great feeling, although bittersweet. At the time, TTK felt like an amazing concept but nobody thought it would grow into something that big.

Meanwhile, the TTK experience changed me.

I have been addicted to riding the UX design dragon ever since. The enjoyment that comes from being in the trenches of a good UX design process is an experience all to itself. Especially when you’re allowed to collaborate with other intelligent and enthusiastic creatives. Every time I get a chance to do even the most rudimentary user experience work —  using everything from sticky notes and sheets of butcher paper to action figures and sock puppets — I feel like it’s more play than work.

As for the bane that is sports management software? I still strongly advocate the “less software means fewer features, less code, less waste” philosophy that Jason Fried laid out in his book Rework. I like to think of myself as a champion of user-driven design — or as IDEO puts it, human-driven design — because it affords me the evidence to push back against the tide of feature-creep that eventually impacts every product.

Was TTK lighting in a bottle? For the co-owners of that marketing firm it was. It also did pretty well for the company that it helped create too. As for me, I found my calling in UX design with that project. And that lets me catch lightning in a bottle every Tuesday and twice on Fridays!

#ux #prototype #prototyping

Photo by Jo Szczepanska on Unsplash