Reducing the Cognitive Load – My UX Strategy

During my years as a school teacher working with second language learners in inner city schools, I gained a terrific understanding of how the brain works. This was important to me because it affected my student’s success: If I didn’t understand their process of constructing knowledge, then I couldn’t effectively teach them new concepts.

In a nutshell, the brain constructs knowledge as such: it has a foundation of comprehension – then it moves into a state of instability as it tries to assimilate a new concept – and finally, it reaches a new level of comprehension. Thus, it goes from 1) knowing, to 2) not being sure, to 3) knowing.

As a UX designer, being armed with this knowledge of how the brain works pushes me to create user experiences that are intuitive. Why? Because the middle stage of learning is by nature a painful stage – as humans, it is normal for us to feel insecure when we are not certain. Uncertainty creates worry and/or anguish – it is a period of emotional struggle for most users.

Thus, as an empathetic user experience designer, my goal is to alleviate feelings of discomfort in my software designs. To accomplish this, I manage the cognitive load throughout the lifecycle of my product so my users spend as little time as possible in the middle stage of the learning process – the painful stage.

Managing the Cognitive Load – Some Examples

To manage the cognitive load means to be aware of the user’s emotional state throughout the use of our product. If the user has to struggle – because we simply must introduce a new convention – then we want to be sure that at the most challenging points of the journey the cognitive load is light. This way their brains will be nimble and agile, as will be their emotional state.

To keep the cognitive load light, we rely on patterns, or conventions, so our users are constantly in a state of knowing. They travel through our designs feeling confident – there are conventions such as back buttons and undo; there is efficient messaging when mistakes are made to gently guide them back onto the correct path; there are concise labels and brief instructions; there is hierarchy to content emphasized by visual design.

Here’s a small example of how I both prevent my users from making a mistake and how I nudge them back onto the correct path if they do make a mistake. When a user has to create a password for a login, I tell them ahead of time the criteria required for a successful password; then if the user attempts to create a password that does not meet that criteria, I give them a gentle reminder as to what the password requirements are – hopefully catching their mistake and giving them a specific error message identifying which part of password has not matched the criteria, such as “must be at least 6 characters long”.

Similarly, in my app Eat Sleep Poop App, I present a novel UI interface – one that simply requires one tap to create an event. Such an interface is not conventional – and the likelihood of users feeling insecure or confused by it, is high. Users expect to tap twice to complete forms, such as “selection + submit = event created”. However, based on my ux research and my desire to design a product that is faster to use, I created the pattern “selection/submit = event created” – thus allowing event creation to occur with one tap (my goal was to make it easier than picking up a notepad and writing down the event; and faster than my competitors apps that require 2 or 3 taps to log an event).

In order to lighten the cognitive load for my users, I relied upon common conventions to pepper the experience surrounding the 1-tap interface. For example, any button on the 1-tap screen that requires more than one tap is a More button ( … ) or an iOS slider; there is a standard tab bar navigation at the bottom of the screen; there is a standard top navigation; there are Headers and color coding to define sections; there is an Undo convention – in case their 1-tap is a mistake; there is a count that appears in the bottom tab bar signaling where the data has been logged. All those conventions are common, so my users are not thinking about them. This means their brains are not busy analyzing data – they are not in a state of learning – yet – because all these conventions fit into their base layer of knowledge. This creates an advantage for me, allowing me to take risks with their emotional state; allowing me to introduce a novel, unconventional pattern – knowing that they will be full of confidence when they meet my new pattern.

Ultimately, until my 1-tap UI pattern becomes familiar to my users, they will experience a moment of struggle when they interact with it. They will pause, they will think, they will take a moment to decide – and based on our understanding of how the brain works – we know they will have a moment of insecurity, perhaps anguish – but they will be able to handle it. It won’t feel overwhelming because their cognitive load is light, and thus their emotional state is positive and confident, as they learn to use the Eat Sleep Poop App 1-tap interface.

Working with Offshore Mobile Developers – It’s Awesome

For the past several months, I’ve been creating a product using freelance developers on Upwork – and it’s been fantastic. Currently, I have branches of my iOS app being built by 3 different mobile developers – including a woman from Hong Kong, a gentleman from Ukraine, and another from Germany. In addition, a developer in Pakistan hops on Skype calls with me to help me evaluate project timelines and committed repo builds.

Why am I working with several developers and not just one? It all started from a place of fear. I was afraid of theft – that some developer in a far off land would steal my product, repackage it, and launch it on their own. Well, those fears haven’t completed dissipated. I’m still very cautious when entering into a new working relationship. Two of these guys have been with me since day 1, and it’s gotten to the point where I trust them implicitly with my code base – and also in terms of cost/invoicing.

But here is how I approach working with a new developer: I give them a blank, private repo on Github, and ask them to commit their work to it. In these cases, the work has not been dependent on the entire code base. Thus, they could work in this silo. For example, in 1 round we just focused on the layout and interactions of 1 screen in the app – no back end was required. In another case, where a backend was required, I mocked up a “faux app”.

Part 2, The “faux app” process

My app requires a login flow that allows the user to “skip to browse”. When they are in browse mode, they can’t create certain actions – and they can’t observe certain user-protected screens. In order to hide the entirety of my project, and simply build a working relationship with a new developer, I created a simple, simple app – I title this the “YesNo App”. And here I emphasized with the developer that this entire iteration was about the user experience of the log in and sign up process – including all the error messaging that accompanies such a process – in particular, errors related to duplicate account creation when a user authenticates using Facebook, and then tries to authenticate once again with that same email address.

There were moments where the developer was incomprehensible about what I was asking them to develop – the app was so ugly, didn’t I want him to him make it prettier? My answer – “absolutely not. Pretty is completely irrelevant for this build. It’s all about the tech that goes into making these flows great. If we can execute the tech properly, then we’ll discuss the visual design.”

In the end, the developer coded this entire build without ever knowing what my final app would look and work like – only how the login & sign up flow would feel like – and the flow of being logged in or logged out of my faux app.

Attached is 1 of the specs I provided my developer. YesNo Prototype – Messaging, Flow, Experience

Lastly, I should mention, he needed to build out an MBaaS for this faux app to work. He did so in Parse, then simply transferred ownership of that Parse app to me when the project was completed.

Thus, this “faux app” process allowed me to protect my product while developing a key part of it: the Sign Up/Log In flow.