Embedded Files
This site is a work in progress. Last updated January 2023.
The crux of CxUX.
After user and task analysis is done, the first part of the app design process should aim to:
- Detail the operational principles of the app.
- Come up with a common vocabulary.
- Define objects, outcomes, actions and relationships.
- Align project stakeholders on all these things.
- Uncover hidden dependencies, duplications and contradictions in the app concept.
A conceptual model is a high-level description of how a system is organized and operates. It specifies and describes:
• the major design metaphors and analogies employed in the design, if any.
• the concepts the system exposes to users, including the task-domain data-objects users create and manipulate, their attributes, and the operations that can be performed on them.
• the relationships between these concepts.
• the mappings between the concepts and the task-domain the system is designed to support.
Johnson, Henderson 2002
• the major design metaphors and analogies employed in the design, if any.
• the concepts the system exposes to users, including the task-domain data-objects users create and manipulate, their attributes, and the operations that can be performed on them.
• the relationships between these concepts.
• the mappings between the concepts and the task-domain the system is designed to support.
Johnson, Henderson 2002
You may notice that this quote is 20 years old, that's because using a conceptual model as a way of approaching product design is not new, academics have been providing evidence of their efficacy for much of that period (see the links below), plus good UX practitioners may already be doing something similar without realising it, as once you understand it, it's a perfectly natural way to work. I have been designing software via this approach for over 5 years (after 5 years of using traditional UX methodologies), and it has significantly simplified the design process. Though my specialism is in professional/ complex app design, it's worth mentioning that in his exceptional book The Essence of Software, Daniel Jackson makes a hugely persuasive case for this style of product design to be used in all software, complex or not. Much of the next section assumed you're inventing an app from scratch, but we've discovered that concepts can be used to great effect in an ad-hoc manor, they can also be retro-fitted to old projects, and similarly, used for new features in old projects.The Conceptual Model is the ground truth of your app, it is a document that everyone who works on the app can look at to discover how the app 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 model, users probably shouldn't be aware of it. Products that are based on a CM will be easier to use as the model will show developers how to pull complexity out of user facing workflows and down into the architecture of the app, this is the key to jumping usability curves as the developers can plan an appropriate architecture for the specific way 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.Another reason the Conceptual Model needs to be created with the help of the engineering team is to avoid costly mistakes cropping up later in the development process. For example, if someone on the engineering team says "we didn't design it for that" the CM is where it went wrong. The idea is to come up with the CM - a description of the objects and actions in your app - before a single line of code is written. The developers can then plan an appropriate architecture for that way 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.You should also remember add to your CM 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. Doing this will also help you to realise when a new concept is really an already existing concept with a different use case (think labels and categories in GMail, oops), or when concepts are linked by hidden dependencies which is a common source of user confusion (consider the example of having photos in several photo albums, are they instances or copies; does changing one thing affect something the user may not necessarily expect?).
This seems like a a lot of work, is it really that important to have a CM?
This seems like a a lot of work, is it really that important to have a CM?
Remember: If you don't design the CM up front you're still going to have one as you literally can't have an app without concepts or a mental model, it's just that it's going to be made up as you go along and/or happen by accident. Apps with no central conceptual model are effectively unplanned, and using an unplanned approach to 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 app 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 are re-used. A user will be able to do more, without learning more.The CM also effectively defines what the UX will become because as well as being the basis for the product's architecture the Conceptual Model is the seed from which the UX will grow, and the designers need to steer that process, again, with input from the developers, rather then simply abandoning the CM for the developers to come up with, and as mentioned if they miss it, you end up with a 'default' conceptual model and mediocrity as standard. To stretch a metaphor for a moment; let's say we're going to boil some new potatoes, we have:
- New Potatoes (Features)
- Water (Architecture)
- Salt (UX)
- Boil the potatoes
- Drain them
- Add salt to the potatoes
- Add salt to the water
- Boil the potatoes
- Drain them
How to Write a Conceptual Model
How to Write a Conceptual Model
For an in-depth exploration of this topic, please read The Essence of Software, which explains this topic in far greater detail than I will do here, as I'll be presenting my preferred approach (which is all about asking yourself questions, and then answering them), there are many approaches, take what works, leave out what doesn't. If you feel overwhelmed, look at the examples, it's really not that bad, you'll get the hang of it.
To begin with start noting down the concepts of your app, each concept should have:
When creating concepts, here are some (slightly abstract) things to think about:
Then answer the following questions:How should users use your app? Consider the following:
Wait, what was that last one? A common source of confusion for users relates to the ability to instance or copy data in a product, so it's worth considering that in your CM. E.g:
To begin with start noting down the concepts of your app, each concept should have:
- A Purpose - a brief description of what it does.
- States - Can it be on/off, or inactive for example.
- Outcomes.
- Example use cases
- Operational principles
- How this concept should work.
- Default state.
- Rules of use.
- Actions - the kinds of things a user can do with the concept.
- Accessibility considerations.
- Safety / bad actor/ misuse considerations - is this concept open to abuse?
- Related concepts - to help lookups later.
- Notes - anything else worth noting, like why you went with this idea over another.
When creating concepts, here are some (slightly abstract) things to think about:
- What is related to what?
- What is a part of what?
- What can contain what?
- What can you do with what?
Then answer the following questions:How should users use your app? Consider the following:
- Undo/Redo (multiple steps/ single step)
- Saving/ Loading - should save files be human readable or even accessible?
- Drag and drop (what/where/inferred actions).
- Is saving automatic, or manual, or both?
- What platforms are you targeting?
- Do you need to consider extensibility?
- Is versioning relevant?
- What new words are you introducing to the user?
- Are you confusing instanced and copied data?
Wait, what was that last one? A common source of confusion for users relates to the ability to instance or copy data in a product, so it's worth considering that in your CM. E.g:
- Can notes be added to multiple tags?
- Can footage be added to multiple video timelines?
- Can photos be added to more then one album?
- Can a spreadsheet cell be referenced in multiple places?
- If a user then edit's something (e.g a photo, some imported data), can they restore it to the original?
- Design how you want the product to be used (the CM), before you design the product.
- Don't exclude the engineers when designing the CM, they can push a CM lightyears beyond what you would think is possible.
- Perform your user and task analysis early and certainly before you build anything.
- At this stage of the game, usefulness is far more important than usability.
- Try not to include any user interface details in your conceptual modal, details of organisation are fine (this will help inform the Information Architecture) but keep things like checkboxes and menus out.
- Verify your assumptions. If in doubt, do more user analysis.
To apply the lessons of previous designs, you need first to be able to extract design ideas as reusable fragments. That's what concepts aim to do.Jackson, 2022
Real world examples of concepts
Real world examples of concepts
These days we format our concepts as concept cards, I've seen people use diagrams, and others just use good old lists. The examples below are from Scene Group's Cavalry, a peice of animation software, and as live examples these concept cards are unpolished, that's just the reality of the real world (or so I like to tell myself). On a more serious note, the concepts are genuinely useful in this state, do as little or as much as works for you. Below these examples there is a screenshot and link to an academically complete example on the Concept Design Forum.Your concepts don't need to be this formal - the original CM I wrote for Cavalry was just a great stack of bullet point laden lists, it got tidied up later.
A perfect concept
A perfect concept
Here's a link to a perfect concept, if I had the time, Cavalry's concepts would be created just like this (I like to tell myself this as I fall asleep wallowing in my own incompetence). Click here to see the Upvote concept example.
Duplicate Concepts
Duplicate Concepts
One of the great advantages of conceptual models is that they will help you to spot if you try to add the same concept twice in two different guises. As mentioned above, GMail's labels, filters and categories are all the same idea in that they only really differ in use case. This is the elephant trap you can fall into if you work backwards from what the user is trying to achieve in order to arrive at a new feature required to achieve it. Working backwards like this is an absolutely a fantastic way to design software, but without a conceptual model duplications will happen.Another example of this exists on GitLab, a software planning and dev ops platform. On GitLab you can create issues and put them into an Iteration, a Milestone, and an Epic. These are all exactly the same concept (a category with a start and end date), but they all have different scopes (you make them in wildly different parts of the platform; Epics exist for all your projects, Milestones for just a single project - there is no reason for this) and the rules for using them are quite different (e.g exclusivity), and they have different visibility as an issues membership in one of these three roadmap items is indicated in different ways - Milestones are well indicated, Epics are essentially invisible. This has the side effect of making these features more trouble than they're worth. In the end we switched to Linear where products are elegantly organised using Cycles, Projects and Roadmaps. Three distinct concepts with entirely different operational principles that achieve the same purpose with a great deal more clarity.What does this look like when handled well? Apple used to have Label Colours on macOS, they were exclusive colours you could assign to a file or folder to help identify it. Decades after this feature was added, Apple decided to add Tags to macOS, these were coloured labels you could assign to a file or folder to help identify it. The difference? Tags could have custom names and they were non exclusive, other then that they were essentially the same concept. Apple realised this and instead of adding Tags as an additional feature, they expanded the Label Colour concept into a Tags concept. Ten points to Apple.
CMs and Wicked Problems
CMs and Wicked Problems
A wicked problem is a problem where failure is required as a scoping mechanism so that you can reassess and build it correctly next time, often the architecture of complex apps is a wicked problem and thus time for initial failure is needed. If it’s going to happen it’s going to happen, so it's best to minimise this risk by giving the developers a CM to work from; you want to fail as early in the process as possible, rather than just before you want to ship, or worse, just after you ship. If you ever hear of a software company completely rewriting their software between versions 1 and 2, it's quite possible the cause is that they didn't have a CM. We literally had this issue with the application Cavalry, the conceptual model holed the first architectural design below the waterline, the second design is still going strong 5 years in.
Can you retrofit a CM if your app has already launched?
Can you retrofit a CM if your app has already launched?
While it's obviously best to create the CM before any code is written (as discussed at length above), you can minimise the future damage of not working from a CM by creating one for an existing project. An easy way to start is to have new features be created with a Conceptual Model to guide them. You can also work backwards from the current state of the app to at least create concept cards for the key (or most used) objects and actions of the app. CMs do not need to be complete to be useful, they are just most useful when complete.
It's time to talk about some concrete tips, firstly, how to manage complexity.
Google Sites
Report abuse