This post is about gaps.
I think gaps are where most of the interesting design challenges are lurking, particularly if you’re interested in information architecture.
Information architecture is fundamentally interested in gaps — gaps between problems and solutions, between products and audiences, between perfection and pragmatism.
Gaps invite us to think about the differences that cause them and the connections that might bridge them.
Gaps keep us in a job.
This article is about a way to describe and explore experiences — particularly the transitions or gaps that occur between moments in an experience.
But gaps aren’t the only things that matter.
I like to think of information architecture as the science of separation, the art of connection and the technology of pointing. The gaps do matter, but only because they’re the space between things — and if we’re honest, the ‘things’ usually get most of the attention.
Information architects are fascinated by ‘things’ and are preoccupied by considering their parts. We analyse and understand the properties of a thing so that we can describe its essence. We’re critically interested in simplification. We strive to make complex things more meaningful. So often we break complex things up into smaller, simpler parts. We simplify and separate. We build gaps.
But although there’s this necessary commitment to reduction of complexity, I don’t think information architecture is a fundamentally reductive activity. Information architecture sets a template for the strategic construction of things. We build stuff — we make places out of information. So, as much as we separate things, we also connect things. We find similarity between and within the classes of things we’ve identified. We find and form connections.
Once we’ve identified connections we devise and design ways to exploit these connections. Whether we’re designing digital navigation or coherent cross-channel experience, we focus on links. Links often depend on pointing at things — whether we do that with wayfinding aids or technologies that take you somewhere — like the hyperlink.
This is what an IA does — we simplify, separate and connect things, identifying the ‘stuff’ we can build places out of, building and bridging gaps and making experiences meaningful. We create places that users can explore and which can be the setting for meaningful experiences.
IA is the science of separation, the art of connection and the application of the technologies of pointing.
The most effective IAs don’t just consider the places they’re making, they also consider and design the spaces between the places.
The space between
So we design places with an understanding that there will always be gaps between the parts of the whole, and that it’s out job to identify where and when these gaps need bridging. But there are other gaps that we care about too.
There are always spaces between the places we make. There are always gaps between our intended design and the first iteration. There are always gaps between our vision and the way colleagues and stakeholders might imagine a design.
No matter how good a design is, it’s never really finished. There are always gaps between what we release and what it will become.
With any piece of information architecture, the implications of our decisions ripple across the whole experience. IA defines the shapes that can appear in the interface. It feeds back into the strategy for future ideas, iterations and innovations. IA controls and curtails opportunities — it reaches into the future and defines what’s possible. IA travels in time.
This is one reason that when you’re designing information architecture (or really any type of UX design) you need to make sure that you’ve got the buy-in of the organisation. You need to have seeded an understanding of the implications of your IA approach, alongside the tangible things you build.
So how do we do that? I’m going to describe one way — Trajectories. It’s a design and storytelling technique that should help you design better experience by bridging gaps — whether they’re between team members during the design process, between iterations of a design as it evolves or within individual designed experiences.
What’s a trajectory?
A trajectory is the path that a moving object follows through space as a function of time.
It’s also a line. It has a beginning, middle and end.
It’s a type of story.
IAs tend to spend a lot of time thinking about space. Information architecture is preoccupied by the spaces and structures that our design implies. But TIME is just as important as space. Information architecture underpins experiences, and experiences happen in time. If you only ever present your IA as a static structure, you’re underplaying the power of your design.
IA is built to be experienced, so you need to find ways to communicate the impact that your IA will have on the temporal and sequential nature of the experiences it will contain.
Architectures also evolve in time. It’s an extra dimension we need to keep in mind as we design. So whether we’re describing a user experience within our architecture, or the evolution of an information architecture between design iterations, time is just as important to an IA as space.
A trajectory might look like a simple line — and it is. But a simple line can be a very powerful tool.
Trajectories are a way of focusing your attention on the temporal nature of experiences. At their most basic, a trajectory is just a line that describes a path through an experience or information architecture. It’s a visual way to describe a user journey.
Their power lies in their ability to focus your attention on any ‘moment’ or point along that line, as well as the continuity of the line as a whole.
As we design experiences, it can be tempting to tell stories in rapid cuts — as if all user experiences are really unfilmed music videos. Whenever you hear a sentence that begins ‘and then the user…’ think about how well the sentence is connected to the one that preceded it and the one that follows. This kind of storytelling can sometimes suspend the ‘user’ in a mythical hinterland where the motivation or context for their understanding and action has not been thought through. Storyboards are a great way to describe experiences. But sometimes the secrets of a design are lost in the gutter between the cells.
Something as simple as drawing a line allows you to trace the path of that action forwards and backwards to determine the motivation for the action, as well as the trajectory that the action suggests. A line has continuity — it’s connected. You can still describe the spaces, both between places and times, but a line encourages you to imagine the coherence and possible connections between the gaps.
Design is about telling the story of a world that could exist and then devising ways to develop that story and make it reality. I think telling stories is at the heart of iterating and sharing design including information architecture.
Every design decision has consequences, whether you build a dominant organisational paradigm based on taxonomy, or you focus on modelling domains and assume connections will be formed organically, for you… there are always consequences
Trajectories can be used to reflect on the direction that you’re travelling in, explore other directions, judge the energy needed to connect the elements of your designs. It’s a tool that can be used to judge a design, as well as the processes that will be required to realise a design.
What’s the trajectory of the information architecture you create — how is it transformed from an idea into a reality?
Stories, whether you use trajectories or not, are another abstraction you can use to zoom out and judge your design. They’re probably the cheapest way of seeding a culture and developing a shared ubiquitous language.
This is a trajectory.
But it’s not a particularly useful one.
No matter how much I love diagrams, I’ve learned that they’re never as effective as a person explaining an idea. This trajectory is pretty useless. Even if you add some annotation (always a useful addition to a trajectory or any form of diagram) it will still be limited in effectiveness. But trajectories can be brought to life, they can be ‘animated’ by telling the story of the path that the trajectory describes.
Imagine me running my finger along the line, describing the purpose of the curves. Trajectories can be used to document a design, but I don’t think that’s where they’re most useful.
Trajectories are most effective when they’re more than just a line — they should be the basis for a design conversation.
Think of the line as a path that your conversation might follow as it describes an experience. When you need to deviate from the path you’ve imagined, that reveals something about the design — work hard to make the implicit assumptions baked into the abstract trajectory clear.
A trajectory line can describe any aspect of an experience as it occurs in time. As with any 2 dimensional line, you have access to a couple of axes.
‘X’ is usually time.
But we don’t have to use the Y axis to describe a movement through space. It could be a measure of attention or engagement. It could be used to denote a user moving between different contexts or technologies or platforms. Or it could mean nothing at all. You might not even have two axes, a trajectory might snake its way through a domain model, bringing to life the relationships, connections and properties that stand between objects and entities.
Some examples
The best kind of trajectories are hand drawn. I don’t think you should try too hard for perfection. Trajectories prompt questions and discussion. Make sure they’re not misleading. But if there’s a break in the line, or you make a mistake, don’t worry too much. The discussion that they prompt is where the real value lies.
The intersection of different journeys and the variation in experiences is easily noted using trajectories.
Seeing these two trajectories reminds me of the graphs I sometimes see on my iPhone after I return from a bike ride. The phone detects gradient and plots it against my speed. Seeing how going up hill slows me down is not a huge surprise. But using trajectories to explore the effects of the features of your experiences is a powerful tool, and usually leads to insights.
You might not need to use curving lines. You can use trajectories to show movement through different devices or platforms. They’re a powerful tool for describing cross-channel experiences. I’ve used variations in contextual studies to show how editorial workflows are dependent on multiple tools and processes.
The designed experience.
We’ve found it helpful to think about three types of trajectory.
One is the designed experience.
Whenever you’re designing something, there’s an optimal path through the thing you create. We’ve all sat at a desk imaging a sunny day when everything goes right and the user flows through the experience in exactly the way we always imagined.
This is the ideal, designed experience. I suspect it doesn’t exist.
Experience designers don’t really design experiences. We design the stimulus with which our audiences create experiences. Experiences are alway unique. A user will always contribute something to the equation of the experience — they always bring something. Most trajectories are a line, but I think it’s a good idea to make the line that describes this ‘designed experience’ a little fatter than the others.
We should always be designing resilience into the ‘experiences’ we give to users and audiences. I like to describe this tolerance in the trajectories I design.
If I know that there’ll be different levels of familiarity with an interface, I might describe a bulge in the trajectory at this point. This allows me to describe that although there are different levels of competency in my users, I’ve designed for this range. It also allows me to describe what might fall outside of the range of the designed experience. This will prompt consideration and often discussion as you tell the story of the design.
Is there enough tolerance in the design? Is there too much?
The trajectory of the designed experience describes the range of different user experience that your design is capable of supporting. It can also be used to denote the boundaries at which you have accepted the fact that the experience might fail or break down — which in turn can be used to design measures to pull individuals back on track.
The individual trajectory.
Every user will have their own ‘individual experience’ of the design you’ve provided.
If you’ve designed tolerance within your product or service the second type of trajectory will hopefully lie somewhere within the region of the designed experience.
This second type of trajectory describes the path that an actual person might take through the experience.
Because we acknowledge that each user will have their own experience, we can describe multiple individual trajectories for the same designed experience. This is one of the most powerful tools that trajectories give us. It allows us to think about the different ways that the stimulus of our design can be interpreted and used by different individuals.
Information architecture often makes me think about the ‘Choose your own adventure’ books that I read as a child. These books have multiple narratives running simultaneously within the same book. At the bottom of key pages the reader is given a choice, “To go in the cave go to page 42, to run away go to page 66.’ I like to think of information architecture as providing the same kinds of structure.
The structure remains the same. The choices that each individual user can experience differ. They’re still usually based on an acceptable range of responses for each individual choice we offer, but the user is mainly responsible for making the experience meaningful, based on the stimulus we provide.
Thinking in these terms allows us to focus on a broader range of supported experience, expanding outward from the ‘designed experience’ to explore the ‘individual experience’ in more depth and richness.
The historical trajectory.
The historical trajectory is the story that participants will be able to tell about the experience that they’ve had.
All experiences create social and historical artefacts. It might be memories of the experience or it might even be physical artefacts. It might even be a social share that they create to pull people into having a version of the experience for themselves.
It’s important to consider the historical trajectory for a number of reasons. After an experience is over, the historical trajectory is all that the user is left with, so if you want the experience to remain meaningful and shareable it’s important that at least some elements can be remembered and described.
Thinking about the description that a user could give at the end of an experience is often a good way to identify possible points of confusion or pain.
Transitions
So, three kinds of lines to describe designed experiences — is that it?
Well, kind of.
But within any story there are punctuation points — chapters, sections, pages. The same is true of all experiences. Experiences are made up of parts and in the language of Trajectories the gaps betweens the parts are called transitions.
Transitions are points in your experience where you need to pay the most attention. They mark points at which there might be a change of direction or where the continuity of the experience you’re describing is in jeopardy.
These are the moments of risk and reward for a designer. And because they represent both risks and opportunities, it’s important to understand them.
Information architects know the importance of naming things. Giving something a name helps you to recognise things of the same type. So I’ll describe a few different types of transition that it’s useful to think about, and give each one a name.
If you’re successful in adopting and seeding Trajectories as a way to explore user experiences in your organisation, you should find that these Transitions become a checklist or a set of heuristics that anyone can use to investigate and analyse the success of a design or experience.
Beginnings
Beginnings provide context and help us describe the motivation of the user.
Considering beginnings can help you to explore whether your ‘designed experience’ reaches back far enough. How do people enter or begin their experience with you? What are the foundations you’re building on?
Thinking about beginnings will also encourage you to consider the range of routes into a designed experience. Where do your users come from? Do you prefer any particular inbound referrer or source?
Could you enhance the entire experience by reconsidering where and what you consider as the beginning?
Types of things you might learn by thinking about beginnings:
– Does the user have all the information they need to take the first required action in the experience?
– How might you enhance the motivation of the user at this stage to ensure the experience begins?
– Is the required first action obvious across the full range of ‘beginnings’?
Roles
People play different roles during experiences. Recognising the roles we want users to adopt, as well as the roles they might just ‘fall into’ will help you to design better experiences.
Search behaviour is one good example of the way a users intention and motivation might shift throughout an experience. At times users might be tightly focused on finding a specific item or resource — you might describe this role as ‘motivated and informed seeker’ — they know what they want, they just don’t know where it is. At other times the same user might be looking for distraction and be open to browsing — this ‘curious browser’ would probably appreciate different features and functionality than when they inhabited the other role.
Another example of role might be ‘beginner’, ‘intermediate’ and ‘expert’ users. They all experience the same stimulus, but they are likely to perceive and use the affordance you provide very differently.
Role is one of the most fundamental aspects contributing the context that your experience will take place in.
I like to think that good design and information architecture can orchestrate experiences. By considering the roles that a user might shift between, and the optimal roles required to deliver delightful experiences, we’ve got more information and inspiration to nudge users into the desired states and mindsets.
Consider devising a controlled vocabulary of roles that a user might inhabit during their experience.
Interface
The interface is the means by which we meaningfully communicate with our audience.
An interface could be any means of communication — the user interface of a website, app or other digital product. It could be physical signs or way-finding devices, printed instructions or just the language we use when we talk to them.
Is the same interface appropriate throughout the whole trajectory and experience?
There are times when changes to the interface can have a profound effect. When we think about immersion and optimising experiences for engagement we’ll often want to make the interface as invisible as possible — maybe the content and the functional interface are fused together. Maybe the interface disappears when it’s not needed — think of most video players — but is easily recalled when required.
The interface will often be how you manifest the ‘giver of the experience’ to the user. There will often be a bond of trust, so interfaces should be meaningful and reliable. But they needn’t remain static. Considering how an interface might react to different contexts, devices or user needs might unlock otherwise unseen potential.
If you’re designing cross-channel experiences you might also want to consider how your interfaces complement each other. How will you support switching between interfaces to ensure that your experiences have coherence and continuity as well as flexibility and resilience.
Language is an interface. Clarifying and controlling the terms you use as you design your experience will make the process easier and more meaningful.
Sessions or temporal episodes
Information architects are preoccupied with the spaces we create using information and classification, but time is arguably the more important feature of experience design.
Experiences happen in time. Experiences have duration and sometimes they can even be spread over multiple episodes or sessions. Considering how your design responds to this will always result in a more resilient and meaningful design.
Does each session mark a new beginning? How might this beginning differ for each episode? Why will an episode or session end? How might you prolong it? How might you encourage a new session to begin?
Asking these questions will reveal opportunities and challenges. But thinking about the answers will ensure that your designs reflect the actual flow of real experiences. Experiences are often interrupted, and they always occur over time. Always consider time and the evolution of the experiences you’re designing.
Consider the impact on the user experience of beginning a ‘journey’ at different points.
In the old days we’d construct a structure imagining a journey would flow from A to B. But search engines enable users to jump into journeys right in the middle of the A to B routes. More complex models place beginnings at many different points. What sort of beginnings does your UX need to support?
Using the transitions discussed so far.
Some experiences might require a user to switch role or mindset. How could you support a user to transition between active and passive states? How might you define and support multiple roles?
Experiences can stretch across sessions. How might you enhance an experience by making it easier to pick up where you left off?
Sometimes a user might switch interfaces. Think about how Google Chromecast asks a user to split their focus while they move from one device to another. The experience can be satisfying, but the seam between the interfaces needs to be considered.
Switching domains
In the original conception of trajectories there was a transition called ‘physical/virtual traversals’. It encourages designers to consider the important transition that occurs when someone switches from a virtual interface and digital experience into one rooted in the real world.
This is still a useful focus, particularly when you’re considering how you might augment real-word experiences with digital enhancements, the transition between the digital and the real-world domain is a seam that should be considered in the design.
However, I think for most information architects we can extend our focus to consider any switching between domains — whether this is a virtual/physical traversal or moving between differently oriented information architectures.
Even within entirely virtual experiences we can move users and audiences through different domains and sections. There might be continuity in the interface and temporal episode, but the underpinning architecture of the ‘space’ they inhabit can shift.
Consider the points at which a user might leave one domain and enter another — this might signal a new beginning or a shift in role too. But there will definitely be opportunity to make the transition smoother and more motivated and meaningful for the user.
Access to resources
Where your design or experience is predicated on the assumption of access to a set of physical resources, identifying this dependency is hugely important. Any core dependency that your experience rests upon should be identified and understood. But it’s likely that there are points in your Trajectory or experience where progress is entirely dependent on this access. Think of these moments as gate points beyond which the experience or design cannot proceed unless the necessary resource is in place.
Access to physical resources provides a chance to consider where scarcity might be an issue. For example, ‘moderating comments’ might not always be considered a physical resource. But if we’re not able to support ‘user commenting’ fully, experiences and products could be undermined.
Considering this type of transition should help you to design more resilient experiences. What redundancy could you design into the experience to increase resilience? What alternative resources might be able to serve the function once the optimal design is compromised?
Seams
Seams describe any other type of weak points in technology. Of course, language is a technology. You can consider a broad range of seams when you design an experience.
Considering the technical barriers that could undermine an experience is vital whenever you design or deliver an experience.
Caching and off-line access to content is an obvious example of where considering seams can help ensure that participants remain inside our optimal designed experiences.
Seams are points of weakness. Rips can occur when you haven’t tightly coupled the sides of a seam, so designing for seams is really a case of designing for resilience. What’s the most efficient way you might bridge a point of weakness in your design? What error messages might you provide when everything goes wrong and the user or audience does find a point at which the experience breaks down?
Encounters
Considering the social aspect of the experience you’re designing will enhance any experience.
Lots of experiences are social, and even when a user experiences a design in isolation, there might be multiple users experiencing the same space or domain at any one time.
How many concurrent users is the right number? How might you support asynchronous cohorts? What is the social aspect of your design?
‘Encounters’ can encompass other types of thinking too. How might the isolation of a user enhance or detract from an experience? How could you use pacing to bring different users into contact or avoid encounters?
Encounters allow you to focus on the inherently social aspect of any experience design — this can extend your attention to consider the social aspect of design. What are the social interactions you need to consider as you design?
Endings
Most experiences come to an end — for example, we’re now at the end of this list.
Considering the ending of experiences will help you create better experiences. If you know the ending that each user or audience member should reach, you have a quantified point you can use to judge whether your design or experience has been a success.
Designing ‘Endings’ help you to consider the historical trajectory that a user will emerge with from the experience. What do they have at the end of the experience? Can they use this to share the experience or shape the future behaviour?
Ubiquitous language
A ubiquitous, shared language is the most powerful tool any organisation or design team can develop. Eric Evans stresses the importance of discovering and developing a shared language in software development teams, through domain driven design. Information architects stress the importance of creating and facilitating shared meaning through ontology.
Design deals in uncertainty, it’s an unavoidable consequence of any design endeavour.
But designers, and IAs in particular have a responsibility to build meaning and trust through the processes they follow. Trajectories and the language of transitions are one way to explore meaning and standardise language.
But they’re not magic.
Stories only exist while they’re being told. Language only has meaning while it’s being shared or used. This article provides a quick overview of some of the ideas I’ve had around Trajectories. But I encourage you to experiment, develop and share your own approaches to using these ideas as you design. I also urge you to develop a shared language you can use with your stakeholders and colleagues to describe the experiences you design. This doesn’t mean developing or endorsing jargon. It’s more about precison and welcoming the question ‘what does that mean’. So if anything about trajectories or transitions remains unclear, please let me know.
Leave a Reply