I was interviewed for Adobe’s Creative Cloud blog about how design works iteratively at Wealthsimple. This article is no longer online.
Tom Creighton is a hands-on kind of design director. As head of UX for Wealthsimple, an online investment management service, he believes in the power of iterative design to build and release features on his company’s apps, across multiple devices. It’s an approach that has served him well in his career, as he’s “ping-ponged” from tech startups to agencies and back again, leading teams in building successful digital products.
We asked why he’s such a advocate of the iterative design approach, and asked him to share some of his tips for UX designers who want to work more iteratively in their own careers.
What’s the best approach to iterative design?
First, you need an organization that’s going to support it – one that’s cognizant that we can only bite off so much at a time, and to do more just means everything’s going to suffer. Second, you have to have a very specific and non-yielding bar for what you’ll actually release.
We need to be very aware of the amount of work we can realistically design, build, and launch in a given amount of time. Because we are aware of that, and we don’t always try to boil the ocean on every single project, it allows us to be more sensitive to the scope of what we’re actually launching.
How have you done this at Wealthsimple?
A great example of this is our referrals feature. For a long time it was within the product, but hadn’t received the same amount of design thinking and love that some of the other parts of the product had gotten. We knew, in many ways, we didn’t have enough data to to go all out on a splashy launch just for referrals, but we could launch smaller pieces and ‘make smaller bets’ about how this was going to work, how people were going to react to it, and the kinds of things people were wanting to do.
Because we’re taking a more bite-size approach, we are able to course-correct, see what the data is telling us, what the actual behavior is. In my mind that’s what the actual benefit of iterative design is: you can launch something small that’s great (since there’s still a quality bar to meet) and use it not just as a feature but also as a learning experience.
We put something out to market, just on referrals, just on mobile, and looked at what people were doing with it. At the same time, we were working on the web version of the same feature, but some of our learnings about people’s behaviors on mobile were folded back into that.
If we had launched all at once, we would have missed some of the nuance that having that staggered, iterative approach allowed us to capture.
How do you know when an iteration is ready to be released?
You have to set the bar internally and say, when we’ve covered off these features, we’ll launch. You need to be sensitive to what the ‘minimally awesome’ version of a given feature is that you can actually get out the door, that actually does everything you want it to do. It’s not about building in all the bells and whistles, it’s about holding some things in reserve until we see what the MVP does in the real world.
What do you do when one of your iterations doesn’t work or perform as expected?
I think one of the nice things about working in a very product-focused organization, is there is this tacit understanding that everything is a learning opportunity. The great thing about digital products is we can just ship continuously, nothing is ever set in stone. Within a month of launching our referrals feature, for example, we blew it up, redesigned the dashboard, thought deeper about the interaction patterns based on what we had seen, and relaunched it. It’s now working considerably better.
I think that’s the perfect example of where this iterative approach to design shines. We didn’t spend a huge amount of time on that dashboard, such that we weren’t able to change it. I think that this very forgiving process allowed us the leeway to go in and say OK, we clearly need to make some adjustments, let’s open up the hood and go to town.
A huge part of the iterative process is having that flexibility across the board, to immediately come back to something rather than having to wait or to get permission or to wait for the resources to be available. It’s a nimbleness that allows us to react to things really quickly.
What’s your advice for other UX designers who want to work more iteratively?
A huge part of the equation is having the explicit buy-in across the organization. One of the things you could try, within an organization that doesn’t work this way, is to do very small experiments. Try snapping off one small piece of a project and try working on it iteratively, just to see if you can get something out of the door in a couple weeks and learn from that experience.
Once you can show that working this way has a shorter turnaround time, provides a learning opportunity, and allows you to repair missteps, the organizational benefits of iterative design become really clear. It’s not something you can just drop onto a company wholesale, but it is something you can introduce and show people what happens when you’re working this way.
People also want to work this way. They want to be able to pivot, and ideate, and throw out ideas. We have a standing policy that, at any given time, any of the designers can just throw anything into our Slack channel and get feedback. I think that opens the door to more collaboration and out-there but good ideas.
I think part of the resistance to this is the question ‘what if we make a mistake?’ You don’t have to expose all of these iterative stages to your customer. This can be a very internal process, which your customers are going to benefit from. It frees people up to be more wild in their approach to what they’re working on if they know it’s psychologically safe to just get eyeballs on ideas.
This iterative approach works at all scales. How much actually makes it into the product is really variable and something that’s very controllable.
Why are you so passionate about this way of working?
What working iteratively allows us to do is course correct, test assumptions, and react to conditions much quicker than our competitors. I think it’s a big advantage. If we waited until everything was very buttoned down, we’d be launching an extremely beautiful, usable, and extremely functionality-packed product at a point when the market conditions or needs of customers might have changed.
We’re doing the user a disservice if we wait too long to get something out to them. A lot of our product is driven by the needs of the customer, and if we’re taking too long to give people the things that they want, we’re not doing a good job.