An Introduction to Conceptual Design

Simply put, first rate software design should:

• Detail the key concepts and behaviours of the software.
• Establish a common vocabulary.
• Define objects, outcomes, actions, and relationships.
• Align project stakeholders on all these aspects.
• Uncover hidden dependencies, duplications, and contradictions that surface during this process.

There are various methods to achieve the above. For instance, Semantic Design as advocated by Daniel Rosenberg can achieve this with a cunning use of spreadsheets and lists, I won’t cover this here, as Daniel’s book Magic UX covers this topic in detail. However, I’ve found the approach that resonates best with me, and ensures the highest quality outcomes is a simplified and less rigorous variation of Daniel Jackson’s Conceptual Design as defined in his exceptional book The Essence of Software, I had been designing in a similar way for a decade, but Daniel Jackson codified and expanded on this way of working in a way I could only dream of.

Please note that this is distinct from Conceptual Models as espoused by Don Norman in his classic book The Design of Everyday Things, which concentrates on improving user interfaces via improvements to the Design Model; Conceptual Design on the other hand strives to improve, minimise and clarify of the very ideas underpinning the software to the extent that an improved user experience happens by osmosis.

An excellent Conceptual Design can jump curves in terms of usability, an excellent Conceptual Model can only improve software as far as the underlying system image allows it to, thus the Conceptual Design is a more complete tool for us here. There’s one final and important argument to consider in favour of designing software in this way, when you design in terms of concepts, you can evaluate usability in terms of concepts, and this is extraordinarily powerful and it opens up new simpler yet more comprehensive ways of evaluating the usability of your software, for more on this, see the section on the Usability Harmonics.

Levels of Design

Software design activities can be categorised into three levels:

Once an application has shipped, visual and informational changes are comparatively easy to make, especially if made incrementally, on the other hand conceptual changes are incredibly hard to make without replacing low level functionality with all the concomitant problems that brings, so it’s important to get this right at the beginning of the development process as it can be expensive to correct later on. However, if you don’t have that luxury, I’ve found that not only can concepts be retro-fitted to projects, but they can also be used in a somewhat ad-hoc way on small teams with limited resources; they aren’t all or nothing, they’re just another tool.

The Conceptual Design is the ground truth of your app, it is something that everyone who works on the app can look at to discover how the software is intended to be used. It will define how tasks are carried out in your application and, importantly, it will define what users are aware of; that is to say, if it isn't in the conceptual design, users generally shouldn't be aware of it.

Products that are designed in this way will be easier to use as the concepts will show developers how to pull complexity out of user facing workflows and into the architecture of the app, this is the key to jumping usability curves as developers can plan an appropriate architecture for specific ways of working, building these ideas into the very fabric of the software. In complex product design, generic architecture entrenches mediocre UX; specialist architecture affords exceptional UX.

Concepts need to be created with the input of the engineering team (either throughout or in a review stage) to avoid costly mistakes cropping up later in the development process. For example, if someone on the engineering team ever says "we didn't design it for that" the conceptual design is likely where it went wrong . The ideal is to come up with the bulk of the concepts before a single line of code is written.

It’s worth noting that if you don't create a conceptual design up front you're still going to have one as you literally can't have software without concepts, it's just that the developers will end up creating it as hoc in an uncodified way - a very quite route to mediocrity. Software with no central conceptual design is effectively unplanned, and using an unplanned approach for complex app design is one of the reasons why complex apps fail or become exponentially harder to use the more features you add because inconsistencies start to appear in the way the software is intended to be used versus the way it was built to be used. Conversely when adding features in a well planned app, increases in difficulty will barely be perceptible when existing concepts and actions are re-used. A user will be able to do more, without learning more.

The consequence of not actively planning a conceptual design, or not including engineers in this process is a likely rebuilding of your product after 1.0 has shipped (something I’m sure we’ve all seen happen many times), and, when an app is rebuilt and the same mistake is made again (lack of conceptual design or lack of engineering input into it) this can lead to the often fatal second-system effect where the rebuilt app is bloated and over-engineered. It’s just not worth the risk.

The concepts also effectively define what the UX will become because as well as being the basis for the product's architecture concepts are the seeds from which the UX will grow; designers need to steer that process, though once again for the people at the back, with input from the developers.

Think of it like building a house. The blueprints are the concepts, the foundations are the software architecture and the rooms are the features. It’s possible to build a house without blueprints but it simply won’t be as good.

You should also remember add to your list of concepts as your product grows, such as when new features are designed, or as new ways of working are sought, this is only natural in Agile and dynamic development environments.

 [1] Please note that these levels are not the same as those proscribed by Daniel Jackson, where the visual level is called the ‘physical’ level, and icons are part of the linguistic level.

As covered in detail in the guide, a concept in software design can be thought of as a mental shortcut (a heuristic) to perform a complex function or represent a complex idea in a simpler way. It can be anything from how data is presented to an encapsulation of UI elements.

An example of a concept is a folder in Finder/ Windows Explorer. The folder itself is a concept that represents a collection of files. These files aren’t actually stored together on a hard drive, they are just represented that way so as to make them easier to understand and use.