by Dan DeMeyere - @dandemeyere
When you work at a start-up, you're not given a bulleted feature spec. document detailing every design detail, each UI interaction a user will experience, or how every page of a feature is supposed to flow. Although it can vary, you're usually given three things: what the feature is, why we are building it, and basic expectations of the deliverables. Some people find this overwhelming. I, however, wouldn't want it any other way.
The freedom of taking a feature concept and turning it into a functional aspect of your web app used by thousands of people every day creates a certain level of responsibility that is intoxicating.
Every decision is important. Deciding how your feature will hook into the current app on the back-end, how users will navigate to your feature, etc. are all decisions you need to work through on your own and they typically require a decent amount of thought. The easiest way to go about this is putting yourself in the shoes of your user and asking yourself, 'if it were me, how would I expect this feature to behave?' But what if you can't put yourself in the shoes of your user?
thredUP.com's demographic is comprised of over 99% women. 100% of thredUP members are parents. One could make a very strong argument that it's not possible for me to be further from our demographic, yet I develop for thredUP every day and build features that our members enjoy (I hope). So what are some of the tips I use?
Align Your Perceptions
If you're not a power user of your service, find one and talk to them. My CEO is a parent of a 9 month old girl and he uses thredUP for almost every piece of clothing she wears. Because of this, I can pick the brains of one of our super users without leaving the office. I might think a feature is great, but then again I don't have children and I'm not using the service out of necessity so my perceptions aren't really aligned with reality.
Another great way to ground your assumptions is to do customer service. Talk with your users. See what problems they are having and what isn't obvious to them. Something you think is intuitive might be confusing to your user. I live in a world of Macbook Pros, iPads, Androids, and know what AJAX is and how it should behave. However, over 47% of our members use Internet Explorer and some of our users are notorious for 'double-clicking the internet'. This is why we've started disabling buttons once you have clicked them and display activity spinners every time an AJAX call is made to let our users know the service is processing something. Intuitiveness is relative. The dichotomy between Windows users and Mac users is sizable enough where you can't assume that a behavior you find second nature on your iPad won't be obscure to half your users.
Use Your Service
This might sound ridiculous, but you have to use your service as your members do. If I worked at Quora or Twitter, two services I use and enjoy, this wouldn't be an issue; however, some of us work and develop for services that are not intended for us. This shouldn't stop you from experiencing your service the way your members do. For example, I pick and list boxes at thredUP and I even have a public profile on our website. The last time I listed a box, I found myself noticing how 4 steps should really be 3 and that an email I received wasn't as helpful or descriptive as it could be. These are the things that help you avoid developing blindly and building features no one will use.
Of all my tips, I fall victim to this one the most and it's probably the most important of them all. My bosses emphasize doing this on a regular basis and I'm grateful as it's important to discover the pain points of your service first hand.
Metrics, Metrics, Metrics
Figures don't lie, but liars figure ~ Mark Twain
Have you ever gotten into an argument where someone states something like 'all of our users ' or 'no one uses ' and you know they are wrong but you can't prove it? This is why you need to become friends with metrics. If you can't pull them yourself, find a developer who can and ask them for a specific data-set. Sometimes the easiest way to do this is to tell them exactly what you're hoping to derive from the statistics. Translation can be lost between models/databases and the names of features thrown around the office. A good developer should be able to find conclusive data for the metric you're looking for.
Solid metrics with proper baselines can save you from arriving at the wrong conclusions. I wish I did this more, but benchmarking all your features after enough time has passed to collect a valid sample set of data is foolish not to do. I sometimes say to myself 'if only I had more time', but that's just a lazy statement. You could run one query that takes you a minute to write that could save you days of development. One great example of this is when we launched a new homepage design that we all thought was amazing, but the metrics disagreed. The homepage had notably worse conversion rates and it became apparent that we had to move on and figure out why our development assumptions were off. I actually wrote about the dilemna we faced and the art of swallowing your pride and admitting when you're wrong. Which leads me to my last point.
Know When You're Wrong
If you're not in your demographic.
If you're not a super user of your website.
If you don't have metrics to back up your assumptions.
Then you have to face the music.
The fastest way to lose an argument, lose your leverage in arguments, and lose respect is by making unfounded statements. Bite your tongue unless you know what you're talking about. Before you go into a meeting and discuss the conception or evolution of a feature, think out your reasoning and be ready to back it up with something undisputable (metrics) or personal experience with the matter (user stories). Maybe your still wrong, but you won't lose respect if you're prepared and you're offering conclusions on valid assumptions.