Let ‘Form Follow Function’

Posted on Jan 23, 2014 | 0 comments

Let ‘Form Follow Function’

There is a reason that your frisbee is shaped like a disc…

And it isn’t just because the manufacturer sells more frisbees that way!  In this post we will explore some novel ways to apply this concept to building a software product that will not only save you time and energy during product development but also lead to better designs for your products.


Certainly, you have heard the phrase “form follows function,” right?

Well, if you haven’t, the concept is very straightforward: the form or design of an object is largely influenced by the function or purpose it is meant to serve.  There are numerous ways to define what we mean by “form” or by “function” in a software context, so let’s start out with some common definitions for these things.  Generally speaking, the form of a software product can be defined as its user interface.  The function of a software product, therefore, may be defined as the benefits or features that it offers to its users.  Despite these definitions, the point I’m trying to make is different and more subtle than “let your user interface be dictated by your software product features”, so bear with me.  The subtlety lies in the definition we use for “follow,” among other things.

Before we jump to the definition of “follow”, however, let’s talk for a moment about the way that typical software products are conceived.  In organizations large and small, software products often begin with the user interface or a description of the user interface.  Sketches and mock ups of interfaces usually help to create a better visual picture of what the software will do, and in particular, how its users will interact with it.  This is logical because people who use software are also the ones defining new products, and their window into the product is through its interface.  Just prior to creating UI sketches, we tend to talk about what a software product does.  “What does (or will) it do?” is usually the first question people will ask our software product visionaries.  The question we should be asking first and foremost is: “what problem does (or will) the software solve?”

Until we can let go of the question “what does it do?” we will never be able to shift away from conceiving of software products apart from their user interfaces, but there are big benefits to this type of lateral thinking.

Let’s return now to the definition of the term “follow.”  When originally conceived, the “form follows function” phrase was meant to define “follows” as “influenced by” or perhaps even “dictated by.”  This is not the definition that I want to use in the software product context.  Rather, let’s use the first definition we find in the dictionary: “to come after.”  This is more of a temporal definition that has to do with the logical ordering of things in time.  So, in our software product context…

Let the user interface come after the benefits and features have been realized.

This may either seem like nonsense to you or totally obvious, but it’s neither an impossible challenge nor a suggestion to build N-tier enterprise software starting with the data model layer and finishing with the UI layer.  Allow me to clarify with examples.

Ultimately, your product is built by a software development team

We need a way to define the product so that it can be built by the team.  If we were trying to answer the question “what does it do?” then we might define our product as a set of software “requirements,” such as “the software shall display a modal alert to the user if they have entered an invalid password.”  We may also combine this with the visual sketch of the user interface to make it really clear where to put the message.  However, this conflation of form (user interface) and function (benefits and features) stifles innovation and forces us to design the interface first.  Let’s see how we can do better.

Agile software processes espouse the use of User Stories to better define a product, so we will look at how to use them to let form follow function.  The “modal alert” software requirement, as previously defined, is one solution to the problem of making the user aware when they have entered invalid credentials.  Our user story might go something like “As a system administrator, I want to be notified when I have entered invalid credentials, so that I can correct the mistake and proceed to log in quickly.”

Here’s where things get tricky…

In order to complete this user story, your development team may now demand to know some details: “Should we use a modal alert?”, “Is it OK to refresh the page?”, “What if we just highlight the text box with red to denote an error, and maybe play a buzzer sound?”  These are clearly all questions about form, since the function is to “notify the user” and these options all serve the same function. So how can we avoid answering these questions?

Simply be indifferent to the form, favoring the absolute fastest path to completion.

Practically speaking, this means that you explicitly choose not to define the form as acceptance criteria because this is not required criteria for completion.  Instead, your acceptance criteria may read something like “Given the system administrator is on the log in screen, when they enter invalid credentials, then the software will notify them of the error.”

This will also require you to instruct and communicate your intentions to the development team that form will follow once the software functions.  This is a deliberate product design decision that will allow your team to focus instead on the best ways to enable the software to provide its features and benefits without coupling them to the UI.  Great developers will understand and appreciate the desire to separate your UI from the product functionality, and can technically architect the systems accordingly.

So what are the benefits of this approach?  

First and foremost, it allows you focus on the core value proposition of your software product and test your key assumptions earlier.  Building a beautifully designed interface up front takes time and money, which will slow down the rate at which you deliver key features to test your hypotheses.  Secondly, it improves the design of the product and its user interface because you can allow the UI design to be influenced by the actual software features, with a working prototype for reference.  Further, the software is more likely to be built (technically speaking) in a way that allows for flexibility in the interface because you communicated up front the key design decision to let form follow function.

So I encourage you to experiment with this technique, maybe even compare it with an up front UI design style, and share your successes and failures in the comment section below.

Leave a Reply

Your email address will not be published. Required fields are marked *