Imagine for a minute that you’re in the business of making aeroplanes. A client comes to you and asks for something to get from one city to another. They give you a timeline and budget. You prepare a set of documents describing the plane they’ve ordered, its various features, the paint job, etc. You have a great meeting with the client where they ask, ‘Can I get from one city to another with your plane?’ You say ‘Yes, of course, we make the best planes on the market’.

After many months of hard work, the day finally arrives to unveil the client’s plane. Everyone involved meets at the hangar and, with a drumroll in the background, you pull the sheet off for the big reveal.

The client looks confused. One of the cities they want to go to doesn’t have an airport. How are they going to use your plane to get there? You thought they knew planes needed airports (how could they not?!), and they had never really told you specific cities, so you couldn’t have seen this problem coming.

You outline the options for building an airport in their city (much too expensive) or flying to a nearby city and using other types of transport to get to the final destination (much too slow). The client has a sudden epiphany: ‘Oh, I see the problem. I meant to say, ‘Can I get from one city to another instantly?’ Sorry about that. Can you make a teleportation device for me? I still need it today, and the budget is the same…’

Clearly, there’s not going to be a good end to this story.

Unfortunately, creating digital campaigns often turns out like the above analogy. Due to the fact that there are lots of fancy words being thrown around and important-sounding people in meetings, we simply switch off. There’s a tendency to only check the work at the end of the process when we receive it. Just like our plane analogy, this can cause major problems.

So how do you get what you want, on time and on budget, with all the necessary features, but without speaking the same technical language as the developers?

Rule One: Nobody knows what they want

Ever. Especially not at the start of a project. Certainly not to the level of detail that we need to make a website/mobile app/instatwitfacepinbooktube plugin. Don’t ever forget this, as you need to discover what you want (in detail) just as much as we do. If you’re in denial about this, it’s not going to go well.

To help us all discover what you want, give us as much detail in the brief as you can. A great rule of thumb is to continually ask ‘Why?’ until the answer cannot possibly be misunderstood, even by someone who knows nothing about the project. Asking ‘Why?’ up to fifteen times on a single point can be what’s required to get to the core of what it is you really need. The more you can pre-empt this or at least be responsive to it, the more we’ll hash out when we’re changing sentences on paper (takes 5 minutes) instead of code (takes 5 weeks).

I know that all this detail seems completely pedantic. We’re not trying to trick, confuse, or overwhelm you – we’re trying to understand what’s important to you. We need to know which parts of what you are saying are the actual requirements and which parts might be unclear due to lack of terminology.

For example, you’re not going to say, ‘I need an EmberJS app with CDN delivery of static assets’. You’re much more likely to say something like, ‘I want it to be like LivingSocial’. We then need to determine whether you want coupons, bright colours, and Like buttons everywhere, or whether you want pages to load at lightning speed that are visually appealing.

Rule Two: Visualise the end product up front

Using the answers you gave us in the first part of the process, we’re now going to make detailed assumptions about what it is you actually want. We’ll give you a set of documents that describe the technical assumptions we’ve made for you. These could be called ‘requirements’, ‘use cases’, ‘wireframes’, ‘functional specifications’, a ‘scope of work’, ‘user stories’, or some other fancy word for ‘Here’s what we think you want’.

If we have time and budget, we’ll make these as interactive as possible so you can see what we’re talking about. Using tools like InVision or Solidify we can turn napkin sketches of a user interface into an interactive prototype that you can click/tap through and interact with on desktop and mobile in less than 15 minutes (for small apps). This is a great way to get a feel for what using your app will be like when we make it.

It’s important that you understand and can visualise each page and user interaction at this stage. Pretend to be a user who wants to accomplish a task using your tool and try to do it. Actually fill in the form fields if you can. Click all the links and buttons you can, including any terms and conditions and help links. How does it feel? Does the progression from page to page make sense? Does the order of the steps in the process make sense?

If the interactive version feels restrictive, print it all out. Start at the first page and try to actually perform a task using your paper prototype. When you tap a button or link, switch to the piece of paper that represents the screen that would load, and perform the next step. Write into the form fields with a pencil. Does it make sense? You’re trying to find problems like, ‘When I go through the registration process, I don’t see a home button on step two. Why is that?’ or ‘It feels like I’m entering in my details in the wrong order’. There might be a good reason that it was designed this way, or you might have discovered something we didn’t assume correctly about what you want. Make sure you ask us about the things that seem odd so we can either tell you why they’re like that, or fix it.

Once you’re happy with your prototype, grab someone in the hall that knows nothing about the project and ask them to perform a task with it as well. The more you can flesh out what you want here, the more efficient and less costly the development process will be. This also sends a clear signal to your developers that you’re working with them and understand the documents they’ve given you.

Rule Three: Stay firm

Once you’ve started the development process, the best thing you can do to preserve your deadline and budget is to let your software get created as it was specified. You can always release another version or support for another platform later. Keep your scope as razor-focused on your original goal as possible. Scope changes get more and more expensive the later they’re introduced.

Sometimes changes are unavoidable (eg. a new legal requirement means it has to work differently) but be realistic if we say it will cost more or take longer. Creating quality software takes time.

If you do have to change the app as it’s getting created, approach it sympathetically. Try to make your feedback as constructive as possible. Give consideration to the developers who have spent many hours trying to deliver a good product for you based on their understanding of your requirements. Avoid jumping to the conclusion that something is wrong, and give them a chance to work with you to solve the problem.

Stay open to possibilities, even though initially your requests may be met with a ‘No, that can’t be done’. Acknowledge the hard work they’ve done and that your requirements are new and different. Offer them the flexibility to solve the problem for you. Who knows? The developers may be able to deliver something new and innovative that you never even dreamed possible.

Conclusion

Allow us to discover what it is that you want together. Visualise what we’re going to create for you. Finally, once we’ve agreed to a solution, focus on sticking to the plan. By following these simple rules, your brand’s digital work will be executed in an economical and efficient fashion with the greatest possible quality. That’s what we’re all trying to achieve.