How FreshBooks

Got Its (Design)

Mojo Back

This is the second post from FreshBooks’ Product Development team. Our goal is to share what we’re learning, in the hopes of giving back to the broader community of companies building software products and services.

This is the story about how FreshBooks lost its Design mojo, and how we used Lean UX to get it back.

Since the very beginning, design has been an important part of FreshBooks. We care about design because we care about our customers — small business owners. A great user experience means they can spend less time learning how to use our software, and more time growing their business and livin’ life.

Our focus on design and user experience has paid off: we’ve won design awards, our customers love us — heck, Forbes even called us “incredibly user friendly.”

Sounds pretty great, right? We thought so too. Until it wasn’t.

The Dark Time

In July of 2013, design at FreshBooks entered a dark time. All of a sudden, design wasn’t just hard — it was painful.

Every project went through a seemingly endless series of design reviews, each more disheartening than the last. Nothing we ever presented was “good enough” (let alone great), but we couldn’t figure out why. We started to lose confidence and doubt ourselves, which only made things worse.

After weeks or even months of agonizing reviews, when we finally produced a design that we felt was worth building, it instantly became precious, and we became defensive. A Developer has some feedback on the design? Too late, the design’s final. Beta-tester’s confused by the UX? Doesn’t matter, the design’s already approved. Since it was so painful getting to this point, why on earth would we willingly subject ourselves to that pain again? Better to keep the design ‘hermetically sealed’ and therefore above reproach.

Designers and Product Managers felt stifled and started to disengage. Developers felt like little more than order-takers, having precious designs handed to them and being told to “go build them”. Worst of all, our customers, the people we care most about, were ultimately paying the price for our broken design process.

FreshBooks had lost its design mojo. What happened?

A New Way of Working

Just before the dark times, the Product Development Organization at FreshBooks began a transformation from Waterfall to Agile Scrum. Up until then, we had been treating software development like it was some kind of assembly line; needless to say, it wasn’t working, and we needed to try something else.

The transformation to Scrum was scary, messy, confusing — even emotional. We had to forget what we knew about building software and take a leap of faith. Truthfully, there were times we weren’t sure we’d come out the other side. But like when Andy Dufresne crawled out of the pipe at the end of Shawshank Redemption, our perseverance paid off.

Software development became collaborative; Product Managers and Developers began working together — no more silos. Software development became iterative; we shipped customer value every single week — no more monolithic projects.

….but what about design? Where did design fit in all this…?

We forgot about design.

We were so focused on figuring out how Agile Scrum could improve the way we build software that we didn’t consider how design fits into this new way of working. Design got left behind.

We didn’t enter the dark times because we suddenly got worse at designing user experiences, but paradoxically, because we got better at everything else. Our design process was a relic of the assembly line, and it was fundamentally incompatible with Agile Scrum. This is why it felt so painful.

Darkest Before the Dawn

Once we realized what had happened, we set about fixing it. We promptly failed, failed again, and then failed some more. Here’s how we screwed up:

1. We tried to solve design in isolation. One of the lessons we learned when we moved to Agile Scrum was that there’s no such thing as a purely technical problem, just as there’s no such thing as a purely business problem. Each problem in software development is a bit of both, and solving it therefore demands collaboration and teamwork across disciplines. We completely overlooked this important lesson when we tried to solve our problems with design. This all but guaranteed our inevitable failure.
2. We added more artifacts, more process, and more ceremony. The Agile Software Manifesto we had come to embrace specifically values “individuals and interactions over processes and tools.” And yet, for some inexplicable reason, we chose to add more process in an attempt to fix design. Product Managers & Designers spent hours building PowerPoint presentations meant to help us align on goals, agree on design direction, etc. They didn’t work. Instead, they wasted considerable amounts of time, and led pedantic arguments about language, phrasing — even which fonts to use in the presentation (seriously, this happened).
3. We inadvertently gameified design reviews. With all the new artifacts and process in place, simply getting to the point where a design could be reviewed became incredibly expensive. So that review had to succeed. You had to win — or else it was game over, back to the dreaded drawing board. We no longer sought out feedback to improve our designs, but simply approval. We found ourselves asking toxic questions like “Is this good enough?” instead of striving for excellence.

So, at the end of all this, we were still demoralized and failing at design, but now we were also mired in an absurd amount of ineffectual process and on the verge of an existential crisis.

Somehow, we had made everything much, much worse.

An Unprecedented Challenge

It was here, at our lowest moment, that we were presented with a challenge that would ultimately help us find our design mojo once again.

This challenge was something unprecedented at FreshBooks; a design project so massive, so ambitious, so formidable that it would have been unthinkable to try and solve it using the existing design process. That much was obvious. (What was the challenge? A topic for another day…)

Conventional wisdom would suggest that we were not ready to take on such a project. Better to focus on ‘low-hanging fruit’ and get some ‘easy, quick wins’ to build up our confidence and gradually improve our design process along the way.

But conventional wisdom was wrong. Choosing what’s easy would have allowed us to continue down the same path, limping along with a process that just wasn’t working. In contrast, tackling the hardest problem would force us to re-think design from the ground up, to confront our demons, and to stop coping. Either that or fail spectacularly.

How Have Others?

But where to start? It occurred to us that other software companies had probably faced similar challenges with design and had perhaps even come up with solutions that we might try. So, we set out to answer the question “how have others implemented a successful design process?”

Lean UX: 4 Stars!

We first found promising answers in Jeff Gothelf’s book, Lean UX. It presents a vision of a design process focused on rapid, validated learning; a concept borrowed from Eric Ries’ The Lean Startup. A similar process, “The Design Sprint,” was developed at Google Ventures to help portfolio companies quickly design, prototype and test UX with real customers. Both Lean UX and the Design Sprint also promoted an inclusive & collaborative design process that involved every discipline; “everyone is a Designer,” not just people whose job titles include the word “Designer”.

This all seemed promising, and the fact that we saw such similar processes espoused by several different sources gave us confidence that we were on the right track. But it also seemed a bit theoretical, and a bit idealistic. How could design move that quickly? Is this just design by committee? How would any of this work with Scrum?

Nothing to Lose

The benefit of hitting rock bottom is that you have nothing to lose. We set aside our cynicism and our doubts, and decided that this new, ambitious design project was a great opportunity to test out Lean UX. It couldn’t possibly be any worse than our current process. (Could it?)

As the book suggests, we set up a weekly cadence of design rituals:

Monday: Charrettes

• Charrettes are where we (i.e. designers, PMs, and developers) collectively define the problem we want to tackle each week, and start ideating solutions. We aim to leave the Charrette with 1–2 high-level design approaches that we can test with users. Each approach should have an underlying hypothesis that testing will either validate or invalidate.

Sometimes we do charrettes around sinks.

Tuesday: Critique

• After Charrette, designers and Product Managers work together to refine the approaches, and then present their work to a larger group at critique. Critique is a forum where feedback is shared openly and candidly and no design is precious. And how could it be? It’s less than 24 hours old!

Thursday: Validation

• Also called “Testing Thursdays,” this is when we validate the now refined approaches with real customers.

Friday: Iterate

• On Friday, we debrief on the results of testing and decide what to do next. Sometimes, this means rejecting an approach altogether. Other times, it means tweaking it and re-testing the following week.

Truthfully, we had no idea what we were doing at first. We just booked the meetings, and trusted in the process. And just like our transition to Agile, it was scary, messy, confusing, and emotional. We had to unlearn everything we thought we knew about design.

After about a month of Lean UX, this unprecedented challenge — this project that was unquestionably beyond our abilities — was slowly starting to take shape. We reached a point where customers were consistently validating our designs decisions, and they liked what they saw. We were making progress!

Not only that, but design was becoming fun again. We looked forward to flexing our creative muscle every Monday in Charrette. We had passionate debates in Critique that often went hours beyond the scheduled time. We enjoyed talking to customers each week and humbling ourselves with their feedback.

After so many false starts, we finally seemed to be getting somewhere.

Fast Forward

It’s been just over a year since we implemented lean UX and we haven’t looked back. The benefits are numerous:

• We’re consistently producing better designs. We’ve got more brains working together on the hardest problems.
• We ship with higher confidence. Our designs are thoroughly validated with customers before they ship.
• We’re able to move much faster. Our design sprints integrate directly with Agile Scrum, allowing us to rapidly validate designs in days instead of weeks or months. Also, we de-risk technical uncertainty much earlier since developers are involved in the design.
• Everyone’s engaged and energized to do their best work. Designers, developers, PMs are all working together to achieve excellence. Handoffs are a thing of the past, and we’re our own toughest critics.

And, in the very spirit of Lean UX, we continue to iterate on and improve our design process. For example, we now conduct generative ethnographic research before starting a design sprint to derive actionable insights about our customers that will inform our designs.

Best of all, we finally got our mojo back.

Avrum Laurie is the Director of Product Management @ FreshBooks.com

Sound intriguing? FreshBooks is hiring UX Designers, apply today and mention you read this post for bonus points!