Of all the words that get used to plan and develop software, it’s hard to conceive of a more important phrase than “Yes, but”.
We’re trained in life to look at choices as binary:
- Should we take the time to make sure our web site is mobile friendly, yes or no?
- Should we include add this new feature idea into the next release, yes or no?
- Should we offer a free trial to encourage signups for our paid service, yes or no?
- Should we allow the user to customize their experience, yes or no?
Questions like these, and many others, are often phrased in a way to suggest only two options are available. The web site is either going to be mobile friendly or it’s not.
When we structure questions like this, we often set ourselves up for confrontation. An engineer who resists supporting mobile platforms because they’re already stressed with other requirements is seen as ignoring both industry trends and user needs. A designer uncritically demanding a mobile experience is perceived to be ignoring the very real constraints of time and budget.
The truth is that there are a myriad of options that lie in between “yes” and “no”. Should the web site be mobile friendly?
- Yes, but we’ll only worry about the most popular pages for now
- Yes, but we’ll limit testing to the most recent devices
- Yes, but we’ll not worry about people using non-standard browser configurations
- Yes, but we’re going to need to invest more money than expected to do it to our standards
When you answer “yes, but” (or “no, but”) you get to challenge your assumptions. You get to avoid paying the full cost for something until you’re certain the payoff is there. You get the freedom to experiment and adjust. You get new possibilities.
Photo credit – Robert Anasch on Unsplash