IHeartRadio held their annual hack week last week. It was an incredible experience with tons of interesting ideas. For me, as someone who is passionate about process, I decided I wanted to jump on to a team that would be willing to demo a process rather than a feature. So, while every other team’s efforts could be seen in the product they created at the end of the week, our product was actually a byproduct of our efforts which were in invested in the process.
Why Process Matters
Let’s take a look at an example:
User interfaces and user experience. Think about how your team creates and iterates on its user interface. It’s quite literally the most important feature you have. You can have an amazing database of life changing information or an incredible algorithm that will change the world, but if users don’t know how to access it, you’re not going to go anywhere.
So back to UI/UX. Does this sound familiar?
“Well, we’ll just get design to mock some things out and well throw them in the backlog then work on them next quarter”
Fantastic. That sounds “agile” right? Design’ll throw something cool together and we’ll just use that. We trust them. After all, their designs always look cool!
It sounds like the right track. But is it? If you’re like us, you live, eat, and breath analytics. You have metrics to track the most minute interactions with your application. That’s why doing something like this, a non iterative dump of UI changes is, exactly the kind of thing you want and need to avoid.
Why Process Matters: Our Hack Week Project
An application’s user experience should revolve around its namesake. That is, the user. Our hack week project was to use a user-driven process to increase user-engagement metrics. How does one go about using a “user-driven process”? Well, I’m glad you asked…
1. Start with a business goal
In our case the business goal was very clear. We need to increase cume or overall user engagement. We want users to spend more time in our app. Because this was such a big goal, we decided to concentrate on a particular subset of users; specifically, users who bounce from the application homepage.
2. Come up with a hypothesis
We needed a hypothesis that was easily measured and well-understood so we started discussing different pain point of our application. Eventually our conversation turned to our real life experiences:
Ever start fiddling with the radio in a car? Regardless of what the song playing is, you’ll spend a few seconds listening to each station before moving through to the next one (even if it’s in an unfamiliar language).
So we decided that metaphor could be applied to our app. If we could get the player (and audio content) to the user faster there’d be a good chance that users would spend more time in our app and thus increase engagement.
3. Card Sort, 6-Ups, Paper prototyping, prototyping
Time to get the team’s ideas on paper. We all had different ideas of how to bring the player further up in the user experience but now we had to come up with a few examples to build paper prototypes. That’s where these UX exercises came in super handy.
Card Sort: a game that put all of our features, sections, and titles on to notecards so that we could see how our users grouped (or didn’t group) them.
6-Ups: a freestyle design exercise that forced everyone on the team to come up with 6 designs (no matter how bad). The goal of this game is to come up with a new design, however, the idea of the game is to inspire each other to come up with a better overall design
Paper Prototyping: how we pulled the results of these two exercises into a paper model; something we could actually use for user testing
By the end of this step we had a working paper prototype with a few variations to test our uncertainties about specific aspects of the design.
4. User testing with paper prototypes
Now it was time to throwout our biases and concentrate on the data.
We dedicated a handful of users with differing experiences with the application to act as our test group and then we had them run through our paper prototype. We recorded their feedback (notes, video, pictures). Here, we started to notice that the smallest details mattered. Lots of the best data to come out of these sessions came from off-the-cuff, unintentionally, thinking-out-loud comments. We jumped on it and iterated quickly.
5. Hybrid prototyping
It was time for us to start prototyping the clear winners from testing. Here, user testing continued in parallel to development. We concentrated on building an incremental prototype. This process ensured a smooth transition from paper to hybrid-prototype (to support paralleled user testing), as well as prototype to production.
6. Beta User Group and A/B Testing Release
Once the core functionality of our new feature moved from paper to prototype we started making preparations to get it to our “beta user group”. This way we could start to see how it performed against a larger group of users. Based on these number we might pivot on particular pieces of the design before dropping it into an A/B test in production.
Key Things to Remember:
Test early, test often
As fast as you come up with ideas, test them. Get them in front of users. Find what you can throw away immediately and start letting users guide your progress. This means testing at every step.
Use data to drive your decision making
Your changes must be measurable so before deciding to change a feature or component, have data to validate its change. This is of paramount importance in being able to gauge the results of your user testing.
Justify every change to the component/feature with a piece of user data
When you make a change or decide to place a component in a particular location, justify it with user data to the team. Say, “User 1 said it was too difficult to find this feature, we should place it here” or “we know that users only have 1 to 3 of these, it should look like this”. This helps keep the team sane as you iterate through different designs.
Limit scope
The minute you get started is the minute you’ll realize that you want to change everything. Target on one aspect of the design or feature. Iterate on that. The added focus will allow you to explore new and different options.
Test just one thing at a time
Limit your variables. Know your unknows. Ensure that what you’re changing is measurable. And know how, where, and when to call a success or failure.
Don’t be afraid to be different
Think outside of what you’ve seen and used. Try not to justify all your design changes by their use by other applications. What applies to other apps may not work with your app and vice versa. Think differently and it may lead you to a new, undiscovered pattern.
Final Thoughts on Hack Week
The fun (or terrifying) part of Hack Week was that it forced us to go from idea to production in 5 days. It was an awesome experience and it taught me a lot about keeping feedback loops short and being deliberate in every part of the process—even as someone who has had experience with cross-functional teams and rapid prototyping, it was a breath of fresh air to challenge myself to fit an entire iteration (spinning up a team, user testing, prototyping, and release) into such a short time period.