In late 2015, myself and 2 partners co-founded CodeFights, an educational game for engineers. As the head of product and UX, I designed and oversaw all aspects of the product's development, from game modes and a badging system, to an admin-only tool suite and customer-facing dashboards. It was a wild ride - here's a look at some of the projects we tackled and my UX process throughout.

CF statsCF stats

AGILE EXPERIMENTATION

Building a sticky game takes exploration, and we constantly experimented to find out which game modes would increased user retention. If they stuck, and received positive user feedback (driving week-over-week engagement), we kept them around.

If we received negative user feedback  (either through usability studies, direct communication or a very active Forum) and observed lower retention numbers, the modes were slowly phased out.

INCREMENTAL DESIGN

Engineers are a picky lot, and never more so than when choosing their programming tools. Rather than start with a complex toolkit that was bound to disappoint many (and be riddled with bugs), we started simple. Then, as we gathered feedback, we built out our IDE (development environment) to support 16 languages, multiple color and formatting options, and Emacs and VIM key binding - all in a responsive package.

CF screenshots 2CF screenshots 2

UX SPRINTS

From the get-go we adhered to weekly design and development sprints, giving new meaning to the term "MVP" (i.e. what can be built in a week). The fast pace required tight coordination between UX and engineering to make sure we didn't fall behind, and a keen eye for design solutions that represented a happy medium between ideal-user-experience and it-won't-take-2-months-to-build.

Projects of a certain size relied on a PRD (Product Requirement Document) as a single source of truth so everyone would be on the same page. A given feature would then proceed through ideation, scoping, design and finally engineering, with approvers providing feedback along the way directly inside the PRD. Designs would be included either inside the document, or an external team Invision project. 

CF UX processCF UX process

DEEP DIVE - ARCADE MODE 

In the early days of CodeFights there were 3 main modes: a "Solo" mode where the player raced against the clock, a "Head to Head" mode where 2 programmers could duke it out against one another live, and a "Challenges" area where users could solve long form problems submitted by the community.

Over time, our Mixpanel analytics made it clear that Challenges was by far the most engaging mode - users spent more time, ran more code, and interacted with other users almost 10x more than with the other parts of the site. We decided to see if we could create a similar mode to Challenges that was more "gamified" and even stickier - enter "Code Arcade". 

 

Arcade image 2Arcade image 2

We took user feedback about what was missing from the Challenges mode - no sense of progression, no "fun", and not enough social competition with friends - and adapted it to the Arcade. In the new mode, users were presented with a pathlike "tree" similar to Angry Birds, where they can clearly see how much progress they've made, and how well they've performed overall. Any friends who've already tackled the Arcade are shown next to each card, so users are prodded into feeling competitive.

MATERIAL(ISH)

Back in 2015, Material Design was all the rage and we thought we'd give it a shot. Our old UI was based on bootstrap (below left), had no real color palette, and was starting to show wear as our product got more complex. I'd had experience working with the design system in its early days at Google, and found it to be a comprehensive, foundational UI system that our engineering team could quickly grok. 

Before long, however, we ran into the limits of Material: namely, a tendency for our designs to look very much like every other Material-designed product out there (cards, cards, cards!), and some major discoverability issues with the FAB button (floating action button). We naively assumed that the FAB (below right) would provide a clear affordance for our primary actions, but a subsequent rise in user tickets, a reduction in those very primary behaviors, and some feedback following a quick round of user research, revealed that the majority of users weren't finding the FAB at all! Turns out that the FAB is optimized for mobile-first applications, and our relatively complicated webapp made the FAB effectively disappear. All in all, a lesson to check my assumptions at the door.

CF old and FABCF old and FAB

DEEP DIVE - MESSAGING & TEAM COLLABORATION

In the early days of our client dashboard, where clients could review and communicate with the engineering candidates on CodeFights, we kept things pretty simple from a messaging standpoint. Users could send and receive simple text messages, but that was it. Through regular communication with our customers, we pretty quickly discovered that recruiters often send the same introductory message to candidates. Our simple text editor was fine, but users were forced to retype the same message every time or copy and paste from an external application - pretty frustrating! And since frustration = friction, we needed a fix quick!

Our initial solution was to remove the friction around messaging by building a simple templating feature. Some quick user research uncovered a range of existing templating tools that we could take inspiration from, and would be easily understood by our clients. 

Initial mockups focused on the ideal workflow to let users create, manage and share message templates. This served as a useful discussion point with engineering to make sure we weren't building something that would break (especially around the commonly shared templates): 

Message template flowMessage template flow

The end result was more polished, handled shared templates, and had an empty state with explanations and default templates to help people get started:

View templateView template