Solution design first! Part 2 — The functional design

In this post, we’ll talk about a foundational component of any solution design process – functional design. We’ll discuss what it does, why it’s essential, and how it fits together with and enables all other design processes.

We’ve covered a lot of ground in the previous post about the solution design as a concept, but for the subject of this one, probably the most relevant is the following statement:

Functional design is a basis and a prerequisite for all other design processes (UX/UI and system architecture design) — as well as for the development process itself.

Put in another way, in a hub and spoke model — functional requirements are the hub (or if you prefer the “Big Lebowski model”, then they are that proverbial rug that ties the room together).

But, in whichever way we decide to put it if what we’ve stated above is indeed true, then the functional design is *very* important, so let’s try to dive deeper into its concept.

The functional design

We’ll start with the following definition/claim

The functional design is a process through which we discover and specify the functional requirements for a solution in a way that ensures that those requirements are optimal for the given problem and are at the same time functionally complete, implementable, and agnostic about the details of their subsequent implementation.

What this implies is that the functional design is (or should) always be the FIRST process that happens in any software solution development scenario (and not only in software development, but that’s really outside the scope of this post)

It also follows that every other process which is a part of the wider software development process, regardless of whether the process in itself is agile or not, relies heavily on a well-defined description/specification of those functional requirements.

Functional requirements themselves are, in their essence, the explicit specification of all the GOALS the system should allow its users to achieve — with its ultimate purpose being the base input (or a foundation) for all subsequent design processes. The goal of those design processes would therefore be to define HOW those GOALS should be achieved by the system’s users.

The functional requirements are a collection of all the GOALS that the system under design should allow for any of its users/actors/stakeholders to ACHIEVE by using it, accompanied by a set of statements that define the important details and acceptance criteria for those goals, written in such a way that no implementation details are implied.

Another (shorter) way to define the functional design (and its primary actor — the functional designer) would be:

The role of the functional design (and a functional designer) is to define (and maintain) WHAT the system should do while taking as much care as possible to NOT suggest the details of HOW it should do it (*).

(*) unless at the moment of creating the functional requirements, some implementation details are already known — for example, there will be cases where the functional designer will arrive at the scene only after some (or all) UX/UI design has already been done (that’s not the best approach by any means, but it does often happen for various reasons), in which cases some of the HOWs (the user interface is really an implementation and embodiment of the wanted user experience) are already defined and a good functional designer will then include those details in the functional requirements they produce (see aspect #3 later in this post for more information)

If we consider what we’ve defined so far, the following 3 main aspects of functional design (and the role of the functional designer) stand out:

1. Discovery, documentation, and validation of a complete set of functional requirements (a.k.a. WHATs)
2. Maintaining the separation between the WHATs and the HOWs (ie. between functional requirements and implementation details)
3. Maintaining the role of the functional requirements as a HUB in the hub & spoke model (ie. maintaining the relationships between the WHATs and their subsequently designed HOWs)

We’ll address each of those in its own chapter.

Aspect #1 - The discovery, documentation, and validation of the functional scope

This aspect of the functional design is most akin to what a typical business analyst does. Techniques are somewhat similar (and will be explained in more detail in the subsequent post in this series that now seems like it’s going to be at least a “trilogy”) and they “boil” down to the following:

1. Defining the high-level, complete functional scope — by defining actors and their goals, or user stories via techniques such as actor/stakeholder interviews and user story mapping, etc.
2. Defining the behaviors and specifics of how the particular goals are reached by writing down use cases, acceptance criteria, business rules, etc.
3. Making sure that the specified scope is functionally complete — via techniques/approaches such as process/entity input/output mapping, etc. (or even a simple “CRUD” method described here)
4. Making sure that the specified scope is implementable — via reviews by the system architects and UX/UI designers

One defining element of this part of the process is that the first step defined above requires input from the client for whom we’re designing the system, and that input will never be functionally complete. So as a result, a functional analyst will first DISCOVER the “kernel” that the client can provide us with and then DESIGN the functional scope around it, ensuring that it’s functionally complete, consistent, and implementation agnostic at all times.

Or, to sum it up

One of the most important roles of the functional designer is an ability to fill-in the gaps between the client’s idea and the functional scope of a standard IT solution (be it a web application, a native mobile one, an offline server process, etc.) in such a way that the resulting functional scope is complete and consistent.

Since examples are to definitions what pictures are to words, let’s try to illustrate what we mean by this “gap” that the functional designer needs to fill — with an example, and this time, for the reasons of making this text more glamorous than a typical technical text tends to be — instead of a software solution we’ll build a “luxurious floating solution” ie. a yacht as it’s commonly referred as by the layman.

And the rest is a yacht

Picture the following: You are asked to design and build a yacht for a client, and the client who came to you has a very clear idea of certain things about that yacht, perhaps they have a very detailed set of requirements for a lounge going as far as defining the number of mirror segments in a disco ball and have a clear idea how many people should yacht comfortably house, and exactly which other yacht owner it should make jealous, etc. but for all the rest of the details that define “a standard luxurious floating device” the requirement is simply “the rest should be like a yacht”.

Ie. those “client sourced” requirements would go something like this

• Should comfortably house 10 people
• There should be 3 bathrooms
• The disco ball in the lounge should have at least 10 000 individual mirrors
• …
• (And the rest should be like it’s on any yacht that I, the client, personally find to be attractive)*

(*) that “and the rest is a yacht” bit is both a silent assumption and also where solution design in general and functional solution design, in particular, come into play.

Now if you change “boat” to “web application” or to “Android app” or to whatever you produce — my proposition here is that the (extreme) example above represents something you’re familiar with, within your line of work.

The main difference here between the “mere” discovery process is that the functional solution design is not a passive “interview-based” process where you get and document functional requirements from the client, but rather that you actively provide the first iteration and draft of “and the rest should be a yacht” part of the requirements and only then involve the client to confirm your solutions.

What you achieve by doing this is that the client fairly quickly

1. Come to the (guided) revelation that there is much much more to this project scope than they thought
2. Realize that you got their back
3. Get to focus on “money-making stuff” rather than minute details of how the Fulltext search will work

So to sum up, the role of the functional designer is both to discover and document the functional requirements (WHATs) and then to build them up and fill out any functional gaps, until they describe an optimal solution of a type (ie. web application, etc.) that their organization is in the business of building.

Aspect #2 — Maintaining the separation between WHATs and HOWs (a.k.a. being implementation agnostic)

Perhaps you’ve spotted a “theme” forming in those definitions — and that is that we’re going to lengths to separate the functional design from other design processes and the implementation, as well as to separate WHATs from HOWs. That is not by accident mind you, that particular aspect of the functional design is extremely important for a rather simple reason.

Think about it. Software development is a collaborative process that invariably involves a team of highly skilled specialists. You have your UX/UI designers, system architects, developers, testers, etc. Also, none of them comes cheap.

So given that each of those roles brings a lot of expertise to the table, as a project sponsor, or manager, what you want is that all of that expertise gets utilized to its maximum, (or in other words, to get the “most out of your buck”). The most efficient way of doing so in my experience is to make sure that:

1. Everyone is able to utilize their expertise to the maximum applicable extent (ie. UX/UI designers are better than anyone else at designing user interfaces and interactions, as are system architects when it comes to defining the optimal technology stack and architecture, etc.)
2. Everyone is given well-defined problems (WHATS) and give them as much freedom as possible to come up with solutions (HOWS)

For example, if a functional designer oversteps their boundaries and starts venturing into UX/UI by for example inventing references to particular UI elements — such as buttons, etc. — in their use cases or acceptance criteria, then the UX/UI designer (who by definition comes to the stage, AFTER the functional designer) can not bring it’s full expertise to the project — as some of their work has already been done (usually poorly or average at best) for them by the functional designer. At that point you usually have one or other of these two outcomes:

1. UX/UI designer argues with the functional designer and your team cohesion suffers as a result
2. UX/UI designer shrugs and works around the UX/UI details interjected by poor functional design, and as a result, you don’t get the full “bang for your buck” from your valuable UX/UI designer.

So what logically follows from the argumentation above is that one of the principal skills that the functional designer should possess is to think in purely functional terms and keep their distance from the HOWs as much as possible.

Here is an example of how that typically can be done in practice:

On being UI agnostic — or the UX designer is a functional designer’s best friend

UX/UI design and functional design really go hand in hand, or as one of my more eloquent (and acerbic) friends succinctly has put it, “we all fart in the same sleeping bag”.

However, regardless of how close those two processes get, the UX/UI design does come AFTER the functional design and is based upon it. So it’s very important for the functional designer to keep in mind that they are not UX/UI designers and that they shouldn’t overstep their “jurisdiction”, or they’ll both get UX designers angry for a good reason, and will also jeopardize the overall quality of the product.

In practical terms, that means that all the output of the functional design process (user stories or actor/goal pairs, acceptance criteria, use cases, and business rules) MUST be UI agnostic.

For example, consider this main success scenario for a user story stating “As a user, I can place an ad for my bicycle, so that I can have it listed and found by potential buyers”:

1. The user clicks on a “submit” an ad button
2. The system renders a UI that contains a select box with all available ad categories
3. The user selects the “bike” ad category from the list and clicks on the “proceed with ad placement” button
4. The system renders a UI that contains the following input elements: A text input for the ad title, A select input element populated with all bike manufacturers, etc…
5. …

Now consider this, UI agnostic use case for the same user story

1. The user informs the system that they want to place an ad
2. The system asks the user in which category they want to place their ad
3. The user informs the system that they want to place an ad in the “bikes” category
4. The system asks the user to provide the following information about their ad: ad title, bicycle manufacturer, etc.
5. …

The first use case heavily implies UX (clicking on a button after which a different UI is rendered) and UI (listing individual input elements), while the second focuses on UI-agnostic interaction between the actor and the system. The first will irritate your UX designer colleague and make their job more constrained and less creative, while the second will give them all the required information they need to do their magic and let them design the living daylights of those user stories.

Also, note how the second one rather clearly implies that every ad has a category as a defining characteristic and that the ad’s structure might differ between categories. That is the desired “side effect” of a decently written UI agnostic use case — that it communicates the crucial information without obfuscating it with UI details.

It’s very easy to slip into “hidden UI” design while designing the functional requirements, as most of us share the hidden conviction that “I’m not a designer, but I know what I like” (just like everyone wrongly thinks that they are a football coach, national sports team selector, epidemiologist, or generally an expert in any topic that they feel strongly about but haven’t really studied in a non-superficial way), but that is wrong and is a duty of a good functional designer to be aware of it and to take action to avoid it.

Aspect #3 - Maintaining the role of the functional requirements as a hub in the hub & spoke model

Any project will go through the solution design phase (voluntarily or implicitly/silently) and since the solution design is composed of three separate but highly interconnected design efforts (functional, UX/UI, and technical/architecture) performed by a separate group of specialists, what often happens (If we don’t take actions to prevent it) is the “balkanization” of the requirements as a whole, and loss o hub and spoke relationship between them and also, loss of the single source of truth principles.

On many projects I’ve been involved with, most of those which had some degree of issues with failing to reach their sprint goals, missing the deadlines, or have suffered an abundance of “but we thought that…” situations, the general context was often that the functional requirements were out of sync with the UX/UI designs/templates. The problem was that the technical/development requirements were based mostly on those UX/UI designs, resulting in the incorrect or incomplete implementation of required underlying behaviors.

That is not a good situation to be in, but unfortunately, it’s very common unless there is someone whose role is to “own” the functional requirements and ensure their role as a hub for all other requirements remains stable throughout all project phases.

Scrum methodology has this covered by having a product backlog owned by the product owner — and that backlog is composed of story cards where each story card must be considered a “single source of truth” about the particular story and therefore must contain the functional requirements (the story and implementation agnostic/function acceptance criteria) and all other requirements must be referenced within it.

The fact that this is often not observed in the actual implementation of the scrum is a topic for another post, but still, the framework is solid and the role of the functional designer in that context is to mimic that of the ideal product owner in the scrum framework and ensure the integrity of the product backlog (or it’s equivalent) regardless of the project methodology.

This goal is typically achieved by the functional designer being the “owner” of the requirements (regardless of what form they are in) and making sure that the team understands the three “pillars” of the solution design process.

A functional designer is the OWNER (and sometimes the defender) of the functional requirements throughout the entire development process.

Open and unhindered/informal communication regarding the requirements — ie. that everyone involved is aware that the requirements might and will change, and that it’s ok, provided that the “referential integrity” of the whole functional scope remains undamaged, is of crucial value and should be one of the main methods through which the goal of maintaining the hub and spoke model is achieved.

The hidden role of the functional designer (a.k.a. business analyst) — a “solver of problems”

In most situations, a functional designer will be the first person that the client will have an operational experience with. Up to that point, the client was typically involved only with salespeople, account managers, and perhaps project managers — but everything done was related to setting up the project and discussing budgeting, and the “first day of the project” is usually lived by the “point person” from the client side and the functional designer alone.

At that point, that “point person” will feel quite a bit vulnerable and unsure — since they know that”

1. A lot of IT projects fail for one reason or another
2. The eventual failure of “their” IT project *will* reflect on their immediate career path
3. They are not able to create a solution by themselves so they are relying on the “kindness of strangers” (a.k.a. you) to do it for them, and to do it well.

So what they really need (and hope for) from their functional solution designer, is not just to be technically competent and to be able to design great functional solutions.

The ability to solve problems on the spot, mold the functional scope, and navigate the solution space “in real-time”, in general, are key skills any functional designer should possess, but they are far from the only ones — here is a link to the blog post that discusses other required skills in more detail, just replace the term “requirements architect” with “functional solution designer” and you’re golden.

Summary

In this post, we’ve talked about quite a few things and hopefully defined what functional design is, why it’s essential, and what are its main aspects/components. We also touched on its deliverables and the “hidden” role of the functional designer.

In the next post in this series, we’ll perform an actual functional design of a simple but realistic system, and hopefully, provide you with that proverbial rug that ties all we’ve talked about so far together.