So, you've got an idea for website or mobile app that you're really excited about, and you're ready to define what it should do. The first thing that pops into your mind might be something like, “the app should be easy to use”. Not an unreasonable thought. However, ease of use is how you market your platform or app – not how you get it built.  Words like 'easy' or 'quick' should not appear in the brief you provide to developers. Let me tell you why.

A dictionary definition of easy is, "not difficult to do, not needing much work".  Interestingly, this definition doesn't tell me what easy is - it's just telling me what "easy" isn't. This is because the word "easy" (like the word  "difficult") fall into a category called "vague" words.  

The same dictionary tells that the definition of vague is "not clearly or fully explained"), and that's really the crux of this article. You cannot be vague when defining what your product should do.

There are many words used in everyday speech that fall into the "vague" category. Big, small, large, little, simple, quickly, very, many and lots are all words that shouldn't be used to describe what you want your product to do. The problem is that each of us places a different expectation on a particular word.

Take the word "big" as an example. How big is big? Compared with a mouse a sheep is big; compared with a sheep a horse is big; compared with a horse an elephant is big. It's only when someone else delivers their version that you might realise the chasm between their expectations and yours.

If you define your product without a clear and fully explained description, there are three likely outcomes:

1. You will not get an accurate estimate for how much it will cost to build your platform or app. If your developer has to make a lot of assumptions about what your vague words actually mean, then they may over (or worse!), under-quote you.
2. Your developer won't build what you've pictured, what you need and what you expect. You ordered a horse, but they delivered an elephant.
3. You and your developers will find it hard to determine when your requirement has actually been addressed by the solution. What I mean here is that when you go to test your product, how will you measure whether it is 'easy to use' or whether a screen loads 'quickly'? What are the parameters? And hence, how will you objectively determine that your platform or app is doing what you asked for?

The end result is a lot of frustration and, even worse, a project that costs you more money, and takes more time to complete than you ever planned for.

I reached out to my favourite copywriter and PR guru, Emma Edwards from Write Now PR to explain why vagueness causes problems in communicating what you want. “Assertive, precise language – using concrete terms – gives everyone a comfortable framework.” Emma says, “No confusion, no complication.

"Often we say that we want something to be ‘like' or perhaps 'better' than another. For a developer, who deals in detail, words like that are as useful as telling your mechanic that the model of your car is silver. It doesn't give them a clear reference point, and ultimately exposes you (and your project) to an entirely subjective response.”

Emma suggests the following, "Precision is essential. That means you need to think more deeply about the words you use than any of us tend to do in day-to-day life. Think of yourself as that wine connoisseur detecting woody notes and undertones of a freshly opened can of tennis balls – you want to think deeply, and articulate painstakingly what you envisage and expect from your platform or app.

"Use language that cannot be misunderstood and which conveys certainty. If something *must* be a particular way, then state that. Because there is a big difference between 'I would like' and 'it must'. Instead of 'a few’, ‘a couple of’, ‘around', etc., state an actual number. Don't ask for it to be 'better' than Facebook – show and tell people what that looks like.

"The message that vague, fluffy language sends is that you're actually not clear on the detail. And if that IS the case, you need to go back to the drawing board."

It's actually not that 'easy' to avoid vague words. The main thing is to dedicate the time to think about what you want your product to do in detail. If you are clear on what your platform or app should do, the need for vague words goes away.

Some examples of specificity include - "I want the screens to load within 2 seconds" and "The user should be able to complete the process in less than 5 minutes".  However, you might not always know what the specific piece is. Sometimes, that's ok - it can come out later in the process. If you're aware of where the vagueness is, you can highlight that to your developer.

Defining your product is full of pitfalls and considerations like this. It’s essential for you take the time to understand what you need to do and what's expected, in order to set yourself up for success.