Simplify Your UX Through Reduction

I came across this great article, “Simplify Your UX Through Reduction” on UX Matters not too long ago. It’s a great piece on simplifying through reduction, organization and prioritization. It fits right in there with The Zero Interface Approach and Progressive Enhancement.



Designing with color blindness – a color blind designer perspective


, ,

Aaron Tenbuuren, a color blind designer, offers perspective on how we can consider color blindness when designing, as he writes in his recent post,  “Designing For (And With) Color Blindness.”

I didn’t realize (or maybe I forgot the number) that one in ten individuals are color blind. While a relatively small portion of the population, they are still users of apps, sites, experiences. Multiply that number and it leads to a large percentage of potential users/visitors/customers who find using your site or app difficult and/or not worth the effort.

I’ll find nice photographs that have great color palettes, pieces of furniture, paintings, anything. These already established and proven pieces are a great source of color influence.

I appreciate Aaron’s inspiration for color palettes – particularly since it exists in the physical world, outside the online one. Even more so when you consider how he experiences color. Not an absence of (which I previously associated color blindness with), but difficulty in labeling or telling one color from another.

I once had a color blind, color photography instructor in school. We would constantly ask him (to the point of annoyance, I’m certain), to identify colors in our photos, or in the subject matter we were photographing. He’d get it right 100% of the time, which just blew me away. And his photographs were equally as stunning.

There is something to learn from a different approach seeing and experiencing color. Perhaps Aaron and my instructor understand color better then individuals with normal sight do.

Fun with Tables


For those who have maybe read one or two of my posts, you may have noticed that I draw inspiration from current events at my day job. It’s been awhile, but I’ve recently been asked to create a user experience for a table with the following display and functionality requirements:

  1. There is a default set of data that needs to be displayed, but no one seems to know who to ask to find out what the data is exactly
  2. The table can potentially display up to 17 columns (17 data segments)
  3. Users can customize the table view by hiding or revealing columns (data segments)
  4. Users can customize their table view by reordering the columns (data segments)
  5. Users need to be able to filter table data (rows)
  6. The table needs to be responsive, because the site is responsive
  7. We’d already designed a card view (previous iteration of a table scenario with less requirements), so our “new” table scenario needs to have continuity with the card

By now we (as an industry) have more or less figured out how tables on modern web sites (RWD) can render depending on the size of the screen. Such as:

  1. Tables (containing only numeric data) that switch to a pie chart when viewed on a small screen.
  2. Tables (with numeric and text data) that transition to a card or “cell” view when viewed on a small screen. See example.
  3. Tables that hide less important columns for smaller screens (not my favorite approach). See example.
  4. Similar to above, but a drop down menu is available to re-enable hidden columns that can be accessed with horizontal scrolling. See example
  5. Tables that flip x and y axis for smaller screens so the column headers are always visible while the data cells scroll left and right (on a small screen). See example. 
  6. Tables where the left-most column is “locked” in position on smaller screens and the remaining columns scroll, allowing for row-to-row comparison. See example.

Obviously, this isn’t the end-all-be-all list, but you get the idea. There are a lot of solutions out there, and luckily for me, I was able to adapt aspects of them for this particular ask. (With a little e-commerce conventions sprinkled in.)

Small Screen, Card View:
I decided that since a card view already existed (though with only 8 data points displayed), we would take a retail approach and treat this view as an “e-commerce” product card. Most e-commerce sites’ product cards (or tiles) contain an image, title, price, rating stars and number of reviews. In order for the customer to see more information about the product she needs to click through to the corresponding product detail page (PDP). Easy-peasy mental model.

Since each row in our table represented an individual item, and each item just happened to have a corresponding detail page, it seemed a logical solution. Why overcomplicate?

Also, it was decided that there was no point in offering the user the option to customize the information (requirements 3 & 4) while in the card view. The card data was predetermined and order locked, meaning trying to hide/reveal or rearrange the order would be a pointless exercise in futility. If the user wanted to see more item details and info, she could click or tap on the card detail to go to the corresponding detail page.

Medium Screen and up, Table View:
Adding a menu to hide/reveal columns was no biggie, especially for larger screens that had the real estate. Also, a filtering mechanic wasn’t an issue either, since the card view had to be filterable as well. Because we had solved for the question, “WTH what happens on a small screen?” it was just a matter of WTH happens when the medium/large screen gets smaller, but not small screen size.

The biggest issue of course, was the fact that the table didn’t have a set number of columns.  At any point in time a user would be able to hide/reveal/reset columns and rearrange the order of columns to suite their browsing preference. Regretfully, there was no user data to help inform any user scenarios, so we winged it.

It came down to two relatively obvious options: 1) the entire table is scrollable left-to-right (once the screen was reduced for overflow to kick in), advancing one column at a time, or 2) the left-most column would be “locked” and the remaining columns would scroll horizontally.  We went with option 2.

I really like Option 2 because it’s a brilliant solve for a table that has rearrangeable columns. Users can decide what information is most-to-least important that needs to be visible. As the screen sizes reduces, the most important information will remain visible, and secondary information accessible via horizontal scrolling.

We also decided to implement the ability to export the whole kit-and-kaboodle to Excel, just in case a user had hundreds of entries.

Fun with Excel.

UX Mag: Modals on Mobile: How to use them wisely


, , ,

Chris Wigley of UXMagazine gives succinct review of the current use of modal windows use in small screen design. He rightly reminds of us of when and how modals should be used. If the content was planned for, then make it right, instead of a modal hack job.

Modals are becoming the dumping ground for content that doesn’t fit anywhere else, often because of issues with content planning. Modal windows should be applied only to meet the following objectives:

  1. Interruption: force the user to make a decision or complete a task within an important workflow
  2. Feedback or Correction: Confirming decisions: “Confirm you are happy with your decision” moment.
  3. Deep Dive: Focusing on a single piece of content, such as an image, article or video.

Read the complete article here.

So What Counts as Data? 6 Myths about Data-Driven Design.


In April of this year I attended the UXIM15 Conference in Salt Lake City, UT, where I sat in on Jared M. Spool’s keynote: “Is Design Metrically Opposed?” The basic premise of Spool’s keynote is this: Google can’t tell you what the emotion, the human behavior, the mindset that influenced the action that resulted in the analytic. The human experience needs to be measured as well in order to create a holistic experience.

Since then, I’ve had a number of conversations with UX peers about how much power we (as a profession) give data when it comes to making user-centered design and experience decisions. While doing some additional research, I came across an article on UXMag on this very topic: “6 Myths about Data-Driven Design” by Pamela Pavliscak. I’ve summarized below; read the full article here.

So what counts as data…and what will inform design in a meaningful way?

Myth 1: Data Means Numbers
Numbers represent the actions of real people with complicated lives. But even the most organized sets of numbers don’t answer a lot of questions we still have about the user experience…why people take action or why they don’t, or how they felt about it, or what expectations they bring to the experience.

Because qualitative insights are not numeric, they are often not considered data.

Myth 2: Data Is the Objective Truth
Because quantitative data is typically tallies actions and those actions are tallied by software, it makes quantitative data seem like hard fact. Even if data is big, it does not mean it’s objective. Bias is inherent in any data set because datasets are created by humans who interpret them and assign them meaning.

Big or small, not data is perfect. Good data describes its biases, and always provides context.

Myth 3: Bigger Is Always Better
When we think bigger, we tend to think about tallies; the volume and velocity part of the big data equation. But big data is also about variety, and that means diverse sources. We have to get our data working together in a way that isn’t all about back-end integration. In other words, creating meaningful categories (metrics) to evaluate, understand and track.

Broader, not bigger, is the better.

Myth 4: Data Is for Managers, Not Designers
When using data to inform design, there are three ways of looking at things: proving, improving and discovering. Because different teams refer to different types of data, they may be discounting or not aware of data of other teams.

Data is not just about proving who is right or wrong. It’s about making improvements and discovering new possibilities.

Myth 5: Data Kills Innovation
Data is seen as the antithesis of innovation, specifically in three ways:

  1. Most data is backward looking. It’s not easy to make predictions based off of discovered patterns and trends.
  2. Data is tactical rather than strategic. It’s a good way to tweak a design element, but not for creating an amazing experience.
  3. Data, especially analytics, seems to skim the surface. Data does not work well for informing design, because it lacks information about motivation, expectations, perceptions or emotions.

Myth 6: There Is a Right Way to Use Data to Inform Design
As of now, there is no one canonical way that works for every team and organization.

A few guidelines:

  • Use data from a variety of sources
  • Include numbers and context.
  • Make sure data is sensitive to the complexity of the human experience.
  • Use data to track changes over time, rather than just proving who is right or wrong.
  • Decide on meaningful categories to make sense of the data and tell a story about the experience.
  • Develop a way to share and discuss data.

Mobilegeddon – Adapt or Die.



On April 21 Google launched an algorithm, referred to as “Mobilegeddon,” that intended to favor websites that were “mobile-friendly.”

Starting April 21, we will be expanding our use of mobile-friendliness as a ranking signal. This change will affect mobile searches in all languages worldwide and will have a significant impact in our search results. Consequently, users will find it easier to get relevant, high quality search results that are optimized for their devices.

People using Google to search while on their mobile devices might find their favorite sites ranked lower in the results than before because the specific site is not optimized for their devices.

Many argued that the algorithm could mean huge losses for businesses that hadn’t updated their websites to be accessible for mobile devices. But let’s face it, the era of desktop-only experience is gone, and if a website isn’t accessible or is difficult to use on a small device, then there will be no repeat visits, no customers, no money. Sad face.

{Aside: The data out there suggests that the sooner businesses adapt for mobile, the better considering:

91% of Americans own a mobile phone
Mobile now makes up 20% of all web traffic, and it’s growing
68% of Americans access the web from a mobile device
33% of mobile, web capable Americans access the web solely through a mobile phone

Not to mention, it’s no secret that Responsive design is Google’s recommended site design approach. }

While the results of the algorithm were slow to see after the first week, it would appear that business that do not offer a “mobile friendly” site are clearly seeing their mobile search results rank drop. While the algorithm doesn’t affect any desktop searches, website TechCrunch found that 44% of Fortune 500 companies failed Google’s mobile friendly test. That’s a huge number of large businesses that have completely ignored mobile/small screens.

Adapt or Die.

Modern web design is responsive (with a lower case r)


, ,

A great article by Nate Voss of VML about how we need to start thinking about modern web design. Nate makes a fantastic point that as users of the modern web we have come to expect web experiences to just work, no matter the device or platform.
This expectation of connectivity and accessibility anytime and anywhere leads to the necessity that modern web design needs to be responsive (lower case “r” is intentional). “Responsive” (with a capital “R”)  is a viable technique among many, such as Adaptive, Progressive Enhancement, RESS–aspects of which enable us to achieve the best, most accessible experience for the end user.

Read on at:

User Experience Mobile Immersion Conference 2015 – Recap


, , ,

I recently attended the 3-day UX Mobile Immersion Conference (UXIM15) in Salt Lake City, Utah, hosted by UIE (User Interface Engineering). If you’ve ever had the opportunity to attend any previous UXIM Conferences, then you know how highly rated the conference is for the quality of the speakers and topics they cover. Each speaker is literally household name in the UX/UI realm and their workshops and talks are of the highest caliber.

Never been to the UXIM Conference? I’ve missed a few years, and it’s a bummer to feel left out.  Hopefully the recap below can give you a glimpse of wisdom and smarts from this year.

Kill your assumptions
Throw away all your working assumptions about input types, devices, screen sizes and user tasks because the lines are becoming more and more blurred. Technology, once iterating every 10 years is on course to iterate every 2-3. Instead of trying to keep up (and losing your mind in the process) in an industry of unpredictability, a more strategic, sane course of action is to approach web design with simplicity, accessibility and performance in mind by using tested, reusable components and patterns.

Input does not equal device does not equal input
We may no longer assume that a certain screen size, input type, or hardware equates to a particular experience. “Desktop” no longer equals a keyboard and mouse any more than a “Tablet” does touch. Moreover, how will web pages change with voice or gesture controls that sync with your devices? Input is not detectable in a reliable way – it is transitory and dynamic.

Device does not equal task does not equal device
“Mobile users will do anything and everything desktop users do, provided it’s presented in a usable way.” — Brad Frost (@brad_frost)

Assuming that a user will or won’t do something on a particular device, specifically a small screen, will get you into serious crap. It wasn’t too long ago we believed users wanted less content or only specific content on their mobile phones because mobile meant the user was on the go. We know now mobile users kill time on their devices while standing in a line or on the couch in front of the TV. Take note: 30% of global ecommerce sales come from mobile.

Device classes aren’t definitive anymore
“These days, trying to draw a line around device classes (mobile, tablet, desktop) is as fleeting as drawing a line in the sand.” — Jason Grigsby (@grigs)

Defining device classes these days is like trying to definitively classify a Labradoodle as either a Labrador or a Poodle. Desktop to tablet to mobile dimensions now either overlap or are separated by just a few pixels. Besides, what class does a watch fall into, or a refrigerator? The windshield of your car?  It’s best to think about devices by size (XS, S, M, L, XL) instead of by class.

Performance is a Design Requirement
“Being Responsive from a layout perspective should not preclude us from being responsive from a performance and interaction perspective.” –Scott Jehl

Performance may appear to be “invisible,” but it can have a direct correlation to whether or not your user decides experience your site. Performance needs to be an essential design principle, not just a technical responsibility. Good performance is good design.

Some sobering thoughts:

  • 1.97mb – that’s the average page size of today’s web.
  • 74% of mobile visitors will abandon a site if it takes longer than 5 seconds to load.
  • 85% of mobile users expect mobile sites to load as fast if not faster than desktop sites.
  • The top e-commerce sites are 22% slower than last year; user data confirms that slow sites result in lost revenue. A slow loading site is one of the primary reasons for site abandonment.

Don’t add the unnecessary in the first place.
If the quickest way between A and B is a straight line, Stephen Hay succinctly states that a lot of experiences out there have (consciously) put a lot of crap between A and B, making for some ridiculously complicated experiences.

The Zero Interface Approach
To help achieve the universal of goal of getting from A to B as quickly as possible, Stephan Hay uses “The Zero Interface” approach: UX/design starts with zero-base. You begin with nothing, what you need is added, stress tested, and refined. Concurrently, you ignore client/designer/developer baggage such as competitor patterns, sunk costs, design trends, pattern libraries because baggage focuses on existing solutions.

The goal of Zero Interface is to focus on solving the problem, versus applying existing solutions blindly without understanding the root of the issue. It forces you, at every step (UX, Design, Dev) to examine each component you add and implement to ensure that it is part of the solution, not adding complication. Train yourself to think, with each addition, is this one thing to many?

Responsive Web Design and Progressive Enhancement
“We in the web world Rube Goldberg everything.”  – Stephan Hay (@stephen_hay)

Responsive web design isn’t just about making web pages fluid and displayable across multiple screen sizes; not “one size fits all.”  Modern web design is about ensuring that design and technology aren’t keeping users from accessing the content they want or need. This means considering and solving for a vast array of scenarios, like devices that may just be a few months or a few years old, disabled script, unsupported touch, older browser compatibility, while simultaneously creating experiences for current technology and devices yet to exist.

Keep in mind: 68% Americans access the web from a mobile device, and ⅓ of mobile web capable Americans access the web solely through a mobile phone. This means if a user can’t access your content, your information, your products or services on mobile, then you don’t exist for those users.

“We have a moral obligation to make sure content and information is accessible across devices and inputs.” — Jason Grigsby (@grigs)

To achieve broader accessibility web design experts Jason Grigsby, Brad Frost, Stephen Hay (to name a few) recommend Progressive Enhancement: begin designing for the most baseline experience–a small screen, slow data plan, no touch capabilities. Once the baseline experience is determined, layer on enhancements such as visual aesthetics, interactivity, gestures–stuff more modern browsers, technologies, and devices will detect and render. The “fallbacks” created by the baseline considerations have two advantages: 1) content and information is accessible 2) the site potentially won’t fall apart with when the next greatest thing comes along. With proper planning and implementation, the site will be useful and usable in an industry of unpredictability, diversity, and disruption.

Atomic Design
Along the lines of RWD, Brad Frost uses an approach coined, “Atomic Design.” Atomic Design is a set of 5 principle stages that more or less occur concurrently: atoms, molecules, organisms, templates, pages. The goal of an Atomic Design approach is to bring together individual elements (atoms) to form a component (molecule) that when combined with other components creates a larger organism. These organisms, or patterns, are placed into content frameworks (templates) to test the pattern across multiple scenarios. As more and more patterns are added to the template, the page takes shape.

The benefit to Atomic Design is that it allows the team to focus on individual design patterns instead of trying to solve for a page of patterns all at once. The content framework infers where solutions will eventually be implemented (placeholders) with finished patterns introduced as they are designed and tested.

Key to the success of this approach is to get into the final environment (the web) as soon as possible; to stop thinking of websites as set of individual pages, but as a system of components combined together. With the near limitless number of devices, breakpoints, resolutions and technology, it is nearly impossible to create a mockup for every breakpoint in photoshop (not to mention, what happens when there’s an edit that needs to made across all the pages). Additionally, the static page is not an accurate representation of the final experience, which is why it is crucial to move out of static comps to code once the design aesthetic has more or less been established.

Is Design Metrically Opposed?
“Bounce rate is the most cited metric for pushing a content agenda.” — Jared M. Spool (@jmspool)

Measure: Something we count
Metric: A measure we track
Analytic: A measure software tracks
Missing: Are these useful?

All too often metrics and analytics result in inferences that are then translated into solutions without further examination. Google Analytics can’t tell you why;  what content is the most useful? What you should do to improve content?  Why people are spending money? Why did someone click?

Qualitative finds should drive our quantitative research; quantitative research should be focused on user frustration. By simultaneously overlapping a journey map of observed user frustration (and delight) of corresponding metrics, we are more likely to pinpoint and solve for the actual cause of user frustration, as opposed to a design decision based in inference. In short, user experience needs to own behavioral science.

See you at UXIM16!

It’s an… Icon? A check box? Open/close mechanic? Navigation element? All of thee above? Please let this be broken.

I am a huge fan of (Ann Taylor) LOFT. The price point (everything eventually goes on sale within a week or two), quality, and style suite my budget and fashion sense just fine. I have a LOFT card to earn points towards more clothing, and I submit payments online.

The LOFT recently updated the account center where you manage your payments, balance, account activity, etc, because when I logged in today it announced the new account center “is even better.”

Yes, most of it’s cleaner and more suitable for multi-device and screen accessibility. But for whatever reason, there are square shapes showing up for almost everything, except text. And I mean everything.

The use of the square is so widespread I can’t be certain if something is broken, or whomever just got carried away. It’s a static visual, it’s part of the navigation menu, it’s part of the interactive features and selection mechanics in the UI. I’m really hoping something is wrong with their image server.

The worst part is that it just broke nearly every mental model I have when it comes to a square. Square = check box. Click/tap = select/unselect. I thought I was losing my mind. I kept tapping on my iPad expecting a check to appear.

Post Log-in Experience:
After the log-in screen I was presented with an overlay introducing the new account center. Initially, I wasn’t paying attention to the use of the square shape in this window. Not until I went to check the box “Don’t show me this again.” (See below).

Instead of a “check” in the box (or square), I got a square–in the box (or square). Is it broken or is this intentional? Good Lord, I hope this is broken.
Home Page and Menu:
LOFT_Home_1It just keeps getting worse. There are squares everywhere, and the intended use or purpose is a mystery to me. In the menu to the left of the page, the square is not used to visually demonstrate the “on state” (like filled in). Instead, a pink, vertical line is the indicator.

The three smaller gray squares in the upper right hand corner are navigation elements to the My Profile section, Message Center, and Help and Customer Care. I didn’t even know where I was going to end up until the page loaded. There is no label on hover state or otherwise.

When I click on the square next to the label “Recent Activity” it just rotates and reveals inline my recent account activity.

And at the top of the screen I don’t even know what the white squares in the pink circles are supposed to be.

Make a Payment:
The shot below is from my tablet, which is where I initially encountered this experience. Each time I tapped on the square, I kept waiting for the check mark. I must have tapped on “Other amount” half-a-dozen times before it occurred to me that the change in background color (light gray to dark gray) was the visual indicator for “selected.” Holy crap, is this intentional?

Not to mention, in the Select Checking Account and Select Payment Date columns, there are selections with TWO squares. What on earth are they meant to represent?

The Aftermath:
I managed to make my payment. (I logged back in this morning to double check). But the scenario raises several questions.

The first question, obviously: is the use of the squares for all static and interactive UI assets intentional? I mean, was there a cognitive decision to use the shape to represent nearly everything?

Question number two: how many UI icons and assets are really necessary? A squint test on this page reminds me of a shooting gallery with lots of targets.

Final question, did this get a scrub and Q/A before it went live?

I really, really, REALLY hope something is temporarily wrong, because overall it’s an improvement to the previous experience.