A few fun things

For the first time in a while, I’m working on a consumer-facing, responsive site. The site must be fully accessible for various platforms (phone, desktop, tablet), which has been an amazingly educational experience. I’ve used a few different books as guides, but these two have been huge standouts:

Both books inspired me to write code and more importantly, use semantic markup in a meaningful way. Here a few fun things I’ve been practicing on my own.

Using viewport to create responsive navigation

This was a strangely challenging endeavor, mostly because I was playing around with Foundation for a good bit, then gave up and coded it myself. I’m really interested in using Foundation because its grid is so flexible, but I’ll come back to that when I have a firmer grasp of html/css.

Taking advantage of CSS to create responsive images and fonts

Playing around with different viewport units (vh, vw), CSS properties (max-width) helped me create an amazing website about pug hugs.

These are super simple, unattractive sites, but they helped me understand how inclusive, responsive sites come together and how to talk to our developers about creating sites that welcome everyone, which is a pretty sweet thing.


UX Shortcuts: Creating requirements from a workshop

Shortcuts are not my favorite thing, simply because they’re often forced out of necessity. More often than not, shortcuts are taken at the expense of other highly valuable resources and result in user experience and technical debt. Yet, as much as I often find them discomforting, they’ve taught me a lot about what it’s like to work effectively under documented assumptions and iterative schedules.

I recently worked for a client that wanted us to produce features sets for their web and mobile presence after a two day working session. In order to do that, I scheduled stakeholder interviews to gather business requirements and a three hour workshop to learn more about their targeted demographic. There are plenty of books on the topic of conducting user interviews, so I won’t get into that – I will, however, highly recommend Steve Portigal’s “Interviewing Users” to folks who want to get the most out of interviews.

The workshop I held consisted of two parts: persona development, and a customer journey post-up exercise. The personas developed for this particular workshop are to help direct the customer journey map and unlike true personas, are purely hypothetical. For simplicity’s sake, I’ll refer to them as personas; in reality, they are a way to focus the workshop attendees’ attention.

Customer journey maps* are the foundation for my workshop because they come with inherent reference points in the form of customer stages. These stages provide a way for a group of people to cumulatively build an experience based on each process in the journey. Customer journey maps also provide some relief from forcing workshop participants to recall all the steps a persona needs to take in order to achieve a goal since the workshop facilitator will have already defined the stages, and all the participants need to do is fill in the steps within a stage. What we get out of the maps are documented assumptions of what stakeholders believe personas do, what they are concerned with, and any stakeholder knowledge gaps. From this exercise, we’ll be able to prioritize technical features, flesh out requirements, and recommend solutions.

Persona Development

Group persona development can be tricky, but I’ve found a few ways to make them more manageable. I start by asking pointed, guiding questions. Since my final goal is to produce features for a MVP, I want the features I recommend to target the most frequent guests and their most pressing needs, not edge users and alternative paths. My first task for stakeholders is to have them define groups of end-users that come to their site the most frequently. Due to time constraints – I ask them to narrow the list down to two. For the most part, I find that these bigger effort workshops take around three hours, so just be aware of how long these activities can take. It may not seem like two personas is much work, these are emotionally taxing and intensive exercises.

Continue reading

The wrong feature

I recently entered a project in mid-stream: most of the visual design and interactions had been done, and coding was well underway. There were only a few weeks left, and my main responsibilities were to further refine the existing interactions and identify any use cases not previously surfaced. When I started on the project, the most pressing concern on our internal team was a particular business requirement specified by our clients: a Japanese keyboard. The team had been nervous about this because we were working off an open-source framework that didn’t natively support Japanese language functionality.

There were two possible solutions: we either had to create a Japanese keyboard from scratch (and the supporting features of translating syllabic, or kana, script to logographic characters, kanji), or take advantage of the the current language API available and modify it. Unfortunately, once we looked at the API, we quickly realized it was not scalable since Japanese is not contained to 26 Roman characters and the API was configured with that particular assumption. There were other considerations as well, such as the fact that we would need to account for multiple methods of typing, the ability to toggle between the keyboards, and the limited time we had to produce the keyboard. Both options were looking very iffy.

Finally, I took a step back. I stopped trying to design around the issue, and began wondering why we needed this keyboard and just how critical it was for users to have access to it. Users would already have access to the English language keyboard, so I didn’t think it necessarily had to be a high-priority feature. As it turned out, the keyboard would only live on one particular section of the site, where users would enter their wifi password. When I found out this was the case, I thought back to the time I’ve spent in Taiwan and China, both countries that use non-Roman script. I couldn’t remember whether my passwords were written in Chinese or English, so I asked a bilingual friend what he did when he was back in Japan. The answer surprised me, and also solved our problem: wifi passwords are written in Roman characters. I confirmed with a few other colleagues who spend significant amounts of time in other countries and they all agreed. We didn’t need a Japanese keyboard.

The time that our team spent stressing over this issue could have been solved if we had been more thoughtful about the intent of the requirements.  Although I’m usually involved with the requirements gathering and writing process, I wasn’t for this particular project, and I didn’t vet the document for any inconsistencies or instances of backseat designing. The issue with the latter is that people often express larger ideas and solutions through designs, so while it’s fine to use design to explain a concept, it rarely tackles the foundational problem. Here, the main issue was that our software system needed to be able to accept wifi passwords for users in Japan as well as in the States. The design solution written into the Business Requirements Document and offered to the design team was to create both Japanese and English language keyboards, which actually didn’t address the aforementioned user need. What did solve the need, however, was identifying the user story: Japanese-language and English-language users must be able to enter wifi passwords. The most valuable lesson I gleaned from this experience was that I always need to perform my due diligence in understanding the purpose of each proposed feature, user story, or requirement and to make sure design helps users accomplish a goal.

Quelle horreur – is that an iframe?

Screen Shot 2014-09-17 at 5.40.50 PM

Aside from the kicky name,  I found it strange that Google Drive couldn’t detect that I had (accidentally) logged into my gmail twice and had the same g.drive document open. How is it possible that a document only accessible via Google could not automatically detect the user? Then, I realized that something else I really love about g.drive documents, the ability to embed them on other sites (including this one!), is probably available because drive documents is an iframe.  Can someone confirm this?

On a similar, iframes make me sad note, I’m wondering if there is a way to fully incorporate/widget-ize a survey tool like SurveyMonkey or Qualtrics into an existing product without using an iframe? Using an iframe survey tool makes it impossible to detect whether a user has actually completed a survey and to provide the appropriate “warm” or “cool” state the next time they log in. My Director of Engineering very wisely pointed out that unless that a third party tool can detect successful completion of survey, our product would have to create its own survey infrastructure. (I guess this means our survey has been slotted for the “next sprint.”)

Case Study: American Airlines

I tried taking American Airlines for a business trip. Ridiculous things happened. So I decided to channel my annoyance with missing some pretty cool research interviews  by creating recommendations for AA to improve their “post purchase” (or “out of the box”) experience. I bet their own UX team has already done this, but if not… might as well borrow this. In short summary:

– Flights were severely delayed

– I missed two important business-related research interview opportunities in the midwest

– American Airlines lied to me about refunding my tickets; they sent me vouchers instead.

– AA also said they would provide a voucher for ground transport (eg taxi) back to my place – but the taxis do not accept vouchers


Recommendation 1: Don’t lie.
Examples: A ticket refund became a voucher, a taxi voucher was not accepted, and… I would have never made my flight, and you knew it!

  • This inevitably breaks down customer trust and creates negative brand perception. I had no real awareness of what the AA brand meant, but after this experience, my personal one is that AA is unreliable, rude to customers, and is a massively silo-ed organization with limited ability and desire to help customers solve their travel issues. Terrible, right? When I was telling a few co-workers this story, a few immediately asked if I had attempted flying AA. It’s not just me – fellow travelers are aware of your pain points, too.

Recommendation 2: Recognize the industry you’re in.

  • I’ve mentioned this before, but one of the highlights of Southby 2012 was Jennifer Hyman’s talk on the experience economy. At one point in her speech, she talked about the role timing and timeliness played in her business. By her account, it was one of the biggest elements of Rent the Runway; since customers are spending money in order to receive something they’re most likely going to wear at a special event, Hyman’s company has to deliver on time. The prom dress that comes two days late is no use at all. Similarly, American Airlines is also in the experience economy. We travel to get to or take part of an event, and timing matters immensely. I missed business-related work because of flight delays, and I saw the man in front of me in line nearly have a breakdown because he would not be getting to London in time for an event.
  • When timing issues occur, and I’m sure they do for every industry, then respond appropriately. Customer reps who act like severe plane delays are no big deal don’t help matters. They are! And I’m not really talking about delays in any certain minute or hour range; it’s recognizing that these delays have a chain reaction and helping your customer figure out the next steps. Those next steps should not involve your customer calling customer service after a refund has been turned into a voucher, only to be redirected to online customer service.


Sequence and flow models below


3 Essential Points from Luke W’s “Web Form Design”


My time to read industry books is so limited that I have to really be frank about what I’m able to absorb, and the reality is: not much.  It takes a bit more focus to power through something that doesn’t exactly have a narrative, like a fiction novel. It can also be a bit of a challenge to guess what parts of a book will eventually become important later on in my work, or if I won’t know if I necessarily agree with something until I try it in my own work or even test it out. So these days, I rely a lot on taking succinct, clear, notes that directly relate to projects I’m attached to.

I’m currently working on an application that has a lot of data points for end-users, which means lots of web forms, and editing web forms. Much of Luke W’s insight is pretty obvious and stuff you would probably know if you’ve used an e-commerce site or filled out a survey (in print, online, whatever) before. But I really liked these points:


It’s really nice for the user to enter whatever data however they want, as long as it’s valid. For example, look at all the ways we can enter a phone number:


There are other ways, obviously (just think of all the factorial fun involved with the parenthesis), but they’re all valid. A way to allow the user to enter their preferred method is to provide a single form field and to do the back-end work to accept all those variations. The work is on us. It’s not to say breaking up the telephone number entry form into three segments is wrong, but it might be a nice way of providing some agency for the user. Flexibility comes out in other ways, too, like how much information a user might want to enter with a form and advanced features for super users.

Label/Form field alignment

I’ve ordered these in terms of saccade time (eye movement), fastest to slowest, and when I’d personally use it. I don’t include inline form fields because there’s so much written about that online, and I personally hate it unless it’s as simple as this. You can read Luke W’s take on it on his site but studies have shown that they don’t necessarily work well. I’ve also highlighted in the drawings I’ve uploaded where the eye would begin scanning the labels – I think it’s helpful to think of that to understand why certain form fields take longer to fill out (not always a bad thing).


Top aligned. I’d use this when a user is going to fill out a form once, it’s fairly long, and they need to power through it quickly.

right aligned

Right aligned. Use when vertical space needs to be limited to a certain size – otherwise, and you still need the user to fill things out fairly quickly. I’m thinking this is more applicable to e-commerce forms. It also creates a few problems in longer form field labels (we don’t read right aligned, in English anyway) so be careful!

left aligned

Left aligned. I’d use this when you know the form is going to be edited fairly often. It’s the form that requires the longest time to read initially, but it also allows the user to scan the left aligned text really well, so that’s a huge bonus for people who are going to be working with the same form multiple times, or who will go back to edit information.

Primary and Secondary Call to Actions

This is one of the few sections of the book that I think is worth reading carefully because of the number of studies Luke W has done with usability of primary and secondary CTAs. Surprisingly, people are really good at engaging with the CTA they want, even if it takes them a bit longer. The best way we can guide them is to provide differentiation – make the primary CTA one style (ie a button) and the secondary another (ie link, or another color). People also like to see all their choices in one location and the primary action the first thing they read (whether that’s the first CTA in a list of CTAs or the first CTA in a horizontal arrangement.)

And that’s it – the details I found most useful in helping me make decisions about label design. The other chapters concern themselves with issues that you can use your design sensibilities to reason through on your own – like where to place error text (and how they interact with the rest of the form fields) and best ways to display answer-dependent content.

Feedback (finally!)

I’m a frequent Amazon Prime customer, and have been a major fan of the instant video feature. What’s been frustrating, though, is the lack of feedback distinguishing previously watched videos and how to move onto the next episode in a particular series. I realize that Amazon has limited space to do a large number of things:

  • Promote products
  • Recommend items (in a variety of ways – this takes up the most real estate and is filtered on various themes)
  • Provide browsing history

What I’m surprised by, though, is that Amazon doesn’t have a more personalized interface. Since Amazon is in a unique position of power – it requires all transactions to be done via account creation  – it means all repeat customers have a “hot” or authenticated state. So why can’t Amazon recommend the next episode of the series I’m watching instead of telling me what customers also viewed? Amazon doesn’t yet have the ability to differentiate viewing habits between television series and movies, and reflect that need in its recommended items.

In the screen capture below, you can see that I’ve recently watched “Starship Down,” which is Season 4 episode 7 of Star Trek: Deep Space 9. But what’s next?!

What I want is to watch the next episode, which is “The Sword of Kahless,” episode 8. The crucial elements: the season and episode number are not included in the “You Viewed” portion, which makes the season number in the “Customers who viewed this also viewed” pretty useless. I’m also frustrated that “Voyager” comes up when it’s pretty clear from my viewing history that I haven’t touched that crappy series in forever.

I’m not going to really comment on the huge promotion banner that dominates the largest portion of the page, causing me to scroll way down (hey, I guess their stakeholders at least believe users know how to scroll, so… that’s nice), because that seems like a business decision to me, but: it’s annoying. How come every holiday is an appropriate holiday to pimp out the kindle?

I am thrilled that there’s finally feedback for previous episodes watched!!!! I’m a tv series watcher, and have the hardest time remembering where I left off, and this makes me happy since the lack of ‘next episode’ functionality doesn’t yet exist on the user’s home page. I believe this new functionality is ADA compliant! Not only are there icons to indicate “watched,” there are also bolded contrast font as back-up, and the currently playing episode has the universal “play” (triangle) icon, is presented as a different color (but not completely reliant on it), and to the right,  another CTA that reflects current/potential actions. Pretty sure that as users become more comfortable with “flatness” Amazon won’t need as many icons/CTAs but for now, it’s a great improvement to what was there previously. Win win win.


Gotta watch Ben Sisko kick some Dominion butt.

What I learned at SXSW, Part II

After this Sunday, Austin returns to normal! Thank goodness – traffic has been crazy! I attended two really great sessions that I wanted to share.

Interface Transitions: Designing the Space Between

This panel was led by Jorge Furuya Mariche (HTC, Lead UX designer) and Corey Chandler (Deep Dive Design, Principal IXD), and it focused on just how much transitions can add value to a product, and their capability to set the tone for the quality and character of a design. The example the panelists gave that stuck in my mind was the interior car handle:

photo (50)

Think of this feature in your own car. When you pull on it, does it make a sound? Does it slowly go back into it’s socket (if there is even one), or does it snap back into place? What do these things say to you? Most likely, if the handle has no sort of “memory” feature and snaps back very quickly into its flat position, it creates a more unpleasant experience than if the handle more slowly moved back towards its original position, giving the user some time to move their hand and having minimal feedback noise. This latter experience speaks to a more thoughtful type of design, and translates as better quality. We can think of this in terms of interaction design, too – how do you transition from one state to another?

There are 3 main types of transitions that can occur, as defined by Jorge and Corey.

1. Discreet – a subtle effect that enhances the overall experience on a subconscious level (e.g. the visual feedback you give a user as your page is loading)

2. Educational – instructs user in how something works (e.g. which corners of the screen are ‘hotspots’ by having a traveling or magnified transition to a particular corner)

3. Processing – masks processing time (this can also be a place to show-off just how much information a tool is sifting through)

These can be combined, and don’t necessarily live in isolation. However, one thing to keep in mind is that the more often a particular transition occurs, the more discreet it should be. For instance, unlocking your smartphone occurs pretty frequently, so the design shouldn’t incorporate a really flashy and long transition since it would interfere with the overall experience.

Let Conscience Be Your Guide: Moral Design

The common theme that weaves throughout RJ Owen’s perspective on moral design is to recognize that things co-exist – so, your perceptions affect your actions effect your habits effect your desires which effect your perceptions and on and on. With that framework in mind, then, how can designers explicitly create moral deliverables? The most important issue RJ stresses here is that moral design solves problems and does not create new ones. It does this by being simple and organic – design adds value to the experience and it enhances the audience’s interactions with a tool/product. Good design tells people they are worth treating honestly and with integrity. 

Southby Learnings, Part 1

My colleagues and I are connected via group.me for the duration of SXSW – there’s about ten of us going this year and most of them are visual designers. As we talk about what sessions we plan to attend, I’ve noticed that mine skew much more towards design thinking and theory rather than practical applications. I did want to take the time to summarize some of the best sessions I’ve been to, and how they influence the way I design.

Experience vs Ownership: The Rise of the Experience Economy

By far, my favorite session at Southby so far. Jennifer Hyman, CEO & Co-founder of renttherunway, spoke about the paradigm shift from wanting to own things (i.e. land) to wanting to experience things (i.e. dinner at a new restaurant) and then  broadcast it with our social networks. The important take-away was that as we create access to things we never thought possible, emotional resonance becomes a huge commodity and the service providing this experience must take care to brand themselves appropriately. The example Hyman gave was her own company, where it could have been perceived as gauche and disgusting to borrow previously worn clothing, but instead, the company was able to make it an emotionally valuable and special event.

Something I found interesting was that this talk was titled “Experience vs Ownership” – is it a true dichotomy? At some point, does the eCommerce space encompass both? Do you have the option to buy and become an owner? I hope someone is starting to track data for when someone becomes a experience consumer to a product consumer.

Hacking Cities for a Better, Sustainable Tomorrow

This panel was moderated by Bryan Walsh (Time Magazine Sr. Editor) and the panel consisted of Erika Diamond (Recyclebank, VP Community Solutions), Abhi Nemani, (Code for America, Dir of Strategy), and Rachel Haot (City of New York, Chief Digital Officer). The core topic of this panel was how digital media could help effect change for citizens, and how we could be a part of that movement. At the fundamental level, though, what all these panelists were saying is that data is king. Without data, there is no API, there is no visual representation of what we know. My concern with topics like this is that it always seems to be top-down change; I actually asked the panelists during the Q/A section in what ways are these datasets sustained and consumed within these communities long after hackers get the data they need for study. What I interpreted to be the answer was that those datasets are (hopefully) embedded into a government’s infrastructure (no promises). When I think about the type of design I can practice one day, it’s often in the context of social good or commons – how do we use it to facilitate multi-use spaces, create opportunity for people to engage with each other and access information? And I hope that when I work on these types of issues, design facilitates communities with sustainable resources and knowledge.

Comedy Tech: How Funny Stuff Shapes Our Future

This was a surprisingly great panel consisting of Heather Knight (Marilyn Monrobot, CEO), Joel Warner (The Humor Code, Journalist), Peter McGraw (The Humor Code, Associate Professor of Marketing & Psychology at UC Boulder), and moderated by Alf LaMont (Adler Integrated Marketing, Chief Content Officer). One of the best insights from the session came from Heather Knight, who codes robot comedians (! Her robot can gauge how funny the audience finds it!!). She was talking about her experience in speaking with other comics and trying to see how she could make her robot even more funny and the theme they came back to was that the robot had to be relatable, and in this case, it meant that the robot has to acknowledge it’s a robot. Once that character has been established, we can “relate” to it insofar as we can put ourselves in the character’s shoes. This relates pretty directly to another short session I saw on how likeability gains trust: in essence, the more honest organizations are at revealing themselves, the more trust is accumulated, and the more likeable it is. In terms of designing a system, it means there’s space to be fun and to play with, but also that it can reflect the sensibility of a company. It was a nice reminder that an audience’s perception of your organization effects just how they’ll respond to your attempts at engaging them.

Dell Shop walkthrough

I thought I’d take some time to go through the Dell Shop app I helped design, particularly since the design process helped me realize the lack of best practices surrounding touch devices. This app was created for the Windows 8 OS. (Also, here’s the article  I wrote for uxmag.com on designing for Windows 8.)

Home screen.


This is pretty standard, but one thing you can see is that “Featured” does not have a ‘>’ carrot next to it, indicating that it is not an interactive element. As we go through the site, you’ll notice that Microsoft is really pushing for an exploratory experience, which is super burdensome on the user. And users can be lazy. There are going to be issues.  Also, it begs the question of how you divide up blocks of information – and everything can be a building block for design. For instance, do you differentiate between CTAs and the image? Do you keep those elements separate so that you can manipulate them further at responsive breakpoints?

Search results landing page.


This is tricky – see the touch icons? They’re not interactive, even though it appears that they are; it’s actually one element from the development team’s perspective. The problem is that this image is used in various locations of our shopping hierarchy. In an ideal situation, could that image exist as a separate element from the price stack?  Sure! It could contain a quickview mode since hover does not exists on touchscreen devices. This also means that swipe to select (the standard selection action Windows is pushing) could exist in the same element environment as a tap/touch to view. For clarity: if I wanted to select the XPS 10 product card, I could swipe it anywhere inside the card, including the image, and the action would take me to the next level down (e.g. product details page); at the same time, tapping to select the image also produces another action (i.e. opens up a modal). Having two actions in the same element area, such as the image, is definitely possible, but it means that users will have to understand what each action in a space does, and it also takes extra planning on the part of dev + design. It might also be helpful to note that Microsoft sets some parameters on what elements can have multiple actions (such as scrolling direction) that may affect app/platform design consistency.

Another issue I have been thinking about a lot lately is how a search results page would look on a huge screen. Supposedly, there are no limits, right? We could project this onto any sized monitor or even television set. I believe (and correct me if I’m wrong), that Microsoft has built in some sort of inherent responsive measures, meaning they’ve built their code according to a specific grid scale, and our search results blocks (in this case, the individual card) automatically has breakpoints according to screen size. On a very large monitor, does this make sense? What is an acceptable range of motion for eyes to trek on a screen? On a tablet, it’s easy to swipe horizontally; on a much larger surface area, I wonder if lazy loading information vertically on a dramatically reduced set-width would be easier to scan. Just some thoughts as responsive design takes over my life.

Product Details.


Some cool features that are perhaps not universally beloved on this page. I really enjoy multiple scrolling directions, like what we’ve got going on here with each tab section’s ability to scroll vertically, and then the whole page swiping horizontally to move through the tabs. The product stack on the left is anchored. This is a big no-no says Microsoft, as far as I understand, but e-commerce folks will understand that it’s everyone’s biggest fear that the consumer will get to a product details page and not know how to add the item to cart! (!!!! x10!!). Fear not, stakeholders of the world. I do in fact like the not-at-all subtle ‘this is the product you should buy’ product stack space since it’s a good summary of a lot of potentially confusing tech information. You probably don’t need a product stack for jeans, though, since I can’t see a jeans’ product details’ page taking up more than one screen.

Shopping Cart.


Follows the same pattern as before – cart summary stack stays anchored to the left, user scrolls horizontally to see multiple items.



You can see the anchored left rail is where we do a lot of important functions and proceed forward – this is super important in the checkout process! We don’t want users to proceed without filling out all the right information and we want to save them the stress of having errors returned when there should be immediate error messaging (client-side or soft validation) for simple things like phone numbers or e-mails, as well as client side validation (which is what happens when the user hits the “Review” CTA). I’m wondering how other sites are handling error anchors for long lists (say, your tax forms)? It’s so hard to scan on tablet sized and smaller devices that I’d much rather prefer Microsoft to provide some sort of standard messaging system that is not inline but anchor-linked based (not super applicable to our Dell Shop app but just in general).