Conceptual Burden
This characteristic breaks down into three major considerations.
Visualisations of the Conceptual Gradient and the Concept Barrier make great additions to a UX dashboard.
Conceptual Gradient​
This is your software's learning curve, you may never have plotted this, you may not even have known it was possible, well, it is, and it's very simple. This is a line to test against, do simple tasks only require dealing with simple concepts? And as tasks get progressively more complex, are progressively more complex concepts required? Things are bad when simple tasks require users to know about complex concepts.
Testing the Conceptual Gradient​
Note some random workflows from your app, from the most basic, getting progressively more complex, until you reach a workflow that's several minutes long.
Next, count the concepts involved in doing this workflow. The workflows go on the x-axis, simple to complex, and the number of concepts involved in each workflow is the y-axis. Here's the trick, give simple concepts a weight of 1, and complex concepts a weight of 3.
A Concept is simply 'an idea a user needs to be aware of'. Like a layer, brush, tool palette, window, keyframe, swatch, artboard, mode, button and so on.
Once you've done this, you can then plot the results, congratulations 🎉. You can now check the graph for irregularities, or spikes, and consider how you might be able to remedy these.
Concept Barrier​
The barrier for entry. This is the threshold of complexity that a user must overcome to effectively use your software. You should evaluate if the minimal set of concepts required to use the software is intuitive enough for new users or if it presents a significant amount of learning. This is very similar to mapping the Conceptual Gradient, only targeted at just the workflows novices will encounter.
Testing the Concept Barrier​
This is very similar to working out the Conceptual Gradient, however you should pick half a dozen of the most simple workflows and count the concepts involved in each of them. Next you can discount any concept if it is one a user will already be familiar with from elsewhere, or is your software introducing an entirely new set of concepts a user must learn to get started, you'll need to count all of them.
Again weight the concepts for how easy they are to learn, 1 for something that's very easy, 3 for a complex concept.
Then consider how easy your software's bespoke concepts are to learn, and is that learning effort worth the benefits that the concepts provide? Are there any concepts that are unnecessary, or overly difficult to learn. You can use a spreadsheet to note down where simple workflows pass and fail the standards that you set in as much detail as you're comfortable with.
| Workflow | Number of Concepts | Weighted Score | Pass/Fail | Comments |
|---|---|---|---|---|
| Drawing a line | 2 | 2 | Pass | As we always open the app straight into a new Scene, this is as streamlined as we can make it. |
| Setting a dash pattern | 6 | 7 | Fail | We should load the shape's settings when the user creates a line by drawing, removing a step. We have no default dash patterns to choose from. It may not be clear dash patterns are measured in pixels. |
You can then map the results as a graph for your UX dashboard. You should be aiming to have this graph as flat, and low as possible.
Concept Management​
Consider how the software allows users to manage concepts (create, modify, delete, instance, copy/paste, drag/drop, customise, undo/redo etc.) - please note not all concepts (very few in fact) require management, so you should create a list of manageable concepts first.
Testing Concept Management​
Go through the manageable concepts and consider each type of management (this will vary per app), then assess if this process clear and user-friendly, and, importantly for professional software, does management scale well, or does all of this add another layer of complexity? That is to say, can users perform actions en-masse without consequence.
You can then create a table of the results.
Conclusion​
The goal of evaluating the concepts is to ensure that users can perform tasks efficiently without unnecessary concepts getting in the way, and that the system scales in complexity in line with user expertise and task complexity. The key is balance: providing enough concepts to make complex tasks both possible and manageable without overwhelming the user with too many or too complex concepts for simple tasks. Remember you shouldn't remove a concept (of series of concepts) without replacing them if it would remove a useful workflow for a user, as while this will of course simplify your software, a user cannot use your software if they cannot complete their work in it.
When performing this evaluation, if you find yourself being overwhelmed by the amount of work, scale back what you're doing, test smaller areas rather than the complete app, and simplify the data you're collecting.
Check After Improvement​
When iterating on the aspects discussed here, it is important to be aware that increasing, or decreasing the number of concepts in a system can notably affect:
- Invisible Links
- Premature Commitment
- Real-Time Review