The “Tell Me What You Want” Conundrum

Have you ever hired someone to work on a website project and had them ask, “okay, so tell me what you want?”

Isn’t that a difficult question to answer?

That’s because when you hire someone to build you a website, you often don’t know exactly what you need—at least in very specific terms.

You might know you need the ability to publish blog posts, or share posts on social media, or create landing pages. (Or, even better, your user research has guided you to these solutions.)

But unless you’re some sort of technical expert, you have little idea of how those are built (or what your options are for each of those features, or how difficult/costly they might be).

Open source is a sandbox

The reality of open-source software, such as WordPress or Drupal, is that there are often 5-10+ ways you can implement any given feature. Some approaches might be simple and cheap, but have a lot of constraints. Others might be complex and costly, but scale very well.

There is rarely one “right” way to implement a feature. It depends entirely on your needs.

Behind the scenes, a developer is evaluating these options and making tradeoff decisions. They’re balancing the time to implement each option against the features it offers, as well as how future-proof it will be.

And if you never get the opportunity to discuss these tradeoff decisions, what they build could be something that doesn’t fully meet your needs, or is too expensive, or just takes a lot of time going back and forth.

The developer is left to make these tradeoff decisions in a vacuum—far from ideal.

This is the “tell me what you want” conundrum—in order for a developer to evaluate potential solutions, he/she needs to understand the requirements. But your requirements may change based on the potential solutions and how difficult they are to implement.

It’s a “chicken or the egg” situation.

Solving the conundrum

Let’s start with a simple truth: both parties need specific information from the other.

You as the client need to make an informed decision based on the potential cost of each option, weighing the benefits and drawbacks. The developer needs to understand what is mandatory—and what is negotiable—so they can narrow down a list of options for you.

So how do you go about this song and dance?

One way to approach this is to discuss your needs in terms of user stories, which take a format such as this:

As a <type of user>, I would like <capability> so I can <benefit>

Or, you can use a less formal approach and describe the capabilities in “should” language (although there are some drawbacks I’ll cover later):

<type of user> should be able to <capability>

For example, here is a sample of potential user stories for an online store:

• Customers and front desk staff should be able to print order summaries
• Customers should be able to hover over an image to zoom in on a larger version
• Staff members should be able to configure some products to collect tax, but not others
• Staff members should be able to configure product pricing on a per-size basis

It’s not important that this list be comprehensive, but it does need to capture the major capabilities you know you need.

You also need to outline major assumptions you are making—you know, the things “all sites like this have” that you assume will be included. (They probably are, but sometimes that’s not always the case.)

A developer or technical manager may also be able to assist by asking follow-up questions to drill into the specifics you may not have thought of (such as configuring product pricing on a per-size basis).

The MoSCoW method (no, that’s not a typo)

So, you have your user stories. Great.

The next step is to prioritize these user stories in the MoSCoW framework: must-haves, should-haves, could-haves, and wishes.

(By the way, this is where using “should” language in your user stories breaks down a bit. It can be confusing when a must-have feature contains “should” in the title.)

Here’s an example:

1. Must-haves:
   1. Staff members should be able to configure some products to collect tax, but not others
2. Should-haves:
   1. Staff members should be able to configure product pricing on a per-size basis
3. Could-haves
   1. Customers should be able to hover over an image to zoom in on a larger version
4. Wishes/will-not-do
   1. Customers and front desk staff should be able to print order summaries

User research can also assist the prioritization process—you will get better results if you base your priorities on actual data and conversations with users instead of educated guesses.

With this list, a developer can go to work researching and analyzing various options, eliminating the ones that don’t meet your must-have requirements. Then they can come back with a shortlist of solutions and tradeoffs to discuss.

Discussing these tradeoffs is crucial, by the way, because you as the client need to make these decisions. The developer shouldn’t be making them behind the scenes—at least for large or expensive features such as an e-commerce store that will have long-term implications.

The drawbacks

So why does this conversation not always happen? What are the downsides?

Well, for one, this approach takes longer because research is needed. It’s quicker to just get to work (and often with smaller features, it’s sufficient to do this). You only need to take a formalized approach like this for complex features.

Also, you will probably have to pay for the research to be done. The reality of customizing open-source software is that it’s, well, custom work. The larger the feature, the more likely it is that it has nuances and details that are specific to your needs and no one else’s. This requires tailored research, starting with the process I just outlined above.

But in this case, an ounce of prevention is better than a pound of cure. It’s better to pay for the up-front research and get a solution you’re happy with, instead of hoping and praying for a good outcome.

So next time you hear the question, “so tell me what you want?”—you’ll know how to bypass the frustrating back-and-forth and skip right to the productive conversation.