A year and a half ago, I sat on the floor of our office with our co-founder, Vivek, surrounded by sticky notes and diagrams. We knew HackerRank would be a great service, but we were not entirely sure what it should look like, or how it should function. We work within an agile process, though, so we moved quickly to push something live.
We identified a triad of functions that HackerRank should embody: a place where people could learn new techniques, share their skills with others, and compete for prizes. “Learn, Share, and Compete” – leading to an overall fun experience.
In the months that followed, we have honed our focus, made mistakes, learned from those mistakes, gained an incredible (and growing!) core of active users, expanded our scope, and experimented with myriad features, most of which are active on the site today. Most of the assumptions that surfaced from that initial brainstorming session proved accurate, although they did not all manifest the way we thought they would.
As a product designer, this process has been thrilling. There have been situations where agile development has worked seamlessly, and times when agile was not the best solution. Overall, there are a few lessons that really stick out.
Act on instincts, question impulses
Agile design involves pushing a Minimum Viable Product as quickly as possible, but it’s easy to get caught up in the process. The art of agile, I’ve found, is having a solid roadmap and coherent understanding of your product so that you can confidently and quickly make product decisions based on your instincts; the goal is to let these instincts validate your impulses and not the other way around.
Instincts are the natural, intuitive thoughts that come from knowing your product and its users. Sometimes they manifest as sudden epiphanies, sometimes they evolve over time.
Impulses are the result of snap judgements or reactions. For example, someone says, “your product sucks,” so you quickly react to address that individual’s criticisms.
Whether its a sudden great idea, a suggestion from an active user, or something you saw work somewhere else, impulses can be positive forces. It’s important, though, to take the time to step back and see whether the idea fits in the larger picture. Agile workflows depend on flexible products, but a big-picture scope is still necessary to keep short-term goals on track and to minimize distractions.
Sometimes, slower is faster
There’s a delicate balance between forward momentum and stalled progress in an iterative environment. It’s very easy to find yourself chasing your tail as you push change after change without any measurable results. Like all good things, agile design is a means to an end. You should never move quicker than your team is reasonably able just for the sake of moving fast.
A great mantra I’ve heard carpenters tote time and again is perfectly suited for agile development: Measure twice, cut once.
If you take the time to do something right the first time, you’ll eventually save yourself time (and a lot of pain and effort) down the road. Being agile is a mindset, an exercise in obtaining the maximum product value for the least procedural cost. It should not be viewed as a fixed set of rules.
Maintaining fixed deadlines is the principle of agile development that I have struggled with the most. Sometimes the “right idea” comes the day before the deadline is up, or unexpected issues arise. The idea behind this practice is sound, but every rule has an exception. A List Apart articulates this well:
“‘Best practice’ suggests that designers should research iteration n+2, design iteration n+1, support iteration n and review iteration n-1. This is sound advice but should not be taken too literally: some stories will take longer to design than these arbitrary timeboxes. Designers should use their intuition and experience to flag up potentially complex stories in advance, giving themselves increased lead time. It’s bending the Agile rules, but should be encouraged if the product benefits.”
Getting Real About Agile Design, A List Apart (emphasis mine)
As the industry and users adjust to value good design, the agile workflow will need to become to flexible to consider the differences in workflow between designers and developers. At HackerRank, our teams work closely together throughout the process, and design has been prioritized since the beginning. The core point is perfectly expressed in the quote above: the rules, and their exceptions, should always be weighed by the value they bring to the product.
Embrace change
From a design perspective, an agile workflow is a world apart from what I have been used to. On past projects, I would take considerable time planning, prototyping, and adjusting a design before it ever went live. At HackerRank I have almost exclusively switched to designing in the browser. This has ended up making me more productive, and is surprisingly liberating.
Once I have my design templated, it is quickly picked up to be integrated and shipped. This has the very cool byproduct of increasing trust across teams.
Since we’re not spending weeks hashing over wireframes and pixel-perfect Photoshop mockups, the strategic team places a lot of trust in me, as the designer, to represent the product goals through a beautiful visual design. I trust my development team to take my design and implement it as I envisioned. This causes us to work closer and have a better understanding of what each team is working on.
A downside to this fast-paced environment, however, is that often ideas must be cut back or even dropped in order to keep the product moving forward. Furthermore, it is far too easy to react to feedback with short-term solutions that have not been fully vetted.
When we first launched, I was acutely aware of the daily and weekly fluctuations of our user base. After finding myself investing too much energy into user requests that did not fit well without our larger vision, I realized that iteration should be used to fix issues and improve the product, not simply to shuffle change around. All good things take time to grow.
I keep a bucket list handy, now, so that I can record good ideas as they come and file them away for later. Sometimes these ideas fit well into a product push, others are on standby – cool features that we will be pushing in the near future. Many will never be made live.
I think that’s my favorite part of the agile workflow: it really is product-centric. Since pushes need to be made quickly, we have to point our focus to the attributes that bring the most value to the product. Ego and personal taste are pushed aside.
It’s not surprising that the movement to embrace content-driven design is occurring in parallel with the advent of agile development. Both represent the prioritization of content over clutter; of product over process.
It’s definitely an adjustment, and something that is not perfect for every team or project. However, after experiencing the rewards that we have reaped from this workflow, in the project as well as internally as a company, I absolutely welcome the change. Ultimately, the greatest benefits fall to our users, which is really the best result we can ask for.
