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.

The 5-Day Design Workshop … Sort Of

I recently had a startup ask me to brainstorm solutions to their current product. After a 1.5 hr session, they wanted to turn it into a 1-day project. But my reply was “no way – you can’t fix a product in 1 day”. Since then, I’ve been thinking more and more about what quantifies as Lean – and does it mean UXers should be able to create 1-day bite size projects?

My answer is still “no way”, however, there are steps we can take in a 1-week sprint that I find helpful. These are based on the theories of C. Todd Lombardo; and explained by Bruce McCarthy in his talk titled: Lean Roadmapping: Where Product Management & UX Meet.

Here are Lombardo’s steps toward a 1 week Design Sprint:
1) Interviews on Monday
2) Compare notes on Tuesday
3) Brainstorm what you want to prototype on Wednesday
4) Build the prototype on Thursday
5) Show it to Monday’s interviewees for feedback/validation on Friday

Of course, to hold interviews on Day 1, there has to be a considerable amount of planning on Pre-Day 1 in order to: get those interviews set up; UX and stakeholders assembled; and the re-visit on Friday with the Day 1 attendees. So, theoretically, a 5-Day Design Sprint works; but don’t expect to accomplish it in 5 days.

The $300,000,000 UX Fix

There is a legendary tale of the famed UX Designer Jared Spool asking his retailer client to change a part of their checkout flow.

The client (a $25 billion retailer), had a button requiring users to create an account or fill in their account information before entering their credit card.

Through user testing, Jared’s team found that new users did not want to create an account for a 1x purchase; and returning users whom had forgotten their login credentials did not complete the purchase 75% of the time.

The UX Solution was: They removed the Register button and replaced it with a Continue button and simple message stating that the user did not need to register to purchase on the site. Revenue that month increased by $15 million, adding up to $300,000,000 over the course of the year.

Read the full article at UIE.com

The Double-D Rule

The double-D rule is simply: Differences are Difficult

When designing interfaces, it’s important to remember that inconsistencies create challenges for users. If our users have already used a feature in our application, such as a left side navigation, don’t suddenly move the navigation to the right side of the page. It’s one more point of cognitive load the user will have to absorb – even if it’s the exact same menu, just shifted, it’s still forcing the user to think – and thus taking up some useful processing that would be best applied to newer/different concepts. Conclusively, don’t create differences; rather, be consistent.

Exploring the T in “T-shaped UX Guy”

The T is a visual representation of the following concept:  the horizontal axis represents multiple skills – such as empathy, engineering, information architecture, visual design, wireframing, content creation, user testing, whiteboarding – skills that add to the whole picture; whereas the vertical bar represents the specialization, such as Interaction Designer.

In my case, I started off my UX career as an Interaction Designer – feeling that the thrust of my skills was in interpreting/predicting/enhancing user interfaces (i.e., where the interactions happen in a software application). But I soon came to realize that I wasn’t ready to pigeonhole myself – even though my business cards suggested otherwise.  So, I began to modify my personal narrative: “I’m a Generalist  – but the perfect jobs are the ones where my colleagues LOVE whiteboarding, and user testing, too. ”

I’ve also come to realize that most of us, including myself, are not a 90 degree T type.  My T is a little more like a robust tree with low hanging fruit. I’m not just “Super Duper Whiteboarding Strategist”; I’m also “decent visual designer; strong coder; pretty solid video editor; great writer(?!); rapid prototyped; great user tester and researcher – with experience designing a Google Glass app.”

For more about me, follow me on Twitter or Instagram.  But know what, you can catch me on YouTube, Tumblr, Google Plus, Flickr and Yelp too. Cool? See you at the Internets!