ROLE: UX Designer, Co-founder
CHALLENGE: Collaboratively discover and implement a sustainable business model and product-market fit
RESULT: Successful launch, operation, and continuous improvement of consumer-facing web application
RecBob was a team management application centered on the experience of recreational sports team captains, players, and subs.
While finishing my Art degree at the University of Iowa, I signed up for a Startup Weekend event to scratch an entrepreneurial itch that had been developing for some time. On Friday evening, six people came together to form hypotheses, test those hypotheses, create a business model around the results, and demo a functioning prototype that Sunday. We did customer research and created a functional prototype, forward-looking designs, and branding in those 54 hours. Ten weeks later, five of those 6 firestarters official founded RecBob.
Baptism of Fire
While in the pit with the developers, I became intimately familiar with a Software as a Service (SaaS) company’s technology stack, as well as team production processes and needs, from Agile to version control. We also needed to know what to make and to understand the possible impact of each roadmap decision. The business model, technology stack, and user needs all had to align. Prior to RecBob, I had not even heard the term “UX”. It was in this startup environment that I came to understand the importance of UX research and design.
There was often overlap, but each of the founders had a primary area of responsibility. There was business, marketing, engineering, research, and design. My wheelhouse was design, frequently dipping into the research side, with the occasional foray into front-end programming. Reliable and open communication between the team members was key, as was trust in the process and each other. And we needed the flexibility to respond appropriately when new information surfaced. We were Agile, Lean, and Hungry.
Walking in the Users’ Shoes
Everyone participated in user research to some degree. At a minimum, each founder participated in rec sports leagues, paying close attention to pain points and asking questions of our teammates and opponents alike. Once we had a product, we ate our own dog food, too, using RecBob for our teams. We felt the pain when we got the experience wrong, and we felt the joy of a simpler way to manage fun when we got the experience right.
Over time, I expanded my personal research toolkit from in-person customer interviews and surveys to more novel and sophisticated methodologies. From the immersive (ethnographic research), to the participatory (co-design sessions), to the distant (remote user testing), I cultivated a sense for what methods to apply toward a given information need. Once we had a product launched, we were also able to utilize more technical and quantitative methods, such as A/B testing and tracking user metrics and indicators.
As our product’s complexity grew, the last thing we wanted was to be forced to opt for sub-par design choices or feature sets in order to avoid re-doing the plumbing, or to end up creating a negative experience for the user by shoe-horning new development into an inferior architecture. In order to avoid such scenarios, it was of paramount importance that we understand and communicate the structure of both present and foreseeable future aspects of the software.
Toward this end, I mapped the possible, tracked the feasible, established development landmarks, and provided detailed information on the relationships and attributes of features, elements, and interactions.
Massively Iterative Design
One great thing about our office was how we had covered the walls with markerboards. I utilized these to full effect, plastering sketches and wireframes around the office, quickly getting feedback from my teammates on technical constraints, notes on use cases I had overlooked, and any other valuable input they could think of (and they thought of a lot!).
I then iterated based on the new information–following up with research where needed–and continued to create and challenge my ideas with the team. Each iteration came with new probing questions. As changes began to minimize, I would switch to higher fidelity mockups, prototypes, and annotated designs.
It’s amazing how quickly a fairly simple idea (team management) can balloon into a complex project. Our list of considerations grew quickly to include multiple personas (captains, players, subs…), barriers to entry (technological, temporal, informational…), diverse device usage (desktop, mobile…), changing contexts (at home, in the field…), and more.
We strove to meet the users where there were at, in every sense of the word. Some users needed to access our software’s capabilities on the go, so our site was responsive. Some didn’t want one more app to contend with, so we designed an experience that never required them to open or interact with the app (we called it “redshirting” users). Some needed to control the experience (captains), while others were just along for the ride (players). Some had already established teams, while others were looking to find one. Anyone who has worked on a consumer-facing application has likely wrestled with most of these issues.
We went from internal demo to public product in 10 months. We established a respected brand, attracted outside investment into an Iowa company before it was cool (Is it cool yet?), and were accepted into the prestigious TechStars network (you can find me at FounderCon in Berlin this June). As mentioned above, RecBob was a baptism of fire for me in many respects. I’m probably leaving a few things out, but below are all of the fiery baptisms I can recall off-hand:
- Lean startup life
- User experience research and design
- Agile methodology
- Full technology stack
- Business model discovery and pivoting
- Angel investors and venture capital
- Corporate partnerships
Once you live life moving a mile a minute, it can be hard to change gears. The culture of self-reliance, productivity, and engaging activity is difficult to replicate in a non-startup environment. The camaraderie is difficult to replicate as a freelancer or contractor. There is something special about startup life, but it’s also meant to be ephemeral. Either you fail, and you go back to another life (or start another company), or you succeed, and you transition to a different kind of company. I admire those companies that have made the transition while largely retaining the culture that brought them success to begin with.