Comments are off for this post.

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.

Comments are off for this post.

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.

Comments are off for this post.

On Mobile, Design for Interruption

Let's face it: we use our phones when we're driving, when we're in line at Starbucks, even when we're in the restroom at the ski lodge and there's 10 people waiting to birth something unmentionable. So what happens to our mobile experience when we are interrupted? Where does our mobile experience go?

Great apps, like YouTube's for iOS, allow the flow to continue from the point of interruption. There are some accommodations that can't be made - for example, if you are viewing a video in full screen, you'll lose that view (tested in iOS 8.1). But the result is acceptable: the video is paused and in the state we left off before the interruption occurred.

Another handy feature that the YouTube product as a whole has (not simply in iOS) is: the History content section. If my experience is interrupted - say, because a cop has pulled me over - then after the cop leaves, I can pick up where I left off by going to my History and finding the video I was recently watching.

The champion in this pursuit of designing for interruption is 'the Cloud'.  It's this remarkable technology that is allowing digital companies like YouTube to create seamless experiences for its users. Habitually, all internet connected experiences are frequently transitioned - not just interrupted - purposefully and wistfully from one internet connected device to another. For example, on any given day I'll be sitting on my couch looking at a YouTube video on my phone. It's possible that later, when a friend arrives, I may launch YouTube on my Apple TV and pull up that same video. And still later, I may again reference that video while sitting at my desktop computer. This seamless, wistful experience would not be possible without the almighty cloud, which allows for synchronization of all my data across all my devices.

Viva interruption - and viva 'le cloud'.

interruption flow mobile

interruption flow mobile

Comments are off for this post.

My Mantra for Mobile Design

There’s a lot of mantra in discussing mobile, such as ‘keep it simple’, ‘feature rich, user poor’, and ‘remember the 80/20 rule’. With such competition, i’m hard pressed to think of a new catch phrase to describe the process of mobile design.

I suppose if i was using mobile to type my mantra, it would come out in the form of a short text character burst: ‘delight them with simplicity and efficiency’.

Ok, so I guess I just wrote my mantra.

Well, now that i’ve written it, i have to consider how to advise accomplishing it. One thing that can’t be omitted - so we might as well start there - is knowing our users.

Of course, it’s easier to know our users if we already have an existing product. Then again, it’s easy to assume we know our users because we have an existing product - and the tried and true response to assume is don’t assume, or you make an ass out of u and me.

So how do we really get to know our users? *User interviews is irrefutably the best way. However, analytics helps too. For those with an existing product, examining the analytics to see which 20% of our features are being used on mobile devices is a primo place to start.

Then there’s the startups with a unique idea - they don’t have users yet. Therein lies the benefit of not having to edit somebody else’s work, i.e., you can start from scratch. Have you ever been handed a document that’s been authored by others, and that you have to edit? The task can be overwhelming. It’s like inheriting a code base developed over several years - versus creating the whole application from scratch. Or a piece of furniture from Ikea - and being told to add onto it, but make sure it matches.

My advice? Go Japanese - design, design, design - add layer upon layer upon layer - then start taking away, stripping down, removing, re-shuffling - heck, throw it away, breathe, then start from scratch. Ultimately, you’ll enjoy the process because you’ll be constantly problem solving - and you’ll wind up with something so simple - and efficient - that it delights. The quality will surface in your work, while the waste will get siphoned down the drain.

This Japanese design process i’m referring to applies to whether you’re re-writing an inherited design; or starting from scratch with a new one. In the case of a code base, Git Hub is our hero - and in the case of a tech spec, I simply duplicate my document and keep a series of sequential revisions in Google Docs. (For you Ikea builders, you’re on your own).

In summary, when designing for mobile, in order to ‘delight them with simplicity and efficiency’, we have to understand our users through user interviews and analytics - and we have to iterate by building and tearing down, forgetting and rebuilding - over and over again. As a result of our design process, we’ll understand our product so intuitively that we’ll be able to serve up it’s good parts and omit the rest. In return, our users will feel delight for the efficiency in our design and (hopefully) fall in love with our creation.
*note: in that we can’t user test without user interviewing, I’m bundling user interviews and user testing into the one term user interviews

Comments are off for this post.

A Tale of Serendipity: iPhone Shortcuts & Bicycles

Recently, I found myself riding a rented bicycle down by the Santa Monica Pier. In an instant, as I rode behind my girlfriend, I realized I wanted to snap a picture of her. The picture would include the shadows of the underpass which played such a stark contrast against the fast approaching sun kissed beach path. I had to have that picture and it was out-of-the-question that we stop and pose it. That’s where the brilliance of the user experience design applied to the iPhone enfolds this story. Within a matter of about 3 seconds, I was able to accomplish the following left-handed, while continuing to pedal and steer my bike:

1) hit the wake-up button, i.e., Home button
2) swipe up on the camera icon shortcut that appears on the lock screen
3) frame my shot
4) snap my picture

Without the design including a shortcut to the camera in the lock screen, I would not have been able to capture my photo. The UX designers at Apple predicted my situation, probably by developing personas during the design process, and by conducting user tests. For this, I tip my hat to them and say "great f*cking job, you’ve made me a happy man".

bicycling under the Santa Monica Pier

iPhone shortcuts help us capture serendipitous moments

bicycling and iPhone shortcuts

iPhone's brilliant UX design allows us to use the camera while biking

Comments are off for this post.

Software Smackdown: Balsamiq vs Keynote vs Omnigraffle vs InVision

  • Balsamiq Mockups for Desktop, Version 2.2.19
  • Keynote 6.1
  • Omnigraffle 6 Pro
  • InVision (cloud platform, 03-19-14)

Today I focused on creating the same low-fidelity iPhone 5 prototype in 4 different applications: Balsamiq, Keynote, Omnigraffle and InVision.

My end product was a login for an e-commerce store.  By developing the same clickable prototype in all 4 softwares, I was able to getter a richer understanding about which one(s) I want to fall back on when needing to rapidly prototype a product.

Here’s what i learned …

• very quick & easy to learn

• have to drag/drop an image
• no mask abilities
• no layers (a workaround is to make an object “markup”)


awesomely simple and quick


• very quick & easy to learn
• simply hyperlink buttons (versus creating “hotspots”)

• no iphone 5 artwork
• no layers: using master template is less intuitive then using layers


also quick and easy to use

tough to figure out, but quite robust
• has layers
• has precise info on grid positioning

• doesn’t come with iPhone 5 stencil artwork (only iPhone 4)
• in preview mode, I got an awful hover highlight over the entire main content
• hotspot navigation falters when using masked artwork in combination with layers


robust feature set, including layers

• very, very quick and easy
• don’t have to mask overflowing content, as the software handles it for you
• preview is phenomenal
• comes with iPhone 5 artwork

• no layers - so you might have to merge some artwork
• resolution is confusing (uploaded artwork gets stretched)
• can't edit device once past the selection screen


very simple for quick drafts, but tough to edit


inVision and Balsamiq: both are easy to learn, with inuitive flows and ready-to-go artwork; thus, allowing us to focus on the task at hand (quick prototyping, low-fidelity) rather than thinking about how to use the software