Thought pieces on user experience, service design and information architecture

Menu

Tag Archives: Content Management

Component led design has become very popular recently. Responsive design is complex and it is understandable why alternative approaches focusing on components have become more popular. To be clear, I am an advocate of design systems.

However, at the end of the day this method of working is primarily a method for solving difficult internal problems that we face in design, development and content management. The end users of our digital products do not recognise the atoms, elements and molecules with which our design systems operate. Sure the user can benefit from a greater sense of consistency, but lets be realistic, users will not consciously operate at the component level when we have spent the last 25 years talking about “webpages”. It is this difference in mindsets and the familiarity with our design systems that I want to talk about.

We are experts in our design systems
So we have conducted the component audit, built the style guide and identified every element in our atomic design approach.

Your collaborative approach with the client means that their content production team are equally well versed in the new design approach. After three months of working on the project you and your client recognise every atom, element and molecule that you have crafted. The project is going well.

My concern is that the longer we work on a website (either in its design or post launch) the more expert we become in it. We remember all of the previous design decisions we have taken. We recognise that “Input Field Atom” that actually makes up the “Email Sign Up Molecule”. We know the CMS inside out and how we can mix and match components to make our desired outcomes. Ultimately, we can look at a page and we can quickly tell exactly how it is built.

We have become experts in our design system.

The problem with becoming an expert in something is that you find it that much harder to empathise with a novice. To look at something for the first time and understand what you are seeing. Let me use an example from the 1970’s to explain what I mean.

Expertise in Chess
In 1973 two psychologists called William Chase and Herbert Simon were conducting research at Carnegie-Mellon University on Perception in Chess. Specifically they were exploring what it was that expert Chess players saw that novices didn’t.

In essence their experiment went as follows:

They had various types of chess player ranging from “master” to “novice”

Each participant in the study was shown a chess position for five seconds. They were then given a board and a set of pieces and asked to recreate the position they had just seen.

Participants were judged on their ability to get as many of the chess pieces in their correct positions.

Some of the positions shown to participants were taken from actual chess games whilst other positions were complete random presentations of pieces on the board.

Figure 1: A position taken from an actual chess game

Figure 2: Chess pieces randomly placed on the board. This position is unlikely to occur in a real game

Chase and Simon took their results and compared the performance of “masters” with “novices”. What they found became one of the most famous studies in psychology around expertise and performance (this study is taught on most undergraduate psychology courses).

As you would expect, chess “masters” were better than “novices” at recalling positions. However this finding only applied for positions taken from real life games. When the results of the random board positions were compared between “masters” and “novices” there was little difference between the two groups in terms of memory recall.

Subsequent analysis showed that chess masters were able to use their extensive knowledge and memory of thousands of real world positions to effectively chunk up the chess boards they were shown in the study. For example, a castled king position is a very common position in chess involving a king and rook with three pawns in front of them (see figure below)

Figure 3: What a “master” sees as one component a “novice” sees as five

It was proposed that chess “masters” would see the castled king position as one group whilst novices would see up to five pieces. The more expert a chess player then the greater likelihood of them recognising a configuration of pieces and being able to recall them easier.

Therefore, when the random chess positions were shown a masters expertise was effectively nullified as they were thrown back onto the resources of the short term memory, just like the novice group.

Stepping back from our expertise
Although not a direct comparison with the world of component based web design, I have thought about this famous psychology study several times in recent months and the impact that expertise has upon our perception of a configuration of components.

Specifically, expertise in our design systems means that we can recognise every component so quickly that of course the page looks good to us when we just to add a few more components. A type of “wood for the trees” syndrome can take effect.

Responsive design systems are by their very nature complex. However, we must never forget that a complex arrangement of components can appear simple to us because by our very nature we are experts in that system.

Put yourself in the shoes of the user, the “novice” in my analogy. They are seeing the board for the first time and they are not certain where all the pieces go or what they do. Maybe the board has been set up nicely for them but then again maybe its a horribly complex position that only a “master” could understand.

Component led design has many benefits to us as a community. But as I stated at the beginning, these benefits are primarily internal to our design, development and content processes.

As we embrace this more flexible yet potentially more complex way of working we must ensure that this added complexity does not shine through into our final configurations.

Our design teams and content producers (especially them!) must remember to take the time to step back and look at the bigger picture at the page level. As the diagram in figure 4 shows (and what I was getting in an earlier post from 2013), there are good and bad ways of combining elements to create either complexity or simplicity (taken from 101 Things I learnt in Architecture School).

Figure 4: Combining elements to make complex and simple shapes

Whilst component based design systems are providing us with a lot of value internally, we must ensure that our final external facing configuration of components is not random or complex but familiar and uncluttered. Only then can we ensure that we are giving our users a playable position to start from.

Design systems have recently been a major talking point in my office and the wider web industry. Whilst not an entirely new idea, the growth in interest in design systems carries a lot of merit and is a direct consequence, in my opinion, of the responsive design and content first movements.

One recent example of the design system way of thinking has been Brad Frost’s term Atomic Web Design. Brad identified five distinct levels in his atomic web design approach:

Atoms: Basic building blocks of our sites such as HTML tags;

Molecules: A combination of two atoms such as a form label, a field and a button forming a search box;

Organisms: Groups of molecules joined together to form a complex distinct part of an interface such as a product listing

Templates: These are concrete examples and groups of the above three items. They are typically where we start to see a design come together.

Pages: These are specific instances of templates and the most tangible to a user.

There is no doubting that thinking in a more granular / component based, system led approach rather than the “page” is excellent during the design phase of a website. Its excellent for the design team and the client to think in such a way as it enables a consistency of experience, optimisation of elements to be built (why have three carousels when one will do?) and a rationalisation of final templates.

My problem is the end user does not always think like this.

Wayfinding – Paths, Edges, Districts, Nodes and Landmarks

Since the dawn of the web we have called them “web pages” and told the public just as much. Even if as an industry we actually successfully managed to kill the page metaphor (“Kill the page” or “Content only, no navigation” have been two phrases I’ve seen banded around lately) people will still routinely attempt to locate themselves to a “place” within a digital product i.e. “Where am I?”.

The work of the architect Kevin Lynch in the 1950’s identified a number of methods that people have evolved for navigating around cities. These are as follows:

Paths: These are the channels along which people move within the city. For example streets or footpaths.

Edges: These are boundaries between two places or regions. They help users group together general areas. For example, a large river bounding a park.

Districts: These are medium to large sections of a city. They will have recognisable character traits and be used as reference points.

Nodes: These are strategic points which are the focus of directions of travel. For example, crossings or two paths that converge.

Landmarks: This is a point of reference that a person cannot typically enter but can enable orientation because it can be seen from a distance. For example, a tall building or mountain.

My own experience has shown me that people routinely see themselves as being in a specific place and often adopt some of these wayfinding techniques to move around within a product or service.

Navigating the bigger picture
What i’m proposing is that particular design components (particularly at the “molecule” and “organism” level of Brad’s atomic distinctions) can be used by customers to orientate themselves within the website i.e. they can act as individual “paths”, “districts”, “nodes” or even “landmarks” in Kevin Lynch’s world.

However, when this happens customers are actually orienting themselves around these components within the context of the bigger picture i.e. the entire site. This is the reason why I feel we must be careful.

In my opinion, customers of a website will never think at the atomic / component levels that we as designers may operate. We may create incredibly flexible design systems featuring interlocking “atoms”, “molecules”, and “organisms” but it is still at the “page” level that we must ensure the site works for customers as this is the predominant metaphor in which they will be operating.

If we are too liberal or flexible in the application of our design systems then, in my opinion, we risk creating serious problems with wayfinding and orientation through homogenisation, repetition or misuse of elements.

Where lies the danger?

My concern with the design system approach is actually not during the design phase. My concern rests with post delivery when the client and subsequent teams of content authors inherit the new site.

Whilst the intelligent content management of a design system can utilise “atoms”, “molecules” and “organisms” to act as Lynch’s “paths”, “nodes” and “landmarks”; they can also be applied in such a ubiquitous and haphazard manner as to render them detrimental to the overall experience.

If a potential major strength of design systems is too aid digital wayfinding through consistency and orientation then, potentially, it is also one of their greatest weaknesses.

Therefore, my intent is to raise the concern that when creating our design systems we have to give serious thought to how and by whom they will be used after delivery.

Gestalt architecture

In writing this article I have found myself finding many parallels to architecture. The way that we design a building can have long lasting consequences for the way that it is inhabited. Both are essential life stages of the building.

Matthew Frederick (2007) wrote an excellent little book called 101 things I learned in Architecture School . I recommend every UX designer read it and absorb the parallels to our profession. One lesson in particular resonates with my point:

Create architectural richness through informed simplicity or an interaction of simples rather than through unnecessarily busy agglomerations.

Matthew goes on to provide some examples of unnecessary complexity in architecture, in particularly he states to avoid:

Agglomerating many unrelated elements without concern for their unity because they are interesting in themselves.

His accompanying diagram couldn’t resonate with this blog post more. Thank you for reading.

Three levels of knowing: Simplicity, Complexity and Informed Simplicity

Thanks for reading!

If you enjoyed what you read then please do share it, I’m always appreciative of the support. You can also follow me on Twitter here.