For the past 10 years of my career i’ve been extremely lucky as I worked with some very talented people. In several occasions i felt inspired by the talent my colleagues possessed. Still remember the first intern i worked with and how good she was (she is thriving now), that technical architect in my first job that had all the answers and my amazing colleagues at TransferWise now.
The thing that i haven’t had though, in such extend, is the amount of driven people around me. Here at TransferWise everyone is really driven and really focused on giving the best possible experience to our users. Nothing goes out without thorough testing. No decision is left unscrutinised and there is no lack of support either. The one thing though that surprised me the most is how data driven the company is. There is all sorts of data for everything. User journeys, workflows, happy paths, new interactions, everything! People really like data.
As a result you find yourself too many times in a position where people will ask you about that data, when designing a solution. Is it useful or not? Do you have enough data and what do they mean? Being in a position like that is a great thing because, along with the user testing sessions and the A/B tests, you get to understand how the users use the product. So yeah, hooray for the data!
A/B test all the things (not)
I’ll be honest with you, I’m not a huge fan of testing everything. I think that in many cases it’s a huge waste of time, and more often than not it’s a (bad) way to deal with your insecurities. Let me clarify though!
There are some things in life that you can’t A/B test. For example, how do you test the experience a new page provides when you redesign it completely (with the aesthetics in mind)? Are the aesthetics not essential? I personally think they are, and Apple is the best example for it (how much for that new macbook with USB-C ports only?). The experience you provide is many things coming together. Performance is experience, Aesthetics is experience, new typography is experience and functionality is experience too. And while you can get data for all of these things, what are you comparing it with? Is there value comparing an old product with something that’s totally different? Are you ever going to throw away 3 months of work if the data is not 100% against your changes?
The answer to that last question is no. You won’t throw it away, you will iterate on it. That iteration process is where you need data, then you have things to compare, but before that I feel that you are just wasting your time. Moreover i sometimes see an A/B experiment as a kill switch. A way to say “If something goes terribly wrong, I’ll flip a switch and I’ll back to the old thing. We’ll be alright”. To that my answer is, trust yourself and the preparation you’ve done. And if need be, you’ll work together, as a team, and you’ll fix the problems. More often than not, you won’t be able to do something that is catastrophically bad for your product. I always begin with the assumption that people will do the best possible job they can before deploying anything (and that’s where working with talented people is important and awesome).
FInally, for an A/B test to work properly you need to have an assumption. A sneaky suspicion that something could (or couldn’t) work. That’s what you should A/B test. If you don’t have a very clear assumption and you just test for the sake of testing then you are in danger of getting paralysis by data.
The above is my attempt to describe the fine red thin line that you have to walk sometimes between getting data and delivering fast. I don’t see decisions to not collect data as a discount, I see them as strategic decisions on bringing something faster in front of a bigger portion of users. As a result you’ll end up collecting more data and more valuable data later in the process.
Feedback
As I mentioned above, I’m lucky enough to work with talented and driven people. As a result every time I’ve done something that was against the beliefs of another person I got immediate and passionate feedback. This is the best thing that can happen to anyone because a fresh pair of eyes always brings a new perspective. If you are lucky to get feedback after then keep an open mind, listen to people and try to adjust your decision making abilities, as you feel necessary.
Also, be open to being wrong. It’s simply impossible to be right every time, if you are good enough you’ll be right sometimes. Remember to not support something that looks wrong after openly listening to all arguments. Be prepared to adjust. That been said, listen to your experience and your gut and hold your ground if you feel strongly towards your idea. The crowd isn’t always right. The old guy isn’t always right. The intern isn’t always wrong.
Convictions
No matter what we choose to do though, we as designers of solutions, we need to remember that our choices are impacting real people, not numbers or robots or anything else. Real people that can’t complete a self assessment because your site is complicated. Real people that they can’t book a GP appointment because your system is terrible. Real people that they try to send money to their loved ones but they can’t because there is this nasty bug. Whatever you decide to do, keep these people in mind and always try to improve their lives. Always improve things. And be open to new ideas.