How does one model and measure the cognitive load?
Strange question, isn’t it? It haunted me for over three years before I finally found a way and integrated it into my design process. It felt cosmetic in the initial days, but it turned out as a persuasive tool and helped minimize the gap between requirements and initial design proposals.
It all began with ordering food!
My architect and I were headed home after a two-day-long design thinking workshop in Pittsburgh. While waiting for our flights, we decided to grab some food.
My mind always gives up on me when it comes to food. Overwhelmed with the number of choices, I was lost. Finally, looking at my confused face, my architect decided to help but not before saying, “You are confused about food?? Imagine our users’ state when they use our complex interfaces.” (Welcome to the world of Mainframes!)
Shamelessly, I took the help — I was super hungry 😅. But the thought kept lingering. No, not the complex interfaces part, the ordering food part. I always had this issue; why? Even today, I avoid going to events not to embarrass myself in front of everyone.
Deep introspection and correlating with a topic on cognitive science related to linguistics made me realize that language was the barrier. Err! What? Was the language the barrier? Wasn’t the menu in English? Sure, it was! But I prefer seeing “Peanut butter and jelly sandwich” over “Pâté of roasted indigenous legumes, paired with a compote of seasonal berries, served on hearty sprouted wheat bread.”
Natural languages with many ambiguities and redundancies in word meaning are hard to learn. Languages with more compact syntax (grammar) and consistent semantics (meaning) are easier to learn.
Daniel Rosenberg
What hasn’t changed over the years is how we master and recognize spoken language. When this language structure has complex syntax and inconsistent semantics, it impacts our cognitive load.
The above statement stands true for user interfaces too. The more compact the syntax (grammar) and consistent the semantics are, easy it is to learn and use our interfaces. Wow, I sound like Yoda now!
How do we make our interfaces easier to learn (and use)?
Do you think all we need is a UX/Tech/Doc writer? No! We are talking about minimizing the cognitive load by simplifying the syntax (grammar) and introducing consistent semantics (meaning) to make our interfaces easier to learn (and use), not create or verify the copy on an interface.
What we need are the User Stories from our Product Managers or Product Owners. We should use Interaction Design (IxD) Grammar as the design tool to convert user stories to conceptual grammar, measure the cognitive load, simplify the grammar, which will eventually reduce the cognitive load and make our interfaces easy to learn and use.
Greek and Latin? I know 😅. I had the same feeling when I first heard about this approach. But, as I practiced it, it made so much sense that I can’t stop using it in my design process.
Grab a cup of coffee, and in the meantime, I will try and simplify this for you with an example.
Using Interaction Design (IxD) Grammar as the design tool to model and measure cognitive load
Back already? Good! Let’s start with a few key terms.
- Cognitive Load: The amount of work we give our brain when we’re thinking or making decisions
- Interaction Design: The design of the interaction between users and products, systems, or services.
- Interaction Design Grammar: Same as the spoken language, Interaction Design Grammar consists of of Nouns, Verbs, and Adjectives represented as Objects, Actions, and Attributes.
- User Story: A simplified description of a requirement describing the type of user, what they want and why
- Object — Action Matrix (O-A Matrix): Representation of Objects and Actions extracted from the user stories
The Process…
Step 1: Define the user stories
Based on your setup, work with your product management to define the user stories.
In Scaled Agile Framework, we follow the Features > User Stories pattern per product. The Product Manager (PM) defined the features of a product.
The Product Owner (PO), the development team, and the designer brainstorm on the feature to identify and define the User Stories.
Step 2: Re-order the user stories and identify objects and actions
Once the user stories are defined, re-order the stories in the sequence of anticipated user flow and identify objects and actions.
Step 3: Create a first-pass conceptual grammar
Convert the user stories to Object — Action Matrix to represent the conceptual grammar.
The conceptual grammar design represented above is sparse due to several inconsistencies and redundancies (holes in the above matrix), making the cognitive load proportional to the product of the Objects and Actions. If we design with this grammar, our users will need to remember 7 * 4 = 28 pairs for this feature.
Step 4: Refine and Compact (Object-Action Simplification)
By applying the method of simplification, we can exclude
- Repo Name has no actions, and it should be an attribute of a mapping
- Owner is either a System Administrator or a Mapping Owner
- Messages and Email notifications are attributes of a mapping
- Change is a synonymous word for transfer in this context
We also exclude Receive as it is a non-transactional action — the state of the task doesn’t move forward which this action.
The conceptual grammar design represented above is consistent and dense, making the cognitive load proportional to the sum of the Objects and Actions. If we design with this grammar, our users will need to remember 3 + 2 = 5 pairs for this feature.
With this, we now have a grammar (Table 2) with 82% less cognitive load than the grammar in our first pass (Table 1) without removing any functionality.
Step 5: Refine the user stories
Finally, regroup with the team, share your observations, refine the user stories, align and proceed to the next set of actions in your design process.
In a nutshell…
Complexity of an interface grows exponentially when inconsistencies and redundancies are introduced in grammar. This stands true for both natural and programming languages. By using Interaction Design (IxD) Grammar as a design tool, we can model and measure the cognitive load at a conceptual level, and not just reduce the load, but also reduce the gap between product requirements and initial design proposals.
