Their aim is to formalise practises of addressing gaps or overlaps in technology and process. But these practises can come with significant overhead, and they’re not always appropriate for every scale or type of organisation.
In mathematics, a topology refers to the arrangement and relationship of constituent parts. A 3D model, for instance, has a topology that describes all its points and how they are arranged in relation to each other. And a good 3D model contains neither gaps nor overlaps.
Rather than uncritically adopting these processes off the shelf, we can analyse the topologies within our individual organisations and use this information to design solutions that suit our own specific requirements.
Some familiar stories
I’d like to begin by telling some stories. I suspect they may be familiar to many of you...
You’ve completed a relaunch based on thorough UX design, testing, and extensive iteration. But when the updates go live, users are confused, and sales goals start going off target.
Or how about this one...
You’ve spent a long time designing your new website, with a clear information hierarchy and strong branding. You’ve even produced a design system, complete with a pattern library demonstrating page templates and clear guidelines on their use. But when the website finally launches after many delays, it doesn’t really look like the designs that had been produced, or the templates on the pattern library, or the guidelines in the design system. Content is lacking, things seems out of place, and nothing holds together quite as well as the designs had done.
So how does this happen, even when everyone is working to the best of their ability, and you’ve implemented all the latest processes and tools?
Processes
We are all humans, working together, using our expertise to solve problems that no individual, no matter how smart or hard working, could solve alone. Many of the complex tasks we perform to achieve our goals involve repeated processes in one form or another. Repeated processes benefit from being broken down into smaller, more manageable units. And this can increase efficiency.
This insight originated in the industrial revolution, and became increasingly popular over the course of the early 20th century. It led to the growth of scientific management based systems like Taylorism and Fordism. While successful, they were also dehumanising and some of their fundamental principles, such as "the worker is lazy and untrustworthy," and "strict hierarchy is an absolute necessity" still find echoes in our workplaces to this day.
Categories
Breaking anything down, whether it be a process, an output, or an organisation, involves categorisation. Categorisation, by its nature, creates boundaries. These boundaries can then impose artificial limitations, depending on our frame of reference. These artificial limitations can be the source of much hidden tension and complexity.
There has been a lot written on how to ensure that we are categorising, structuring, and naming things correctly. But there is much less discussion about what gets hidden by these categories, and the impact this can have. The end result of our attempts to work together efficiently by breaking things down is that the topologies of our workplaces are left with gaps and overlaps.
Gaps and overlaps
Gaps are where hidden complexity live. If we don’t have a category to cover it, in effect it becomes invisible. But that doesn’t mean it’s not there. Unidentified gaps cause inconsistency and confusion.
Overlaps occur when two separate categories encompass some of the same areas of responsibility. They cause conflict, duplication of effort, and unnecessary friction.
These gaps and overlaps are often responsible for undesirable outcomes that occur despite our very best efforts.
The good news is, we can learn how to spot them.
The stories I told earlier sound like distinct problems, but topologically they share many features.
Gaps and overlaps exist at every scale. To help you to identify them, I’ll go through some examples, starting at the smaller end of the scale.
Pattern libraries
We build pattern libraries to help modularise the delivery of front-end code. But we design for user need. When we consider user needs, we consider the whole user journey, and the whole context. To achieve the benefits of component based design, we must break that “whole” down. In doing so, we lose some of that context.
Now we have all these flexible components that can be put together in almost any way. But they still need to remain coherent in different configurations. This becomes difficult when a component is generated by a Content Management System and can have almost any context. There are an almost infinite number of ways that a component can be placed together on a page with other components.
How do you design for infinity?
Since we can’t anticipate every possible combination, what we can do is recognise the fact that we have broken something down in order to categorise it, and therefore there may be gaps ...in this case, literally.
We can design a consistent system of spacing and layout to control how items are placed in relation to one another, and the parts become whole again.
Design systems
Moving up in scale, a pattern library is one aspect of a design system. We create design systems to allow our organisation the benefit in speed, lower cost of change, and resilience that is created by having a single source of truth.
It is a distinct entity, but to produce a design system requires collective effort. So we divide responsibility along the lines of UX, design, front end development, content, etc.
A design system must also fulfil different requirements for different end-users. Developers might need to know what components are available. Content creators need to know what the organisation’s tone of voice is. And so it suffers the same consequences of anything subject to categorisation, with apparent divisions of responsibility that hide overlaps and potential areas of conflict or duplication of work.
We might see places where developers must recreate in code what designers have already created in their design tools. Static design tools like Sketch have no way to highlight when interactions (like hover states) are missing, so we can easily end up with incomplete specifications—gaps—where interactions are not considered.
We might also see gaps when front-end developers don’t provide enough documentation for back-end developers to implement something effectively.
At this scale, by recognising and addressing the gaps and overlaps that have been created, before issues are uncovered, we can prevent excessive cycles of iteration from occurring as gaps are uncovered one by one.
There are many different ways to repair this topology, and they will look different for every design system. But here are a few...
Choose tools that more accurately reflect the nature of the medium we work in—that bridge the gap between design and development. Tools like FramerX hold a lot of promise for the future of design and development collaboration.
Adopt techniques for helping people work together,like Lean or Agile, that encourage collaboration through close and frequent communication. Making sure all key team members are involved as early and frequently as possible also helps.
Organisations
Moving up in scale once again, a design system sits within an organisation.
For shared understanding and efficient division of labour we separate ourselves into teams and departments. At a certain level, these groupings are arbitrary. They’ve largely emerged from historical convention. They can also be influenced by emerging conventions and cargo-cult trends. Where these divisions do not accurately support the work to be done, it can be a source of tension within an organisation.
In cases where teams have overlapping boundaries of responsibility, and if the organisation is unbalanced—favouring one department over another—then the end result will not reflect the goals of the organisation as a whole.
If there are gaps in skillsets, the organisation will simply struggle to achieve its goals.
By encouraging everyone to balance their own goals and perspectives with the organisation’s and with other teams’, we can help people work across silos effectively.
We can aim to create “an environment where reciprocity is the norm”. In the words of Heidi Gardner, author of Smart Collaboration:
Are we developing a coherent joined-up solution that’s really going to address this problem? Or are we just slicing off parts of it that we’re comfortable solving which won’t actually make the problem go away.
Culture building takes time and effort, but in the long run, it is a lot more sustainable than replacing a burnt-out team.
Validating your topology
So topology is a simple but powerful concept. It can apply at any scale, and there are five steps.
Focus on the overall context
The overall context might be a page design, a long-term goal, or the structure of your organisation.
It’s easy in our day-to-day work to get caught up in the specifics of our tasks and the divisions of responsibility. It’s important to step back regularly andremind ourselves of the bigger picture.
Recognise that categories are subject to distorting pressures
Historical precedent can push us into uncomfortable positions. The pressure of time is an ever-present factor in our decisions,pressuring us to choose the quick option—the path of least resistance—rather than the best option. It’s important to ask ourselves why we make the categorisations we do—why we’ve chosen a particular framework, or divided our teams in a particular way—to ensure that we are working towards our goals in the ways that fit us best.
Recognise that categories hide context
Every time we make a choice to divide something up to better fit a division of labour, we lose context (like the context lost with component-based design). Keeping track of what we have categorised and how we have categorised it allows us to spot opportunities to fill gaps.
Recognise that categories create potential areas of conflict
Every time we divide something up to better fit a division of labour, we risk overlap of responsibility.
Marketing and development are typically both responsible for the content on a webpage. But they come into conflict when the marketing team wants more scripts to understand users, and the development team wants fewer scripts, to improve performance for users.
Being aware of these areas of overlap, and keeping our overall context in mind, allows us to engage in dialogue, or create rules or processes to follow, in order to prioritise what should happen when conflicts do arise.
Determine whether a given problem requires a technology, process, or people -based solution
Recognising the gaps and overlaps is only half the battle. If we apply tools to a people problem, we will only end up moving the problem somewhere else.
Some issues can be solved with better tools or better processes. In most of our workplaces, we tend to reach for tools and processes by default, because they feel easier to implement. But as often as not, it’s not a technology problem. It’s a people problem. And the solution actually involves communication skills, or effective dialogue.
Maintaining an equal balance between all three—technology, process, and people—and understanding when each approach is the most appropriate solution, is critical.
While the concept is simple, applying these ideas can appear challenging. But I believe that exercising our creativity and judgement to improve our work lives on our own terms, rather than allowing it to be dictated by convention or the path of least resistance, is worth the effort!
