Solution design first! Part one.

The first thing that pops into most people’s minds when someone mentions the term “design” is most likely something visual. The point of this post, however, is that that “visual” aspect is just one (admittedly important) chapter in the wider story about design and, that that particular story includes a few more important chapters that often get overlooked.

Throughout this blog, we’ll try to inspect and analyze the process by which the software solutions get designed, and place the UX/UI design in its rightfully deserved and crucial place within that context.

Additionally, and arguably even more importantly, we’ll try to identify another crucial, and often overlooked component of the overall design process — the functional design, and see how we can use this newfound knowledge to “level us up” in regard to our peers and competitors.

We’ll start our analysis by finding out *why* the software solutions get designed in the first place.

We’re in the business of solving problems

One of the basic premises that we’ll base our discussion upon is this:

Anyone who has a problem (that they are aware of), will be willing to compensate someone for solving that particular problem, where the compensation would be proportional to the individual’s perceived importance of that problem

That is really just a fancy (and admittedly, a bit convoluted) way of saying that the money in any business (including the IT agency business) is typically made by solving customers’ problems and getting compensated for the effort. Note that that statement holds true even if the said customers had no idea that they had a problem until you presented them with the solution in the form of your new product.

So if we agree that we make money primarily by solving problems, we then need to figure out what exact problems are we solving for *our* clients?

Well, there are two main ones. The first one is fairly obvious, they have a business idea — ie. an idea of how to solve some real-world problems that their potential customers might have (whether they know it or not) and as a consequence, get the compensation from them — but they don’t have any means of embodying that solution it in a form of an IT system such as web or mobile application.

Or put in another way, they cannot create a technology-based “idea vehicle” for their business idea by themselves. That particular problem we can obviously easily solve for them and get paid for doing so, but, there is another problem, perhaps one that is not so obvious, but is nevertheless extremely important for our discussion.

That second problem is the fact that our clients are typically not technical experts(*), and have rarely (or ever) engaged themselves in the software development projects in any significant depth, but their career paths (or salary bonuses) are more often than not, linked to the success of that software development project.

As a consequence, they feel quite like “fish out of water” when it comes to designing and developing the technical idea vehicles(*). And to exasperate the problem further, IT projects in most organizations tend to be of a “revenue-generating” or at least “revenue preserving” kind, and as a consequence, their success is often linked to the career paths of the people involved (those whose projects tend to fail, usually fare worse in the long run than those whose project tend to succeed).

And the proverbial “cherry on top” of all that is the fact they know damn well that most IT projects fail, at least to some degree.

That’s quite a “pickle” to find oneself in.

So, let’s do a quick recap here. What we’ve postulated so far is that we make money by solving our clients’ problems and that our potential clients typically have the following set of these:

1. They have a business idea (developed to a certain degree) but they have no internal means of embodying that idea into a technical product — ie. they cannot build “an idea vehicle” for their business idea themselves,
2. They are aware that they are not experts(*) in the art of defining, designing, and building a technical product, but that the outcome of the product/project they are assigned to will affect their career or their salary/bonuses at least partially,
3. They know that the IT project tends to be brittle and more often than not fail for numerous reasons.

(*) although some might consider themselves to be technical experts and even can have an actual technical background — unless they can produce a comprehensive a set of functionally complete and consistent requirements themselves (and I have yet to meet a client that can do that) — they still have the same problem.

Luckily for them (and us — as we get our money for solving other people’s problems, remember?), all those problems fall well within our area of expertise, provided that we understand the process of how solutions get designed and can use it to our (and our clients) advantage.

The “solution space” of an engineering problem

Let’s consider how we’d go about finding a solution for the first problem stated in the previous chapter (we’ll deal with the latter two in the next post as this is a multi-post topic).

Let’s restate the problem in a form of a task or an assignment – ie. state what we need to do in order to solve our particular problem:

Define, design and develop a “business idea vehicle” that embodies the client’s business idea in form of a IT system that is functionally complete and consistent, visually and ergonomically pleasing and of optimal technical quality for the scenario it would eventually be used in the “real world”

That is an engineering problem right there, and a thing with engineering problems is that they always have multiple solutions. So we’ll introduce a new term here, and we’ll use it heavily for the remainder of the argument in this text— we’ll call a set of all possible solutions for an engineering problem a “solution space” for that particular problem.

Solution space for the “two-bedroom house” problem

The design is navigating and molding the solution space

It stands to reason that if there is a number of possible solutions within the solution space of a given problem, and if we typically select and develop just one of those possible solutions, then there must be some way of choosing a particular subset of solutions from that space and even molding that actual space to our liking.

Well, there is a way and what I propose here is the following:

Any design(*) process is the process of navigating through and/or molding the solution space of the particular problem.

or alternatively

The process of selecting individual solutions form the solution space of a given problem is called (solution) design(*).

(*) Note that the term “design” here is used in its broadest meaning and since the term is heavily “loaded” to mean “UX/UI design”, I typically try to use the term “solution design” instead. But I wanted to point out what I believe the design process is — when considered in its most abstract form.

We’ll come back to this statement later, but first, in order to understand the position of the design in a wider context of the software development process, we need to define the process itself.

Any software (and not just software) development process goes through the following four basic stages or steps: (they can be, and sometimes are, named differently, or decomposed into more fine-grained sub-steps, but for our purpose, this simple flow will do just fine):

1. Discovery (the process of specifying the “problem” (business idea) in enough detail so that the solution for the problem can be designed. — defines the “what”s and occasionally some of the “why”s),
2. Design (the process of selecting the preferred solutions from the solution space of the problem defined in the discovery phase, composed of three components — functional, visual, and technical —defines the “how”s),
3. Development (it’s…well, development… and also it’s out of the scope of this post, so we’ll happily ignore it for now),
4. Delivery (although there are some connections with the discovery and design stages through the written acceptance criteria, the delivery is also outside the scope of this post, so we’ll ignore it too).

There is nothing complicated or particularly enlightening about the process and its steps depicted above, except for one thing, and I’ll state it again, clearly in case you’ve missed it — because it’s extremely important.

The design of any technical (IT) solution is not a monolithic process but is rather composed of three distinctive design processes: functional, visual, and technical. Each of those process involves different experts within your organization.

We’re all good developers (and UX/UI designers)

At this point we should have a fairly clear idea of why and how we design the software solutions and so now I want to present you with one of the key propositions of this text:

We all do the development stage of the software development process more or less equally well, the thing that make each of us different is the solutions we choose to develop.

What I mean by it is that the software development market has matured, long gone are the days of the 2010s and inept UIs and untested PHP4 spaghetti code FTP’d to the webroot folder of the default apache installation on a shared hosting account. These days, pretty much everyone has decent internal processes, uses appropriate and modern tech stacks, performs automated testing and CI/CD, and can design and produce industry-standard UIs and the UX that goes alongside them.

So if we all do development comparatively well, that leaves us pretty much only with the processes of defining the problem and selecting the solutions from the solution space as the obvious candidates for the things that we might want to develop further within our organization if we want to distinguish ourselves from our peers. And since I’m stating things left and right here, I’ll claim the following is also true:

The design phase of any software solution development process, happens for any project in it’s entirety, regardless of whether we, as an organization, are aware (and in control) of it’s individual aspects (functional, visual and technical) or not.

So, if we combine the last two premises, what logically follows (at least for me), is:

1. Design (and especially its functional aspects) is the area where we stand to gain most in the context of our overall competitiveness — since in other areas it’s much harder to offer something different than our competition,
2. It makes sense to master the process that makes us individual and raise ourselves above the group of our peers and that also happens regardless of whether we control it or not (with unstable and unreliable results in the latter case).

And that neatly brings us back to the opening statements of this post, as for most, the design process is synonymous with the UX/UI design, but what I’ve hopefully demonstrated here is that UX/UI design is just one (very important) part of the overall process of the solution design, and there is another, often neglected one. The functional design.

Conclusion and summary (the first one)

The functional design is a topic in itself, and it is very reliant on the skillset of the person performing it (spoiler alert, it’s someone almost but not entirely like a business analyst), and therefore we’ll address it in our next post.

To wrap things up for this post, however, we’ll summarize what we’ve established so far, and then we’ll (hopefully) build on that foundation later:

1. We solve problems for our clients — and that’s how we earn our money,
2. The problems we solve are of an engineering kind — since what we build are technology-based “idea vehicles”,
3. Every engineering problem has multiple solutions, and the set of all solutions to a given problem composes what’s called the “solution space” for that particular problem,
4. Design is the process of navigating and molding the solutions space and has three aspects — functional, visual/ergonomic, and technical,
5. We all do development well, what sets us apart is which solutions we choose for development, and that is determined by the design process. Or in other words, the quality and versatility of our design process is what sets us apart from our competition,
6. All three aspects of the design process will happen for any development project, regardless of whether we control them or not, the only one we typically control is the visual aspect, in a form of the UX/UI design.

If all that holds true then it makes a lot of sense to become aware of the functional aspect of the solution design process and try to understand it and leverage it to our advantage.

UPDATED - Check out The Functional design part 2 now!