You are here: Home > All Topics > Why Functional Design Matters

Why Functional Design Matters

No plan, no solid foundation

You don’t build a house without a proper design, technical drawings, a detailed estimate from all suppliers involved… and then expect it to go smooth and within budget, do you?
Do you think your new website or application is any different? A Functional Design is a costly part of your project… But not having one may well prove to be costlier!

Common complaints during or after website / application development, where no Functional Design has been made (and maintained), are:

  • The application does not do what has been requested (read: expected)!
  • the website was delivered late! or,
  • the development cost much more money than budgeted!

What is a Functional Design

Bluntly put? It’s an extensive description of the goal of your website / application and its interactive parts in detail. It’s drawn up in such a manner that it paves the way to make – and hold – all suppliers in the process accountable and exchangeable. It is also the basis for the final quotation that will be made for the various parts to be realized in the process.

Although this actually is oversimplifying things, you could say it’s one big “If This, then That, and does That meet the necessary non-functional requirements, such as accessibility, usability, operability, reliability, and maintainability.

It’s what you need in the process of making sure everyone involved in building your site or app knows what to do.

Which results are expected. Who is stakeholder. And who is not. It is also the means to quickly bring a new developer or designer up to speed on his or her tasks if another falls off the wagon.

And last but not least:

It’s an indispensable tool for smooth communication and Expectation Management

Developing a larger commercial website requires intensive cooperation between many different parties and disciplines. Think about:

  • Client
  • Client’s Branding & Marketing Team
  • Project Management
  • Graphic Design
  • Developers (Programmers)
  • Copywriters
  • Third parties, for example hosting company, Accessibility Consultants, external software systems / parties with which links are made.

With the Functional Design, it becomes a lot easier to communicate with each other, as definitions are synced. It saves time and costs because everyone works from the same starting point.

A possible structure of the chapters that a Functional Design can contain is as follows:

  • Preface
  • Target group & goals
  • Scenarios
  • Structure of the website
  • Features per page
  • Open issues
  • Comments for the designers and developers.

Mine’s a different standard!

The common standard is to strictly have a separate functional and technical design. Which, in my opinion, is entirely based on theory and assumptions. And don’t we all know by now that assumption is the mother of all fuckups?

Assumption #1 – Customers can’t be bothered with technical information.

It is assumed that the Functional Design is intended only for the clients, who are expected that they can’t be bothered with tech stuff and the geek speak. The software developers on the other hand, would only need technical and no functional information. Experience has taught me this is NOT the best approach. The functional designs I create address all involved, but all of that in language that a non-technical reader can understand. When very specific technical language for the developers proves necessary, it is there, in separate sections, per feature. Simply to make sure everyone knows certain definitions. If you wonder why I do that, here’s a conversation between a non-technical person and a developer.

Assumption #2 – When the programmers manage to run the software they created without errors, their job is done.

Technically, yes, but having the functional description – including all the scenarios – of what they are supposed to build at their disposal, will help them judge their work even better. It prevents a lot of problems, especially in the field of User Experience (oft written as UX).

Simplified example:

Take a form with mandatory fields for financial information, such as an IBAN. If the backend developers only had the Technical Design, and the instruction for that form would be to create an error message, for certain situations. For example: error message should appear when the IBAN field has not been filled out, or was filled out incorrectly, the mill could stop right there. Technically speaking, the display of a message saying “error” upon submitting the form, would mean the developer did the job as described. Which would be a horrible thing in regard to user experience (UX). Then if the message itself is not defined, how is the user ever going to know what exactly triggered the error?

If you think this is a stupid example and no backend developer would create it like that

Last week I needed to change the payment information in my user account for one of the world’s best known Weight Loss Programs. A multi-billion global company, founded over 50 years ago. They offer a shiny site, an even shinier mobile app, and an internal social network. You’d think they have their digital act together, right? Well, no. Not really. I logged in on the German pages, and pasted in the IBAN number for my German bank account, which I had copied straight from my online banking pages. Upon submit I got a message saying “Something went wrong, please try again later!”

I waited 15 minutes and tried again. Same error message. So I tried again the next morning, and got the same error message. A regular person would probably get super annoyed by now, and either send a message to support, or try to call support, or worse, voice her frustration on Social Media.

It dawned on my that maybe the format of my IBAN number was the issue. Normally, an IBAN is displayed with spaces, like so: DE10 1234 5678 9876 5432 10. I removed the spaces, and tadaaaaa, submitting the form suddenly worked.

A true story about striking a Functional Design

I was part of a project where the client wanted a to sell paid memberships and physical products, both to businesses and consumers, worldwide. It meant they needed a solid eCommerce solution. They wanted it hooked up to their custom made CRM and their accounting software.

The initial cost estimate came down to roughly € 25.000. The planning was to publish the website 2 months after the start. The estimated price included the functional design, which was offered for € 2.500. Personally I thought that was actually quite a cheap offer for a well written functional design, given the massive amount of time and expertise invested, but I was not the one offering. I kept my mouth shut. The client decided to strike the offer of a Functional Design altogether as they deemed it unnecessary and “too expensive anyway”.

The project ended up with an 8 month delay and worse: the budget was exceeded by € 35.000!

The whole thing had cost 60K, instead of 25K. Which were direct costs. Don’t even get me started on indirect financial damages! They could have prevented this massive disaster, had they not been so ‘Penny Wise, Pound Foolish’. And the same goes for the agency, running the project.

So what on earth went wrong?

Well… about everything that a solid Functional Design could have prevented from happening:

  1. The first and worst mistake was made by the agency coordinating this project. They should never have made working with a Functional Design optional. They were young and enthusiastic – and as it turned out later: rookie – developers, and very eager to do such a challenging project.
  2. They gave the customer a preliminary estimate of the costs, not fully grasping they did not yet have all the necessary information to even begin to estimate.
  3. Cumulatively, billable hours were wasted on needless discussions, out of scope change requests and additional feature requests.
  4. In the middle of the entire process, it turned out the supplier of the client’s custom CRM, which had to be connected to the website, was unable to make things work properly on their end. In geek speak: the API of the CRM sucked. (If you want to know what an API is, have a look at this video on YouTube. It’s one of the clearest explanations about API in human speak I’ve ever seen.)
  5. No one had thought of having some proper research done on how things were supposed to work with international taxes and the accounting system, which caused a massive delay.
  6. The lead designer jumped ship. She was constantly being yelled at by the customer’s marketing manager, as apparently every design made was not according to his – previously never expressed and therefore unwritten – expectations. Stating that she was “done walking around in a minefield every day”, she decided to step down from the job, leaving them in a frenzy to find another willing to be lashed out at all the time.

Guess what? That lead designer was me, 9 years ago. Never before and never after did I step down from a job in the middle of a project. And it all happened because things had either not been defined clearly, or had not been thought through all the way.

I swore never to participate in a project of those dimensions without a proper Functional Design and a qualified Project Manager, ever again. In the years after I developed my own method of actually writing up a Functional Design, working closely with developers to integrate the parts of the technical design that are important for the client to understand.

Am I trying to worry you into hiring me as your project manager and writer of the functional design?

Of course, I am! Although worrying you is probably not the right expression. I’m just being realistic and not as modest as the world may expect of me to be. With my experience, I can tell if suppliers in the process actually know what they’re doing, or if they’re throwing smoke screens. I  understand what kind of hosting a project needs, and how to make comparisons. In cases where I am not certain, I have an extensive network of experts to ask.  I can translate all the geek speak into human speak. So you know what you are deciding for. I’m able to see and understand both the technical and the design side.