Comments are off for this post.

Magical Empathy Booth – Service Design Project

Winner at the LA Service Design Jam, 2016: "Best Service Design"

The Project

Designed in under 48 hours, this project was the collaborative effort of 5 persons - including myself, a strategist, another UX designer, a developer and a TV editor.

We met at the jam and coalesced around the topic of Children/Education. Our goal evolved around the following statement: “What if we can instill empathy in children?”

We developed a prototype and presented it to an audience of 100+ persons. We were voted the best service design by the judges and attendees.


The Process


We designed personas: children in 2nd/3rd grade were our key persona. Teachers were secondary. Parents were tertiary personas.

We collaborated on a script, then went into the field to gather interviews. We broke off into a teams and collectively gathered about 10 interviews.

To synthesize our divide-and-conquer research, we:
1) unpacked our information to unearth problems we’d discovered, and
2) sought to understand where a product or service would fit in to solve these problems.



  • Whiteboard and use stickies to find affinity with ideas.
  • Create a Ven diagram to visualize our problem.
  • Prototype using crafts - from Barbie Dolls to note cards to improvisational acting exercises.

Build and Test

  • Within hours of identifying our product - the Magic Empathy Booth - we began testing our prototype.
    • Did users agree that we were succeeding in iliciting empathy?
    • Was our model scaleable?
    • Would children and/or parents find our prototype effective and enjoyable?



We designed a service that contained a gameified solution. Students would not know whom they were communicating with while inside the booth, as their voices would be masked; and their personas would be reflected as an avatar to the other person in the booth.

We focused on touchpoints, such as identifying a need, seeing an advertisement and having a follow-up activity after exiting the booth.


The prototype was award winning because we user tested throughout its entire lifecycle; and incorporated the feedback into each iteration. But our success would not have been possible if we had not worked so well together as a team. We each took turns pushing agendas; but also compromising. Lastly, we had fun!


Comments are off for this post.

The Key to Fixing Enterprise Software

In Jared Spool's podcast on titled "Time Traveling with Enterprise Applications – UX Immersion Podcast", they explore the topic of fixing bloated, unusable enterprise software systems from a ux strategy perspective.

Jared Spool and company highlight how enterprise software is often database driven, e.g. "if it's in the database, create a field for it on the screen". It makes sense, since most of these systems were driven by engineering and built 10+ years ago. Back then, users and design weren't as vaulted as they are today.

I enjoy how Spool and company flow from identifying the problem to fixing it. If there's one golden nugget to take away, it's the following tip: watch/understand the enterprise users suffering while attempting to complete tasks using the software; then start chiseling away, bit-by-bit, at the improvements - make sure each release has at least one of your fixes in it.

In my experience, it's almost that simple - but not quite. People are often so preoccupied with pushing out features that even when they see user's suffering to navigate the archaic interfaces, they don't think "we better fix that"; rather, the thought process is "well, they'll suffer one time to figure it out, but then they'll know how to use it and won't suffer any more since they'll understand it after that first time."

Other things holding back the required changes is the coaching/training departments that corporations invest heavily into. Each time a change is made, the training manuals and lesson plans must be altered.

And lastly, there's the fact that if the software is so archaic, many great ux changes simply can't be accomplished. For example, in the old of Microsoft-driven technologies (ASP), it was standard practice to always compute changes on the server and to push them to the front end. Whereas, great modern user experience accomplish these same tasks on the client side - allowing for state changes without a page refresh.

Conclusively, though Jared Spool's plan of making incremental changes in each release is helpful, it falls short of describing how to accomplish great ux changes. In order to accomplish great ux changes in old enterprise software, there has to be a simultaneous build process - so for each feature that is carved into the archaic system, that feature is built out into the new system as well. At some point, the new will catch up with the old; at which point the old can be switched off (and buried!) and the new can light up the world.

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.

App Store Descriptions are Gifts to UX Designers

When I’m starting to research a new client’s digital product, one of my favorite places to go is the app stores. This is where companies have an opportunity to identify their product in the most concise terms possible.

Let’s take a look at how Instagram describes themselves in the app stores: ‘Over 300 million users love Instagram! … It’s a simple way to capture and share the world’s moments on your phone … customize … transform … share your photos and videos … follow … Facebook, Twitter … ’ [note: I’ve added the elipses to cull the key words].

If we view their marketing copy on their web site, it is different. It includes their slogan: ‘Capture and Share the World's Moments’; but it doesn’t emphasize simple or the number of users. The keywords here are: fast, beautiful, fun, easy, free, Facebook, Twitter.

It’s hard to argue with such a successful company like Instagram. We can assume that they market their product differently on the web vs in the app store for a reason, probably based on analytics. With less prestigious companies, however, such as newer startups, I have found that such choices are not intentional - but mistakes. For example, an LA startup I worked with had contrasting copy on their Android vs iOS descriptions. This revealed several user experience holes in the company’s product.

When a company is inconsistent with their marketing copy, it reveals the truth about the company - that they have a fractured organization, where one hand doesn’t know what the other hand is doing. For example, the marketing team isn’t in-line with the engineering or product teams. And thus they are chasing different goals. Ultimately, it’s the user who pays for these inefficiencies. An analogy is a child whose parents disagree; one parent says so-and-so is bad; whereas the other parent says so-and-so is fine. The child ends up confused as to which message is the correct one. Similarly, if a company sends mixed messages to its users, those users will wind up confused and/or missing out on understanding key features about the product.

As a user experience designer, these kinds of mistakes are opportunities to do good - to help a company align its message. We can find out whom is responsible for writing the copy; for posting the copy to the app store; and for driving the strategy behind the copy. And then we unite those persons through documentation - maybe just emails - but ideally, through healthy discussions, whiteboarding and Google Docs. Soon, the message will become succinct; teams will become unified; the design will reflect that unified message - and users will reap the benefits.

Lastly, I’d like to emphasize how much a unified message can effect a company’s revenue. If their message is unified, it will be reflected in how their users talk about the product. Like the game of telephone, if the message is simple, it will remain intact after countless numbers of persons have re-iterated it. Same with a digital product's message - it has more of a chance of going viral if it's succinct and concise - and, of course, reflective of a succinct and concise product.

Comments are off for this post.

Focus Groups vs Usability Testing, in brief

I was at a General Assembly socializing event last evening, and some one asked me if I could explain UX to him. Part of our conversation involved the discussion of user testing - at which point he suggested that focus groups sounded like the same thing as user testing. I explained to him that they were different, essentially in that focus groups are usually marketing driven; and that usability testing is led by UX designers and one-on-one.

Below is a summary comparison, culled from Steve Krug's 'Don't Make Me Think', which sits on my coffee table.

Focus groups are best completed in the planning stages of designing a product or feature. It’s often 5 - 10 people talking about their feelings; how they might feel doing such and such; so they help define what a product might be. And, to some extent, if it should even be designed in the first place. Most often, marketing leads these research sessions.

Usability testing is best completed throughout the entire life cycle of the product - before, during and after things are built. It’s 1 person using - or attempting to use - the product. This form of testing helps us see where users get stuck when using our product.

Comments are off for this post.

A quote on Lean UX

Get a concept. Create a prototype. Validate internally. Validate externally. Learn from user behavior. Iterate. — J. Gothelf, the author of Lean UX

Comments are off for this post.

A quote on Lean UX Deliverables

Sketching, presenting, critiquing, researching, testing, prototyping, even wire framing ... the trick is to use these tools when appropriate and, more importantly, to use them at the depth appropriate for the immediate problem you’re trying to solve for the business. — from the article Lean UX: Getting Out Of The Deliverables Business, on Smashing

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.

What’s Essential to Know about SVG

SVG is a relatively new technology that allows for improved rendering of image-like content. It's a preferred method for adding artwork to mobile and web apps because it performs faster than traditional jpg and png images.

SVG are essentially vectors - you can increase and decrease their size without losing quality (using code)

SVG are better than icon fonts because: they are image tags, which makes them better for accessibility and they have more controls (e.g., class name).

Apps are built using templates. Here's how to templatize SVG:
use inline HTML, and wrap the SVG in a DEF tag, as DEF prevents it from rendering. You can use it one time and then point to it in the templates. SVG is rendered in the DOM, so there’s no HTTP request (HTTP requests slow apps down) - then use CSS and JavaScript to make it increase or decrease in size, animate, etc.

1) a PNG might render faster if the SVG has a lot of vector points - thus SVG is more for boxier artwork, such as charts and graphs or logos that don't contain a lot of complex lines

2) SVG needs fallback support for Android 2 (and IE8)

based on LukeW’s notes from C.Coyier’s lecture:

icon set in this artwork can be found here: