Compare and Contrast – A Technique for Better Specs


By providing compare and contrast opportunities in our specs, we are infusing ux into the ux/ui hand-off experience.

When we are in the process of providing specs for a product enhancement, the developers are already familiar with the product (assuming they built the original product).

Since they are familiar with the current product, it facilitates their cognitive comprehension of the desired changes if we provide them with a compare and contrast spec that is annotated. The result being that we are working with their current mental model and then gently ushering them into the new design. The annotations help quickly identify the differences. And the side-by-side presentation allows them to

  1. not work from memory, and
  2. be able to quickly identify the differences visually.

Compare and contrast is a teaching strategy employed at all levels of curriculum, since it’s so effective at scaffolding knowledge. By bringing this technique into software development, we can make the process more delightful for everybody involved – especially the engineering staff that needs to interpret the specifications. But similarly for stake holders that need to understand and sign off on designs before they get moved to the development stage.

Since employing this technique in my specs, I find that there is much less back-and-fourth, much less “mansplaining” and simply a lot more calm around the design handoff process. If you haven’t tried it yet, I strongly suggest you do.

What’s the Difference Between a Product Manager and a UX Designer?

In the words of Julie Zhuo, product designer at Facebook, a UX designer is “responsible for the actual design (the flow, the sound bytes/pixels, etc.)” while the product manager is responsible for “coordinating across different teams, getting folks aligned on goals and timelines, inward/outward communication, and analysis of whether a product is actually a ‘best product’.

In my own experience, it depends on the size of the company. When Eat Sleep Poop App was just me and some developers, I had to divide my time between doing all the ux work – research, flows, wireframes, prototypes, testing, analytics – and the product management work: finding synthesis between the tech and the design; making sure the product fits into higher-level goals of the business – such as having a release in time for the holidays; communicating a unified message about the product across different verticals, such as Facebook and the App Store; adjusting our IAP strategy to increase sales.

Now that I have a very talented UX designer working with me, I am freed up to focus more on the product. Of course, the UX is still vital, and I continue to be involved with all the intricacies of the customer experience; but now I’m more able to consider the business aspects of the product – namely growth and sales and their alignment with both tech and design.

A lot of how a small product business such as Eat Sleep Poop App evolves is: “what can we afford to do this month that will produce the most value?” And then the value is determined by understanding our customer’s needs. A good example is this pending 4th quarter of 2017. While we have spent most of 2016 growing, we did not take the time to do some essential development work on the code base. Now we are looking down the barrel of Apple’s release of a brand the new version of Swift 4, and we are barely catching up to be steadily entrenched in Swift 3. That means that if we are to continue down the path we’ve been on for most of 2016, we are further distancing ourselves from having an updated code base.

So here’s some more specificity for you: I received a request from some users to update the Sleep module of Eat Sleep Poop. And believe me, I am dying to give them that enhancement – especially because my analytics shows that it’s the #2 feature of my app – but if we focused our energies on that enhancement, we would be building it on top of a shaky code base – and with new, un-tested engineering talent. That could be a big waste of time. Consider the math: each team member spends about 15 hrs/week on the product (it’s a side project for all of us); if an engineer who is unfamiliar with the code attempts to build the Sleep enhancement and fails, we could potentially have lost a month. This same engineer could be assigned the task of refactoring the code (the migration to Swift 4), which would put her in the position of learning the code base without a ton of risk – while getting us closer to our goal of having a Swift 4 code base.

In the meantime, my UX designer and myself have the time to prepare and test designs at a prototype level – all the while determining which features and enhancements will bring the most value (in addition to the Sleep module enhancement that has already been planned).

Back to the question of how the role of UX differentiates itself from the role of product designer, I see the role of the product designer as quarterbacking the ball down the field; and the UX designer as the role of the running back. They are intrinsically combined; however, the product designer has to strategize at a higher level, one that encompasses the commercial success of the product. In the words of Jeff Lash at SiriusDecision, “the product manager is responsible for the commercial success of a product, overseeing it from inception/ideation through design, build, launch and growth/enhancement.” Whereas before 5% of my time as UX designer was spent on growth, 30% of my time as product manager is spent on growth. Similarly, 90% of my energies were spent on the mobile app; whereas now about 50% of my energies are spent on alternative applications which can become pillars of Eat Sleep Poop – such as a web application and IOT applications.

Related Articles: A Product Managers Job. By Josh Elman. Medium. 2013


  1. Julie Zhou on Quora
  2. Jeff Lash on

What are Mental Models and How do they Apply to User Experience?

A mental model is a concept in a person’s brain; it’s how they imagine a system works. It’s based on their past experiences and influences how they make decisions in their current experiences. For example, a user that has used a watch will have ideas about how an Apple Watch will work. Additionally, if they’ve used an iPhone to compose a text message using the Messages app, they’ll have a mental model of what the texting experience on an Apple Watch using the Messages app will be.

The challenge we face as user experience designers is achieving an interface that matches a user’s mental model; that way there won’t be a disconnect between how the user imagines the interface will work, and how it actually works.

Referring back to our Apple Watch texting app (Messages), we have to respect the work that Apple did on making the watch app be intuitive. They designed an app that barely works like any app users have interacted with before – and only kind-of-like the iPhone Messages app. To use the iPhone app, a user types out a message on a digital keyboard on their phone or iPad. However, on the watch, there is no digital keyboard – so the user has to figure out how to use the app in a different way.

And yet, the design Apple has implemented does seem to align itself with user’s mental models. Personally, when I approached the app for the first time, I realized that I had 1 option to get started: I had to do a “long-press” action. At the time, long-press was pretty unheard of and not yet a convention I was accustomed to doing ever, on any device. But Apple had successfully onboarded me as to how that gesture would be an option at times. So even though there is no indicator in the Messages list view, I intuited that I should try that gesture. And I was rewarded by the succeeding steps in the flow. Apple has applied other common patterns that help first time users adjust to the new interface, such as graying out the send button until a recipient has been chose and a message has been composed.

Summarily, user experience designers can apply the lessons Apple has applied to their Watch design when designing our own experiences. Personally, I’m a huge fan of the grayed-out button pattern and apply it regularly; similarly, onboarding is vital for innovating. In my app Eat Sleep Poop, I saw a big jump in user retention after improving my onboarding screens to better communicate the innovative pattern I’ve implemented on the app’s home screen.

Related Articles:

  1. The Secret to Designing an Intuitive UX, by Susan Weinschenk, Ph.D.
  2. Mental Models, by Jacob Nielsen

Usability Testing and the Mistaken Next Button

I recently completed a series of wireframes to communicate the flow of a feature inside a mobile app. When I built these wireframes, my focus was on designing an intuitive experience around the navigation of the product. To make the experience intuitive, I concentrated on 1) the content, and 2) how the user could seamlessly navigate that content to accomplish certain tasks. (For the record, the task was to personalize a greeting card to his client(s).)

When I initiated the usability testing, my aim was to get feedback on wether the navigation was intuitive: had I designed a flow that allowed him to seamlessly navigate the content?

My process for creating the wireframes was that I worked quickly, copying and pasting artboards within Sketch – combining other iterations into a new one. My goal was to be nimble: to not be inhibited by my tools. Thus, my wires were lo-fi; and my Sketch files were simple (e.g., not relying on symbols or components and using a white, black and a couple default primary colors).

When I began testing with my user, I was pleasantly surprised by one of the simple responses he had to my wireframes. I had some questions around the placement of the “next” button in the design – but it was not a key element of my research. It was more of a micro detail that would not solve the flow problem – but would enhance the overall user experience if executed properly. For example, the button would not appear until a user had made a selection.

Toward the end of the testing, after having learned a great deal about the usability of the flows, I asked my user about the next button – almost as an after-thought. And the reply I received kind of blew me away. It’s almost as if the user couldn’t wait for me to ask about it – because it truly stumped him. He pointed out that on the last screen in the flow – one which I’d copied-and-pasted and made a small tweak to – the next button was confusing to him. Its appearance on that screen was confusing because he thought he’d finished the flow but here the button was still reading next. Should he hit next again, he wondered.

I realized immediately that i’d made a mistake. While copying and pasting and rapidly adjust my wires, I had overlooked a tiny detail – but one that created a massive usability issue for my user.

To recover, I explained that he was absolutely correct – that the next button should not appear in that screen. That screen was the end of his flow. I drew his attention back to what I was testing: did he realize the color of the list items he’d interacted with had updated? Did he feel like he was getting the feedback he needed from the new updated state of the starting screen?

He confirmed that yes, he definitely felt a sense of confirmation and completion. I thanked him and made sure to remove that next button before testing again with another user.

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!


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.

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.

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.

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.