Skip navigation

<a href=

warning: Creating default object from empty value in /var/www/vhosts/ on line 33.
Original author: 
(author unknown)

A local shop is part of an ecosystem — here in England we call it the High Street. The owner of a local shop generally has no ambition to become a Tesco or WalMart. She’d rather experience steady growth, building relationships with customers who value what she brings to the community.

People often mourn the disappearance of their “local shops.” I’m sure it is the same in many parts of the world. Large chains move in, and the small local businesses, unable to compete on price, close. As the local shops disappear, customers win on price, but they are losing on personal service.

At local shops, they know their customers by name, remember the usual order of a familiar face, are happy to go the extra mile for a customer who will come through the door every week. It’s most often the business owner who is behind the counter filling bags and taking money.

This direct and personal relationship with the people that their business serves quite naturally provides the local shop with information to meet the needs of their customers. Customers come in and ask if they stock a certain product, one that they have seen advertised on TV; or that is required for a recipe on a recent episode of a cooking show. The local shop owner remembers that three people asked for that same thing this week, and adds it to their order. We’re not dealing with the careful analysis of data collected from thousands of customers here. The shop owner could name the customers that asked for that item — she will point out the new stock to them next time they come in.

One single store is unlikely to attract much footfall, so the business of one store relies on being part of a vibrant community. Within this community the local shops and tradespeople support each other. A customer pops into a store and mentions while paying that they are having trouble with their car; the shopkeeper recommends the garage down the road — “don’t forget to tell Jim that I sent you!”

As the co-owner of a bootstrapped digital product, I often feel like we are that local shop on the web. I know many of our customers by name, I know the sort of projects they use our software for. I follow many of them from my personal account on Twitter. I love the fact that they come to speak to me at conferences; that they feel they know us, Drew and Rachel from Perch. This familiarity means they tell us their ideas for the product, and share with us their frustrations in their work. We love being able to tell someone we’ve implemented their suggestions.

We’re also part of this ecosystem of small products. Unlike the village shops we are not bound together by location, but I think we are bound together by ethos. When selecting a tool or product to use in our business, I always prefer those by similar small businesses. I feel I can trust that the founders will know us by name, will care about our individual experience with their product. When I get in touch with a query I want to feel as if my issue is truly important to them, perhaps get a personal response from the founder rather than a cheery support representative quoting from a script.

This is business. We make a thing, and we sell it at a profit. The money we make enables us to continue to create something that people want, and to support our customers as they use our product. It also enables us to support other people who are running businesses in this digital high street we are part of, from the companies who provide the software we use for our help desk and our bug tracking system, right through to the freelancers who design for us.

I am happy with my small shopkeeper status. I talk and write about bootstrapping because I want to show other developers that there is a sane and achievable route to launching a product, a route that doesn’t involve chasing funding rounds or becoming beholden to a board of investors. I love the fact that decisions for my product can be made by the two of us, based on the discussions we have with our customers. If we had investors hoping for a return on their investment, it would be a very different product by now, and I don’t think a better one.

I think it is important for those of us succeeding at this to talk about it. As an industry we make a lot of noise about the startup that has just landed a huge funding round. We then bemoan the disappearance of products that we use and love, when the founder sells out to a Yahoo!, Twitter, or Google. Yet we don’t always make the connection between the two.

Small sustainable businesses rarely make headlines. So we, the local shopkeepers and tradespeople of the web, need to celebrate our own successes, build each other up, and support each other. I’d love there to be more ways to highlight the amazing products and services out there that are developed by individuals and tiny teams, to celebrate the local shops of the web. Let’s support those people who are crafting small, sustainable businesses—the people who know their customers and are not interested in chasing a lottery-winning dream of acquisition, but instead are happy to make a living making a good thing that other people love.

Your rating: None
Original author: 
(author unknown)

For ideal typography, web designers need to know as much as possible about each user’s reading environment. That may seem obvious, but the act of specifying web typography is currently like ordering slices of pizza without knowing how large the slices are or what toppings they are covered with.

If someone asked me how many slices of pizza I wanted for lunch, I would probably say it depends on how large the slices are. Then—even if they told me that each slice was one eighth of a whole pie, or that they themselves were ordering two slices, or even that the slices were coming from Joe’s Pizza—any answer I might give would still be based on relative knowledge and inexact assumptions.

Such is the current situation with the physical presentation of responsive typography on the web. The information at a designer’s disposal for responsive design is virtually nonexistent outside the realm of software. Very little knowledge about the physical presentation of content is available to inform the design. The media query features of today can only relay a very fragmented view of the content’s actual presentation, and related terms from CSS are confusing if not downright misleading.

The immeasurable pachyderm

Among all the physical qualities of web typography, the elephant in the room is the issue of size. I’m not talking about em or rem or “reference pixels” ¹ or even device pixels. I’m talking about real, actual, physical, bona fide, measurable, size!

It’s ridiculous that we can send robots to Mars yet it’s still virtually impossible to render a glyph on a web page and say with confidence: “If you measure this glyph on your screen with a ruler, it will be exactly 10 millimeters wide.” Although actual physical size isn’t always the most important factor in web design, in some cases it is critical. For example, consider content for partially-sighted or low-vision readers: the ability to tweak designs according to physical sizes would enable designers to make conscious design decisions with much more sensitivity to how the type is actually being seen. And even where physical sizing is secondary to relative sizing, why shouldn’t we nevertheless be able to factor in physical size when establishing the relationships between different elements?

Physical considerations ≠ print design

I don’t believe web typography should be a screen-based imitation of print typography. One of the greatest benefits of web typography, and web design in general, is that it is flexible, adaptable, fluidly adjustable, without being locked into any one specific configuration. However(!), that doesn’t mean web designers should be forced to design without any means to address the issues of physical presentation. On the contrary, responsive design will not reach its full potential until it allows the ability to respond to the very important physical variables of digital media.

Please pardon the cliché, but when it comes to typography, on screens or otherwise, size matters. Physical size affects optical issues that change how the eye and brain process typographic images. Not surprisingly, typographers and typeface designers have been compensating for optical size-related issues as far back as Gutenberg.

You can’t expect a paragraph of type with the same relative line-height, column width, letter-spacing, and glyph proportions to function just as well on two different displays that have the same number of pixels but completely different physical sizes. It’s great that designers can adjust proportions between typographic elements if the canvas varies in relative size, but any such compensation is still based on guesswork and assumptions about the physical size of that canvas. When people disagree about the size or spacing of type on a website, there’s a very good chance that their opinions are based on completely different physical manifestations of the same content, even if their software and settings are identical.

Resolute resolution, absolute absolution

One of the most crucial factors in the size equation is resolution. And when I say resolution, I don’t just mean “how many pixels is this?”, or even “how many device pixels is this?”, but also “how large are these pixels?”

This is very different from the W3C’s “resolution” media feature in the current draft of the Media Queries Level 4 spec. You will note that the spec refers to resolution in terms of “CSS ‘inches’”—the quotes around “inches” are theirs, implying that they are not actually inches at all.

For an example of why physical resolution matters, imagine you are rendering text on a digital billboard with a physical resolution of one pixel per inch (1 PPI). Now imagine you are rendering the same text on a 200 PPI mobile device display. Even if you knew the actual number of device pixels that would be used to render your type (which itself is difficult to do with confidence these days), you would want to treat the two compositions very differently, both in terms of the typeface as well as typographic layout. The billboard type would likely require less space between letters. The letterforms themselves would benefit from narrower proportions, and could endure a higher ratio between thick and thin strokes. The type might even require different colors to optimize contrast at that size. These are all basics of typography and typeface design.

Unfortunately, in the current landscape of media query features, there is no way to know the difference between 16 device pixels on a crude LED billboard and 16 device pixels on a high-density mobile display. Heck, there isn’t even a reliable way to know if your type is 16 device pixels at all, regardless of how large the pixels are!

Pixels still rule, for better or worse

I know what some em-based enthusiasts might be thinking: “But you shouldn’t be specifying type sizes in pixel units to start with! All type sizes should be spec’d abstractly in relation to each other or a base font size!” However, in the current world of web typography, no matter what unit of measure you use to spec your onscreen type sizes—em, rem, px, pt, in, %, vh, or whatever else—at the end of the line, your specification is being mapped to pixels. Even if you leave the base size of your document to the defaults and specify everything else with em, there is still a base size which all other sizes will ultimately refer to, and it is defined in pixels.

This is because, currently, the only unit of measure that can be rendered onscreen by any operating system with absolute confidence is the lowly pixel. Until we have media query features that allow us to spec for situations like:

@media (physical-resolution: 1device-pixels-per-physical-inch) { … }


@media (device-width: 10physical-centimeters) { … }

… any compensation for physical size is based entirely on rough guesses about the devices our content will be presented on.²

It’s a complete fallacy that the official CSS spec allows so-called “absolute” units of measure like inches, points, and centimeters to be mapped to anything but actual physical units. Ironically, previous versions of CSS treated these things as you would hope and expect, but a change was made “because too much existing content relies on the assumption of 96dpi, and breaking that assumption breaks the content.” Call me idealistic if you will, but I am more of the mind that a spec should be written based on what is best for the future, not to cater to things that were made in the past.³

Getting physical

Any ability to leverage physical variables for web design will require a joint effort by several groups:

  • Device manufacturers will need to provide APIs that can inform the operating system—and, by extension, web browsers and web designers—of the actual physical properties of the hardware being used to present content to the user. Some device APIs are already beginning to show up in the world, but there is a long way to go before functionality and adoption are anywhere near dependable.
  • Standards organizations—the W3C in particular—will need to establish specifications for how to reference physical properties when formatting content. They will need to update (or at least augment) their existing “absolute” units of measure to be more meaningful, so they are more than just multipliers of sizeless pixels.
  • Software manufacturers will need to implement support for new specs relating to physical media features. Browsers are the most obvious software that will need to implement support, but the biggest challenge might be in getting native support for device APIs in operating system software.
  • Type manufacturers and type services will need to provide more diverse ranges of typefaces that have been optimized for a variety of physical properties. Ideally, many of the needed variations could even be provided on the fly using a broader approach to the ideas of font hinting.
  • Web designers and developers, last but not least, will need to build their sites to respond to physical properties, leveraging all variables to the benefit of their users.

Size and resolution are just the tip of the iceberg of physical variables that could be considered when improving web typography. Things like viewing distance, ambient light, display luminance, contrast ratio, black levels, etc., etc., could all be factored in to improve the reading experience. Even the ability to know some variables within the realm of software, like the user’s rendering engine or the presence of subpixel positioning, would go a long way toward helping web typographers design a better reading experience.

In the meantime, I’d love to see more of the players mentioned above start to at least experiment with what’s possible when physical features can be specified, detected, and factored into responsive designs in structured, meaningful, and predictable ways. Until we can do that, we’re all just ordering pizza without knowing exactly what will end up on our plate.

Your rating: None

By Dominique Hazaël-Massieux: People used to stare at me and laugh, back in 2005 when W3C launched its Mobile Web Initiative to advocate the importance of the web to the mobile world. Now I am the one smiling much of the time, as I did most recently during the 2013 edition of the Mobile World Congress (MWC) in Barcelona, one of the largest events to focus on mobile devices and networks.

This year W3C had a huge HTML5 logo splashed across its booth to emphasize the impact of the Open Web Platform across industries and devices. But the real adoption story was told by the HTML5 logos prominent at many, many other booths. The web has gained real visibility on mobile, and we should all be smiling because we are all getting closer to a platform for reaching more people on more devices at lower cost.

MWC 2013 also confirmed that HTML5 has broken out of the browser. We are seeing more and more HTML5-based development platforms, such as PhoneGap, Windows 8, Blackberry, and Tizen. Mozilla’s big announcement at MWC 2013 centered on FirefoxOS, Mozilla’s mobile operating system entirely based on web technologies. W3C and Intel partnered to create a T-shirt that says “I See HTML5 Everywhere.” And indeed, I do.

The challenge of mobile

Not only has the web a big role to play on mobile, mobile has also a key role to play for the web. As more and more of our connected interactions start or end on mobile devices, we must ensure that the web platform adapts to our mobile lives. I believe this is critical for the future of the web.

For many years W3C has designed technology to make the experience of web users on mobile ever more rich, adapted, and integrated. For example, CSS media queries provide the basis for responsive web design. There is already a lot for mobile, and a lot more is coming. To help people follow all the activity, every quarter I publish an overview of web technologies that are most relevant to mobile.

These technologies are the tools designers can rely on to build the user experience they need. But technologies are only a small piece of the puzzle when it comes to making the web user experience work on mobile devices. The number of A List Apart articles about mobile development provides a clear sign that this challenge is driving creativity in the design community. Responsive web design, mobile first, future friendly, and just-in-time interactions are some of the trends that have resonated with me over the years. The creativity is fantastic, but we still want our lives to be easier. Where web technologies do not yet provide the hooks you need to practice your craft, please let us know. Feel free to write me directly:

Closing the gap

Another challenge that we, the web community, face on mobile is the amazing energy devoted to native development.

The web has displaced a lot of the native software development on traditional computers; on mobile, the reverse trend has happened. Content that users had enjoyed on the web for years started to migrate to native applications: newspapers, social networking, media sharing, government services, to name a few. And to add insult to injury, a number of these content providers are pushing their users away from their website toward their native application, with obtrusive banners or pop-ups.

It is unclear where the world is going on mobile: some statistics and reports show a strong push toward moving back to the web (e.g., the recent Kendo UI survey), while others argue the opposite. What is clear to me, though, is that we cannot afford to let mobile become a native-entrenched ecosystem.

What has made the web unique and popular in so many hearts is not the technology (some great, some terrible) nor even the ubiquity (since interoperability can reduce it). I believe the much more fundamental importance of the web comes from its structural openness: anyone can publish the content they see fit and anyone can participate in defining the future of the web as a platform.

Native ecosystems on mobile have historically been very closed ecosystems, under the control of single commercial entities. A world where the majority of our information and infrastructure would be trapped inside these ecosystems is not something we should accept lightly. Mind you, I appreciate the innovations spawned by these platforms, but we need to encourage the cycle where innovations become standards, and those standards prime the platform for the next innovations.

Of course the best way to shift the balance to the web is to make the web the best platform for mobile. Achieving this will require ideas and energy from many people, and web developers and designers play a critical role in shaping the next generation of web user experiences. I am leading a focused effort in W3C to assess what we can and should do to make the web more competitive on mobile, and welcome feedback and ideas on what the missing pieces in the puzzle are.

Beyond mobile

I believe a key part in making the web the “king of mobile” is to realize that mobile devices are a means to an end. In our connected world—computers, phones, tablets, TVs, cars, glasses, watches, refrigerators, lightbulbs, sensors and more to come—mobile phones will most likely remain the hub for while. The only platform that can realistically be made available on all these devices is the web.

We have a unique opportunity to make the Open Web Platform a success. I realize getting it right will not be trivial. Building user experiences that scale from mobile (or watches!) to TV is complex. Building user experiences that adapt to these very different type of interactions will be hard. Matching the needs from users in a growing diversity of contexts will make us cringe. Creating user experiences that abolish the devices barrier (as I explored some months ago) is guaranteed to create more than a few headaches.

But there is unprecedented momentum to create an open platform for the planet. And that has me smiling a lot.

Your rating: None

Close your eyes and touch your nose. How did you do it? How did you sense where your hand was, and direct it to the right point? You’re not using sight, hearing, taste, smell, or touch (except right at the end). Instead, you’re relying on proprioception: the sense of your body’s position in space, and the position of various parts of the body in relation to each other.

Proprioception—sometimes regarded as the sixth sense—helps us understand our orientation, coordinate our movements, and make sense of the world around us. It helps us turn space into place, turning an abstract set of dimensions into an environment that we understand and can manipulate accordingly.

Digital space, of course, doesn’t offer physical proprioception, so it falls to designers to provide cues about the user’s position. The most obvious way to do this is with explicit visual components. Throughout the web’s history, we’ve adopted many physical metaphors for these navigational building blocks: breadcrumbs, navigation menus, and homepages have become familiar to millions of users.

Unfortunately, these explicit navigational components are difficult to handle in the responsive era. They don’t fit well on small screens, and are falling out of favor as recent trends demand their deprecation in the interface.

To revitalize these components, enterprising designers have started to explore new small-screen navigation patterns. These are a useful start, but to help users navigate comfortably on small screens, it’s worth looking beyond pure signposting. We can bring the sense of proprioception into the digital world by focusing on the transitions between screens. Here are just a few examples.

Horizontal for hierarchy

By (largely unspoken) Western convention, right is the direction of horizontal progression–just think of the number line or written text. Left is subsequently seen as backward, even regressive. It’s no accident that the Latin for left–“sinistra”–found its home in the English language as “sinister.” This historical prejudice may upset my fellow lefties, but it offers a helpful convention for digital product designers.

Horizontal transitions are seen throughout smartphone operating systems. In this example from the iOS Music app, as content moves right to left, the user appears to move right, and thus down the hierarchy. He can then move left to return back up the tree. The iOS designers use directional indicators to back up these transitions. Controls that lead down the hierarchy are given right arrow shapes, and those that lead up (or “Back”) point left. Position further reinforces the concept, with right arrows placed on the right, and left arrows on the left.

The design works by offering users a mental origin—the home screen–then using transitions to establish a sense of displacement from that origin. Every step right takes the user farther from home, every step left brings them closer. This effect therefore needs a clear anchor or landmark against which the user can orient. The home screen of an app is usually at the top of the tree: the horizontal hierarchy effect isn’t so successful if the user is thrown straight into the middle of a complex hierarchy.

Perpendicular for modals

Not every action in an otherwise hierarchical structure sits within the hierarchy. Modal actions like warnings, “select account” disambiguation screens, or login flows need different treatment. It’s useful here to use perpendicular transitions that go against the horizontal flow.

Using the y-axis (i.e. vertical transitions) is the most common choice. The Twitter mobile app uses it, for example, for composing new tweets, an activity that breaks out of the timeline/detail view hierarchy.

The modal window slides into view from the bottom of the app. This doesn’t suggest progress within the hierarchy. Instead, it feels disruptive: the screen intrudes into the usual flow. Once the user has completed or dismissed the screen, it disappears from whence it came, and we return to horizontal business as usual.

Flip for configuration

An alternative for non-hierarchical interactions is a flip.

The physical metaphor of the flip gives it a slightly different feel. This isn’t interruption so much as configuration: reaching around the back of the screen to play with the wiring. As such, a flip is ideal for Settings screens, where the options chosen directly affect the initial view. In this clip, the Me screen flips to allow the user to choose their preferred account.

Card swap for entering a new hierarchy

In the card swap transition, the active screen moves aside and then behind another, like a deck of cards being cut.

This transition feels more absolute than the others. Just this simple piece of animation wipes the slate clean and tells the user she’s moved to a new structure, or even a new app. As such, it also feels less reversible. The user can’t simply press Back to undo this switch. The only way to reverse is to repeat the action, bringing the other screen back to the foreground.

These four transitions alone communicate significantly different navigational patterns; yet transitions are frequently overlooked in favor of bulkier on-screen components. Intelligent transitions could make a significant difference to your app’s user experience. If they support and confirm your app’s structure, your navigational model can fall into place more easily. However, if your transitions conflict with on-screen components, you may just stir up a vague feeling that something’s not quite right.

The rise of small screens rewards time spent on the small details. When on-screen territory is at a premium, the gaps between screens become far more interesting.

Your rating: None

Raise your hand if you’re looking at this in an RSS reader right now. Or an orbital content app like Readability, Instapaper, or Pocket. Or if you got here by clicking a link on Twitter or Facebook, or from a search engine listing, or any other means that didn’t involve typing “” directly into your browser’s address bar.

Congratulations, you’re part of the “superdistribution.” (You can put your hand down now.)

In Post-Industrial Journalism, a recent report from Columbia’s Tow Center for Digital Journalism, co-authors C.W. Anderson, Emily Bell, and Clay Shirky use the term while setting out to diagnose the major challenges facing traditional newsrooms and publishers.

They note that digital content continues to find novel new ways to wander away from its various points of origin. Tools that give users ever more control over formatting, timeshifting, and sharing will continue to proliferate. This steady growth runs directly counter to the simple, one-to-many broadcast model enjoyed by many publishers in the past—one where it was relatively easy for them to control the venue and keep tabs on the conversations happening around their content.

The report’s authors note:

The old model, where most users visited a home page or used a mobile application tied to a single organization, will continue to lose ground to superdistribution, users forwarding relevant materials to one another. We already live in a world where the most widely circulated stories acquire audiences that dwarf the median headcount [of the original site]. Adapting to this increasingly unequal distribution will require that most organizations get better at working with their users to filter and pass on relevant material.

Put another way, digital content lives a life beyond the URL where it was born, one whose boundaries keep getting broader. For publishers still geared towards the far simpler distribution of the past—a model that requires content remain exclusively bound to its original context—this represents a problem. But those publishers need to take note of what’s going on here or risk missing out in a big way.

Consider that these users actually care enough about a particular piece of content to save, share, repost, or reformat it. These are the folks actually making use of content. Just as piracy can be an indicator of thwarted demand, this behavior is an indication of affinity. It’s telling publishers who their most motivated, digital-savvy readers are, and what they’re actually interested in. Rather than trying to hobble this behavior, site operators should be embracing it, reaching out to build partnerships and tools that bridge the gap between these services and their own offerings.

Last year Flipboard inked a deal with the New York Times that lets subscribers sign into Flipboard with their Times account and view the latter’s content in the former’s app. And Pocket recently added a feature to store login credentials for subscription-based sites right inside their apps. Both of these are good starts. As these bridges get built, publishers will get a far more complete picture of how users are really interacting with their content, especially off-site, which was completely opaque to them before. That knowledge will come in the form of data that can be used to guide the construction of better services and tools, ones that align revenue with actual user behavior in the broader world.

To many of us in the audience, this “superdistribution” is just content distribution as we already know it. But the authors of the Tow report were using the word to signal to publishers that something has changed, something publishers should be actively participating in if they are to gain the benefits (to say nothing of staving off decline). It’s time for publishers to start swimming with this tide instead of against it.

Your rating: None

User-centered design has served the digital community well. So well, in fact, that I’m worried its dominance may actually be limiting our field.

The terms “user experience design” (UX) and “user-centered design” (UCD) are often used interchangeably. But there’s an important distinction.

UX design is the discipline: what we do. Precise definition is elusive, but most attempts focus on experience as an explicit design objective.

User-centered design is a process: how we do it. Again the specifics vary, but usually form shades of the same hue:

  • Research. Immerse yourself in your users’ worlds to understand what they do and why they do it.
  • Sketch ideas that address these learned needs.
  • Prototype the most promising ideas to evaluate them more accurately.
  • Iterate through testing, repeating steps as required.

Other design processes

UCD is the dominant design approach within UX, so pervasive that some UX designers behold it as the Platonic ideal of design. Deviation from the UCD faith is even met with derision. A naive recruiter whose job specs aren’t explicit about direct user contact soon learns not to reoffend.

But other design processes are available. Jared Spool’s article 5 Design Decision Styles explores alternatives to UCD, including:

  • Self design, aka “scratching your own itch.” The designer acts as a surrogate for the audience. It’s convenient and quick, but clearly only reliable in narrow circumstances.
  • Genius design. Genius design has no first-hand research phase. To anticipate user behavior, the designer draws upon stockpiled experience, imaginative analogy, and psychological fundamentals.
  • Activity-focused design. Here, the designer addresses users’ primary tasks rather than any underlying needs. Tasks are derived a priori, from a logical interpretation of the domain, rather than from research.1

It seems arbitrary to regard these alternative design processes as inferior substitutes. Surely other modes can fulfill the broad UX mandate of creating experiences?

Weaknesses of UCD

UCD’s ascendancy deserves historical context. Its success came largely as an antidote to what preceded: the Wild West of the early web, dominated by Hey-This-Looks-Cool hackery. UCD offered rigor (or at least the perception of rigor; see Scientism below) that helped the immature web refocus on its audience. But that phase is long past, and the more experience I earn, the more flaws I see in UCD’s finery.


UCD simply takes longer than genius or self design. Clients typically identify research as the culprit, meaning the research phase is usually targeted when time is short. The UX industry has countered this variously through client education, seeking shortcuts, or by slipping research in without formal consent. But—whisper it quietly—some design research is wasted effort. For research to be valuable, it must:

  • be free from sampling or cognitive biases;
  • address issues that are central to the product;
  • offer genuinely new insight; and
  • be used to forge new ideas, not to validate predetermined decisions.

In these circumstances UCD is unparalleled, enabling breakthroughs other modes can’t. But I think UCD advocates overstate how often these planets align. I argue that genius design and iteration will often achieve better results in the same time.

Someone with experience as not only a designer but also as an attentive user has built up an unconscious repertoire of patterns and approaches that suit various contexts. As this library grows, it frees the designer from the need to research every problem.

The UX industry appears to acknowledge the relevance of genius design by its adoption of the expert review—a tool that epitomizes the approach—but often feels it has to prop this review up with user validation. It’s hard to escape the thought that the primary function of this redundancy is to retain the appearance of neutrality.

Negation of style

Among the UX community’s favorite quotes of late:

“[Good design] dissolves in behavior.” —Naoto Fukosawa
“The best interface is no interface.” —various
“Great design is invisible.” —various

At first glance, these are elegant statements of aesthetic intent: the user should never notice the designer’s influence. This “disappearing designer” motif holds self-sacrificial appeal, and for many interactions it’s great advice. I don’t want my tax forms to bear any trademark flourishes. However, when we extend this line of thought to its logical conclusions, these quotes start to look like mere slogans.

By negating the idea of a designer’s influence, we also negate the idea of style within the UX discipline. We’re saying that, done properly, it should be impossible to tell one UX designer’s work from another’s. There should be no signature elements, no philosophical movements, no overarching tenets except that of transparency.

The commoditization of designers that this idea suggests is troubling. Moreover, style is crucial for a creative discipline’s evolution. The best writers and architects—whose work, just like UX design, has function and engenders experience—have unmistakable styles. Throughout history, daring work from iconoclasts has sparked entire movements, and thus transformed creative practice. The transition between the Neoclassical and Modernist architectural eras, for example, wasn’t simply a case of replacing Doric columns with perpendicular glass. It was a total reframing of architecture and its values. Modernity usurped antiquity.

Is our form of functional art any different? In a system that deprecates style, is there room for a designer to pioneer entirely new approaches?2 If not, are we happy with the resultant ideological homogeneity?

Of course our designs must put users first. But there is never just a single way to meet user goals. Instead of trying to deprecate style, we should embrace it as a way to drive our practice forward and lend personality to the things we make. In a marketplace of bewildering clutter, products with a damn opinion are by far the most interesting.


Given its academic influences, it’s not surprising that UCD has been sold as a science. Empiricism runs through its discourse, to the unfortunate extent that the UX industry often oversells the certainty it can offer.

Scientism—akin to Colbert’s “truthiness”—is the veneer of science where little scientific validity exists. While UCD is methodical, it is manifestly not scientific. There can never be a universal truth to design. Solutions applied in one context may fail magnificently in another, and the few governing principles (Fitts’s Law, the Gestalt principles, and affordance, say) give at best partial guidance. Some supposed laws, such as the “magical number 7±2” persist in ill-informed fringes of UX, despite being largely rebutted.

While researchers and designers can learn plenty from the scientific method, design simply does not yield to scientific analysis in the way its scientistic proponents wish.

To treat design as a science is to retreat to the illusory safety of numbers, where designers are mostly seen as agents of skewing the odds in your favor. This can start a race to the bottom as design gets less and less leeway. Weak leaders overtest in lieu of trusting designers to make decisions: it’s just a small step from there to the infamous forty-one shades of blue.


Finally, I’m concerned about the mindset that UCD can instill in its practitioners.

It’s unsurprising that a user-centered process can skew inexperienced designers’ loyalties away from business priorities. Some claim that this serves as counterweight to the business-first leanings of other employees. The argument strikes me as infantile. When a designer adopts simplistic, reductive arguments that ignore business reality, it undermines him. It limits his potential influence. Only the well-rounded designer who can fight for what’s right while accommodating business reality will be seen as a true leader.

What next?

I don’t expect UCD’s pre-eminence to change. Nor do I think it necessarily should. But a design community is most healthy when it shares a respectful variety of opinions. I don’t see that in the UX industry today, and I hope we can begin to appreciate the value of alternative design approaches.

The designers who will stand out in future will be those who are familiar with many modes of design. These designers may have a favorite, of course—and UCD is an excellent candidate—but they also have the versatility to draw on other processes when suitable. Perhaps they will even pioneer new approaches to add to our toolkits.

Your rating: None

You have five minutes while waiting for a friend to meet you for lunch, so you find yourself shopping for a new pair of shoes. When your friend arrives, you put the phone away, but leave the web page open to help you remember what you found when you get home.

While you’re at work, you read a restaurant review for a new place you think sounds tasty. Come dinnertime, you grab your phone to pull up the address and location.

One night on your tablet, you’re browsing articles for a report you’re writing at work. Back at your desk the next day, you struggle in vain to remember what you searched for to find those articles. Why can’t you find them again?

Sound familiar? If you’re like most people, it probably does. Research from Google (PDF) shows that 90 percent of people start a task using one device, then pick it up later on another device—most commonly, people start a task on smartphone, and then complete it on the desktop. As you might expect, people regularly do this kind of device switching for the most common activities, like browsing the internet (81 percent) or social networking (72 percent). Certain categories like retail (67 percent), financial services (46 percent), and travel (43 percent) also seem to support this kind of sequential use of different devices.

Dual-screen or multi-screen use of devices gets a lot of attention, but we tend to focus on simultaneous usage—say, using tablets or smartphones while watching TV. Publishers, advertisers, and social networks are all actively trying to figure out how to deliver a good experience to users as they shift their attention between two screens at the same time. Sequential usage is every bit as common, but we rarely acknowledge this behavior or try to optimize for this experience.

When people start a task on one device and then complete it on another, they don’t want different content or less content, tailored for the device. They want the same content, presented so they can find it, navigate it, and read it. They imagine that their devices are different-sized windows on the same content, not entirely different containers.

What should we do to provide a good experience for users who want to complete the same task across more than one device?

Content parity

Let’s make device-switching the final nail in the coffin for the argument that mobile websites should offer a subset of the content on the “real” website. Everyone’s had the frustrating experience of trying to find content they’ve seen on the desktop that isn’t accessible from a phone. But the reverse is also a problem: users who start a task from a smartphone during a bit of free time shouldn’t be cut off from options they’d find back at their desktop.

Consistent navigation labels

When picking up a task on a second device, about half of users say they navigate directly to the website to find the desired information again. Users who are trying to locate the same information across a mobile site (or app) and a desktop site can’t rely on the same visual and spatial cues to help them find what they’re looking for. As much as possible, make it easy for them by keeping navigation categories and hierarchy exactly the same. There aren’t that many cases where we truly need to provide different navigation options on mobile. Most desktop navigation systems have been extensively tested—we know those categories and labels work, so keep them consistent.

Consistent search

About 60 percent of users say they’d use search to continue a task on another device. Businesses wondering whether “mobile SEO” is necessary should keep in mind that user tasks and goals don’t necessarily change based on the device—in fact, it’s often the identical user searching for the exact information that very same day. It’s frustrating to get totally different results from different devices when you know what you’re looking for.

Handy tools

Users have taught themselves tricks to make their transition between devices go more smoothly—about half of users report that they send themselves a link. Sites that don’t offer consistent URLs are guaranteed to frustrate users, sending them off on a quest to figure out where that link lives. Responsive design would solve this problem, but so would tools that explicitly allow users to save their progress when logged in, or email a link to the desktop or mobile version of a page.

Improved analytics

Mobile analytics is still in the dark ages. Tracking users between devices is challenging—or impossible—which means businesses don’t have a clear picture of how this kind of multi-device usage is affecting their sales. While true multi-channel analytics may be a ways off, organizations can’t afford to ignore this behavior. Don’t wait for more data to “prove” that customers are moving between devices to complete a task. Customers are already doing it.

It’s time to stop imagining that smartphones, tablets, and desktops are containers that each hold their own content, optimized for a particular browsing or reading experience. Users don’t think of it that way. Instead, users imagine that each device is its own window onto the web.

Your rating: None

We talk a lot here at A List Apart about designing for the future. About being thoughtful, accessible, forward-thinking, and compassionate. About building a web that serves more of us, more fully.

And yet, when it comes to building our own communities—the events and conferences in which we learn new skills and discuss new ideas—we’ve spent precious little time designing with this inclusivity in mind. We accept conference lineups loaded with white men because “we couldn’t find any other qualified speakers,” or “all the women we asked said no.” We host bro-tastic hackathons fueled by beer-serving babes. Sometimes, we even give straight-up harassment and vitriol a place at the podium.

This isn’t good enough.

If the web’s ideal is universality, as Sir Tim Berners-Lee says, then shouldn’t this be the driving principle behind our own communities and organizations as well? If we want a web that works for everyone, then don’t we need a web profession that reflects just as much diversity? After all, the best way to understand the audiences we design for is to know those audiences. And the best way to know people is to have them, with all their differences of perspective and background—and, yes, age and gender and race and language, too—right alongside us.

“But I don’t want to exclude anyone,” you might be thinking. “I’m not trying to keep women or people of color or those from different backgrounds out of the spotlight.” I’m sure that’s true. Yet our community is far from diverse: According to the 2011 findings from our very own Survey for People Who Make Websites, just 18 percent of you are likely to be women, and even fewer of you are non-white. Add in the fact that women, people of color, and those from outside the U.S. are all much more likely to perceive bias in their careers, and it starts to get pretty hard to pretend everything’s OK. In fact, sexism at “geek” events is so prevalent, there’s a whole wiki devoted to cataloging known incidents.

However you participate in the web community—organizing conferences, holding hack nights, publishing articles, hosting meetups, or simply attending events—you have the power to do something about this, and in turn bring the web closer to its ideals. And it’s not as hard as you might think.

We have the tools

The web’s ability to connect people, facilitate understanding, and amplify ideas has enabled us to build incredible things. It’s also given us a wealth of lessons in how to design thriving, thoughtful communities. Lessons it’s time we turn toward ourselves—toward reaching this more personal, more intimate goal.

What can we learn from designing online communities, social systems like Flickr and Facebook? I propose four key skills: setting expectations, making it easy to report abuse, fostering diverse participation, and avoiding blaming our users.

Set expectations for behavior

The right tone of voice can turn someone’s confusion into trust, skepticism into optimism, boredom into curiosity. The wrong tone of voice can turn someone’s interest into annoyance, anticipation into disappointment, frustration into full-on anger.

—MailChimp’s Voice & Tone guide

Online communities are fertile ground for misunderstandings. Without the benefit of nonverbal cues like nods, smiles, motions, and postures, we misinterpret sarcasm. Our jokes fall flat. Our feelings get hurt. So what do we do when building these communities, besides writing up explicit terms of service? We set implicit expectations.

Implicit expectations include the voice and tone of an interface—from the signup forms to the welcome messages, the email reminders to the error notifications. Design, too: Typography, color, and layout choices all influence how a user sees an experience, and help her form an impression of not just what the site is, but how it feels, and how she’s expected to behave there. With every bit of content you communicate, you’re modeling the discourse you expect from others.

In addition to having explicit rules of conduct (and training your volunteers to enforce them), you can also create these types of implicit expectations in IRL. In fact, if you organize events, you already have models for behavior: the people who take the stage. Placed on a platform, both literally and figuratively, your speakers’ and organizers’ behavior and actions become your event’s norm. Their tone becomes your audience’s tone.

It’s your job to make sure it’s the right one.

If you’re in charge, talk with presenters, organizers, and volunteers about the expectations you want to set. Remind them that their actions are on display, and will reverberate across the event. Empower them to model the sorts of behavior you want to see, and be explicit about what’s inappropriate—like slides that objectify women or statements that marginalize non-U.S. attendees.

If you’ve picked the right speakers, this won’t impose on their creativity one bit.

Provide easy-to-navigate outlets to report abuse

Imagine a 14-year-old girl logging onto Facebook to find that she’s been called a slut and tagged in obscene photos by a classmate intent on ruining her reputation. She’s got enough on her plate without having to also wrangle with an interface that makes it hard to stop the harassment, right? So Facebook offers the option to delete any item posted to your page, right alongside the post—and to block a user and report abuse, just by visiting that user’s profile.

Now think about the last conference you attended. If you’d been harassed, would you have known where to go for help? Would you have had a clear outlet to voice concerns? Or would you have been @-messaging a generic conference avatar, unsure who was on the other end? Sidling up to a harried registration desk to discuss your grievances in public?

Would you have said anything at all?

I didn’t. A couple years back, I was propositioned by an employee of the company organizing the conference—a much-older man who was also a vendor for my then-employer. We’d had drinks with another colleague of mine, where we’d made mundane cocktail talk about business and spouses. We said goodnight, and approximately two seconds after he knew I’d be alone, he sent me a demanding, aggressive text message—one that assumed I’d already consented to a liaison. I was disgusted and furious, but unsure what to do: He was my main contact at his company, and knew the owner of mine well. The prospect of explaining all this over and over to people I wasn’t sure would understand seemed like a further humiliation waiting to happen.

So I let it go. And I spent months feeling ashamed of myself for it.

No event organizer wants attendees—especially those dropping hundreds or thousands of dollars on a conference pass—to feel this way. But if you’re in charge, you’ve got to do more than want. You’ve got to plan, and you’ve got to make it clear to the people attending that there’s an outlet for their concerns—before they have any.

Hearing about inappropriate behavior is difficult, sure. But no matter how awkward it is for you, I promise it’s much worse for the person who’s been made to feel uncomfortable or unsafe, who’s trying to hold it together while telling you, and who’s scared you’ll just write it off.

Don’t let that happen. If you organize events, name a person or provide a place—virtual or physical. Promise confidentiality. And publish this on your website or in your collateral, right from the start. You don’t need to make it scary—just include a simple note reminding attendees that everyone should feel welcome, and if they don’t, there’s a place to go and a person who’ll listen.

If you volunteer or speak at events, make a point to ask about policies for harassment or inappropriate behavior: Does the event have any? What are they? Raising the question may be all that’s needed to get an organizer thinking about these issues.

Whatever you do, don’t you make it a burden for someone to figure out how to tell you they’ve been harassed. If you do, many of them never will.

Foster diversity to foster longevity

Back in 2010, when Twitter first started suggesting people for users to follow, it made a rookie mistake: recommending the same people to everyone, all the time. This created a dynamic where “the rich got richer,” as Heather Champ, who’s known for her work building communities like Flickr, has noted. In other words, it made a few big names even bigger (Bieber, anyone?), but it failed to foster deeper connections or build robust communities. Over time, Twitter realized this wasn’t working and responded with major updates designed to give users more varied, relevant suggestions.

As we design community events, it’s important to ask the same thing: Are we just allowing the same people to keynote each year? Are we creating a divide between the haves and the have-nots—those with all the speaking experience, and those with none? If so, which people are we leaving behind? What value could they bring, what new connections could they build across our community, if we amplified their voices instead? What is our industry not learning, where is our industry stagnating, because we’re inviting the same cast to perform the same show each night?

Sameness is boring. It’s predictable. It’s stale.

Perhaps worst of all, it’ll only sell tickets or entertain audiences for so long. The best events feel fresh and different each time—they bring forth a variety of voices, tell a range of stories, and share a breadth of perspectives. They shift and adapt—just like the web.

As an attendee, you might argue that you want to see polished speakers and big names. There’s nothing wrong with that, and it’s normal to seek out lineups that have a few. But how many times have you looked at a speaker roster and thought, “man, that guy’s at everything”?

The best events avoid this sort of speaker fatigue by mixing in fresh faces and ideas—and that requires actively looking for new voices. If you’re recruiting talent, ask past speakers whom they’ve been reading recently. Trawl Twitter for interesting blog posts hashtagged to your field. Invite longtime attendees to submit a talk. Consider whether women might be declining your invitation to speak for reasons you hadn’t considered, and address those, too.

A star-studded speaker roster might generate buzz, but a diverse lineup adds texture, depth, and color. It adds richness and fullness. Done well, it makes people remember how your event changed the way they think and feel—not just which internet celebrity gave the keynote.

Don’t blame your users

Users aren’t perfect: They’re busy. They’re distracted. They’re human.

When we design for humans, we know we need to be forgiving. We know that when they need help, we can’t talk down to them. We know they deserve respect, understanding, and compassion.

Perhaps most of all, we know that when they fail, it’s our job to get better.

The same is true in person. Every time you make an excuse for a bad experience—“It was just for fun. I don’t know why you’re so offended,” or “We’re not trying to exclude anyone…you must be imagining things!”—you’re blaming your user. You’re making it his problem, not yours.

I’ve felt like this, too. Recently, I was accosted by a conference organizer at an official event happy hour. He had always come on a bit strong—too many cheek kisses, too much touching, too-tight hugs, too everything—but I’d always ignored it, figuring he wasn’t worth getting worked up about.

I was wrong. This time, when I questioned something he’d said in his talk that I considered divisive, things turned a very different direction. He screamed at me, in public, pointing his finger and advancing on me aggressively. I kept reiterating that I wasn’t sure why he was so upset, but the yelling continued for what felt like an eternity. I finally told him that the way he was talking to me was inappropriate, that I needed to be treated with respect, and that if he continued, I wouldn’t speak to him anymore.

I’d gone from someone he thought he could paw at to someone he thought he could scream at, and the combination left me shaken. I felt degraded. I felt humiliated.

But most of all, when trying to talk to people about what had happened, I felt marginalized. “He was probably drunk!” some folks said. “Oh, you just got him agitated! You know how he is,” I was told.

Whether or not I’d said something controversial doesn’t really matter. Disagreement and discussion aren’t the problem. His response was abusive and inappropriate, if not overtly sexist, and excusing his bad behavior made it my fault: If I’d just avoided him while he was drinking, just not asked a question, just not gotten him so “worked up,” then this wouldn’t have happened.

You know how condescending, blame-ridden error messages—like “FAILURE. FILL OUT ALL FIELDS CORRECTLY”—frustrate the hell out of users? It’s no different here. Blaming someone who’s been treated poorly is taking what’s already an alienating, isolating experience and deepening it. It’s making them feel incompetent and ashamed.

It’s like the lite version of telling someone she shouldn’t have been wearing a short skirt if she didn’t want to be groped. And it’s a problem you can fight, even if you’re just an attendee, by taking a stand against bad behavior—one that puts the blame squarely on the person who’s really responsible.

It’s up to us

I don’t pretend my experiences are tragic. I wasn’t terrorized or physically assaulted. My life goes on.

But my stories also aren’t unique. I could regale you with hours of anecdotes from friends and colleagues—mostly women, but not all—who’ve poured their time and love and attention into preparing presentations and articles, only to be humiliated or marginalized. People who’ve chosen not to talk about their piss-poor experiences for fear of being retaliated against. People who’ve stopped attending events or speaking up, because it’s just too damn hard to keep smiling while feeling left out, degraded, or attacked. Instead of outing others, though, I’ve told you my own stories. Stories I wish I didn’t have. Stories I wasn’t sure I’d ever share.

I’m sharing them now because I believe we have the power to improve things.

We already know how to make design choices that support inclusivity, set expectations for users, and model the interactions we want. There’s no excuse not to fix this—and, in fact, there’s a real danger in not trying.

We’ve spent two decades talking about a web that’s inclusive and flexible. We’ve devoted countless hours to creating spaces where conversations and relationships can thrive. The longer we tolerate a community that excludes others, the more we, as an industry, are defined by exclusion—and the further away we remain from the universality we’ve worked so hard to build.

Your rating: None

We are pleased to present you with this excerpt from Chapter 1 of Content Strategy for Mobile by Karen McGrane, now available from A Book Apart. —Ed.

When we talk about how to create products and services for mobile, the conversation tends to focus on design and development challenges. How does our design aesthetic change when we’re dealing with a smaller (or higher-resolution) screen? How do we employ (and teach) new gestural interactions that take advantage of touchscreen capabilities? How (and who) will write the code for all these different platforms—and how will we maintain all of them?

Great questions, every one. But focusing just on the design and development questions leaves out one important subject: how are we going to get our content to render appropriately on mobile devices?

The good news is that the answer to this question will help you, regardless of operating system, device capabilities, or screen resolution. If you take the time to figure out the right way to get your content out there, you’ll have the freedom (and the flexibility) to get it everywhere. You can go back to thinking about the right design and development approaches for each platform, because you’ll already have a reusable base of content to work from.

The bad news is that this isn’t a superficial problem. Solving it isn’t something you can do in isolation, by sandboxing off a subset of your content in a stripped-down mobile website or app. The solution requires you to look closely at your content management system, your editorial workflow, even your organizational structure. You may need different tools, different processes, different ways of communicating.

Don’t despair. There’s even better news at the end of this rainbow. By taking the time now to examine your content and structure it for maximum flexibility and reuse, you’ll be (better) prepared the next time a new gadget rolls around. You’ll have cleared out all the dead wood, by pruning outdated, badly written, and irrelevant content, which means all your users will have a better experience. You’ll have revised and updated your processes and tools for managing and maintaining content, which means all the content you create in every channel—print, desktop, mobile, TV, social—will be more closely governed.

Mobile is not the “lite” version

It looks like you're on a train. Would you like me to show you the insultingly simplified mobile site?

—Cennydd Bowles (

If people want to do something on the internet, they will want to do it using their mobile device. Period.

The boundaries between “desktop tasks” and “mobile tasks” are fluid, driven as much by the device’s convenience as they are by the ease of the task. Have you ever tried to quickly look up a bit of information from your tablet, simply because you’re too lazy to walk over to your computer? Typed in a lengthy email on your BlackBerry while sitting at your desk, temporarily forgetting your keyboard exists? Discovered that the process to book a ticket from your mobile was easier than using the desktop (looking at you, Amtrak!) because all the extra clutter was stripped away?

Have you noticed that the device you choose for a given activity does not necessarily imply your context of use?

People use every device in every location, in every context. They use mobile handsets in restaurants and on the sofa. They use tablets with a focused determination in meetings and in a lazy Sunday morning haze in bed. They use laptops with fat pipes of employer-provided connectivity and with a thin trickle of data siphoned through expensive hotel Wi-Fi. They use desktop workstations on the beach—okay, they really only use traditional desktop machines at desks. You’ve got me on that one.

Knowing the type of device the user is holding doesn’t tell you anything about the user’s intent. Knowing someone’s location doesn’t tell you anything about her goals. You can’t make assumptions about what the user wants to do simply because she has a smaller screen. In fact, all you really know is: she has a smaller screen.

The immobile context

Users have always accessed our content from a variety of screen sizes and resolutions. Data reported by SecureCube shows that in January 2000, the majority of users visited from a browser with an 800×600 resolution, but a significant minority (twenty-nine percent) accessed the site at 1024×768 or higher, with a smaller percentage (eleven percent) viewing the site at 640×480 (; fig 1.1). At that time, decisions about how best to present content were seen as design challenges, and developers sought to provide a good reading experience for users at all resolutions, discussing appropriate ways to adjust column widths and screen layouts as content reflowed from smaller to larger screens.

Figure 1.1

Fig 1.1: We have plenty of experience delivering content to a variety of screen resolutions. Why do we assume that mobile screens necessarily indicate a different context?

What you didn’t hear designers talking about was the “640×480 context” and how it differed from the “1024×768 context.” No one tried to intuit which tasks would be more important to users browsing at 800×600, so less important options could be hidden from them. No one assumed that people’s mindset, tasks, and goals would be different, simply because they had a different-sized monitor.

Why do we assume that mobile is any different?

Mobile tasks, mobile content

I recently departed Austin, Texas, traveling with three friends. Since we arrived at the airport a bit early, I wanted to lounge in the comfort of the United Club, away from the teeming masses. I felt it would be rude to abandon my friends to a similar fate outside, and so I wanted to know how many guests I could bring with me to the club.

A simple Google search should clear up this problem. Sure enough, I quickly found a link that seemed promising (fig 1.2).

Figure 1.2

Fig 1.2: Searching for “United Club Membership” shows that the content exists on the desktop site. But because the mobile website redirects the URL, users wind up on the homepage of the mobile site.

Alas, following the link to United Club Membership just took me to the homepage for When users search from a mobile device, United automatically redirects links from Google to its mobile website—without checking to see if the content is available on mobile. If the content doesn’t exist on mobile, the user gets unceremoniously dumped on the homepage of the mobile website. Mobile redirects that break search—how is that ever a good user experience?

Sure, there’s a link to the full desktop site, but that too just dumped me on the desktop homepage. I could try to use United’s internal site search, but I’d wind up pinching and zooming my way through several search result screens formatted for the desktop. And honestly: why should I have to? An answer that should take me one tap from the Google search results should not require searching and tapping through several pages on both the mobile and the desktop sites.

I went and asked the representative at the desk. (Correct answer: two guests.)

I don’t bring this up just because I want to shame United for wantonly redirecting links to a mobile URL when the content isn’t available on its mobile website. (That’s a terrible thing to do, but it comes after a long list of other bad things I’d like to shame United Airlines for doing.) No, I use this example to illustrate a common misconception about mobile devices: that they should deliver only task-based functionality, rather than information-seeking content.

Information seeking is a task

Luke Wroblewski, in his book Mobile First, tells us that Southwest Airlines is doing the right thing by focusing only on travel tasks (fig 1.3):

The mobile experience…has a laser-like focus on what customers need and what Southwest does: book travel, check in, check flight status, check miles, and get alerts. No room for anything else. Only what matters most.

Figure 1.3

Fig 1.3: The Southwest Airlines iPhone application only has room for what actually matters…if what matters doesn’t involve looking up information.

Mobile experts and airline app designers don’t get to decide what “actually matters.” What matters is what matters to the user. And that’s just as likely to be finding a piece of information as it is to be completing a task.

Eighty-six percent of smartphone owners have used their phone in the previous month to look up information—whether to solve a problem, settle an argument, get up-to-the minute information such as traffic or sports scores, or to decide whether to visit a business like a restaurant ( Don’t believe me? Look at your own search history on your mobile device—you’ve probably tried to answer all sorts of questions by looking up information on your phone.

The Southwest Airlines desktop website includes information about their baggage policies, including policies for checked bags, carry-ons, and pets, as well as lost and found, delayed baggage, and a variety of other traveler information, such as what to do if you lose your ticket, need to rebook, or your flight is overbooked. It even includes information for parents looking to book travel for unaccompanied minors, and how Southwest accommodates disabled flyers and the elderly.

The mobile experience does not. Who are we to say that this content doesn’t actually matter?

It’s fine to optimize the mobile experience for the most common tasks. But that doesn’t mean that you should exclude valuable content.

Mobile is social

Have you ever clicked on a link from Facebook or Twitter on your phone? How about a link someone sent you in an email?

Figure 1.4

Fig 1.4: “No mobile content found. Would you like to visit the desktop version of the site?” asks The Guardian. Can you guess the answer?

Of course you have. Sharing content with our friends and colleagues is one of the bedrock ways we communicate these days. Users don’t distinguish between accessing email, Facebook, Twitter, or other social services on the desktop or on mobile—they choose them fluidly, depending on which device they’re closest to at the time. In fact, as of June 2012, nearly twenty percent of Facebook members use it exclusively on mobile (

If your content isn’t available on mobile—or provides a bad reading experience—you’re missing out on one of the most compelling ways to get people to read it. Is your site littered with icons trying to get people to share your content? If your readers just get an error message when they tap on shared content, all the effort you put into encouraging social sharing is wasted (fig 1.4).

Designing for context

“Context” is the buzzword everyone throws around when talking about mobile. At the South by Southwest Interactive conference in 2011, the panel called “Designing for context” was the number one must-see session, according to .net Magazine (

The dream is that you can tailor your content for the user’s context—location, time of day, social environment, personal preferences. Based on what you know about the user, you can dynamically personalize the experience so it adapts to meet her needs.

Today, we use “designing for the mobile context” as an excuse to make mobile an inferior experience. Businesses want to invest the least possible time and effort into mobile until they can demonstrate return on investment. Designers believe they can guess what subset of information or functionality users want. Everyone argues that they’re designing for the “mobile use case.”

Beware of personalized interfaces

Presuming that the “designer knows best” when choosing how to deliver personalized content or functionality is risky. We’re notoriously bad about predicting what someone will want. Even armed with real data, we’re likely to make incorrect assumptions when we decide to show some things and hide others.

Microsoft Office tried this strategy in the late 1990s. Office 97 offered many new features and enhancements, which made the user interface more complex. Long menus and dense toolbars gave the impression that the interface was “bloated” ( (Sound like any desktop websites you know?)

In response, Microsoft developed “personalized menus” and “rafted toolbars” which showed the most popular items first (fig 1.5). Although Microsoft had good data and a powerful algorithm to help determine which items should be presented first, it turned out that users didn’t like being second-guessed. People found it more frustrating to go through a two-stage process, hunting through multiple menus to find what they were looking for. Personalized menus violated one of the core principles of usable design: put the user in control.

Figure 1.5

Fig 1.5: Personalized menus in Office 97 attempted to prioritize only the options Microsoft thought users wanted. They were a failure.

Now imagine that instead of clicking a chevron at the bottom of the menu to expand it, the user has to click a link to “full desktop website” and then hunt around in the navigation while squinting at a tiny screen. If your website’s mobile version only offers a subset of your content, you’re giving your users the same frustrating experience. Only much worse.

You don’t have good data

Microsoft had a ton of data about which options people used most frequently. They developed a complex algorithm to present the default “short” menu based on the items people were most likely to want, based on years of history and research with multiple iterations of their product. And they still made mistakes.

The choices you make about which subset of content you want to deliver probably aren’t backed up by good data. They might not be backed up by any research at all, just a gut feeling about which options you imagine will be most important to the mythical on-the-go user.

Even if you do have analytics data about which content people are looking for on mobile, it’s not likely you’re getting an accurate picture of what people really want. Today’s crippled mobile experiences are inadequate testing grounds for evaluating what people wish they could do on mobile. As Jason Grigsby, Cofounder of and, says:

We cannot predict future behavior from a current experience that sucks (

If your vision for mobile is designing for context, then the first step you need to take is getting all your content onto mobile devices.

All of it? Really?

Really. Your content strategy for mobile should not be to develop a satellite to your desktop site, showing only the subset of content you’ve decided a mobile user will need. That’s not going to work because:

  • People move fluidly between devices, often choosing a mobile device even when they have access to a desktop computer. Don’t assume you can design for “the on-the-go user” because people use their mobile devices anywhere and everywhere.
  • Mobile-only users want and need to look at your content too! Don’t treat them like second-class citizens just because they never or rarely use the desktop. Even if you think of them as “mobile-mostly” users, remember that you don’t get to decide which device they use to access your content. They do.
  • Mobile supports reading content just as well as it supports functional tasks. Don’t pat yourself on the back just because you’ve mobile-ized some key features—there’s more work to do with your content.
  • Context is a cop out. Don’t use context as a rationale to withhold content unless you have real research and data about what users need in a given situation or environment. Unless you have that, you’re going to guess wrong. (And even if you do have that—given the crappy experiences most users get on mobile today, you’ll still probably guess wrong.)

Never force users to go to the desktop website for content they’re seeking on a mobile device. Instead, aim for content parity between your desktop and your mobile experiences—maybe not exactly the same content presented exactly the same way, but essentially the same experience.

It is your mission to get your content out, on whichever platform, in whichever format your audience wants to consume it. Your users get to decide how, when, and where they want to read your content. It is your challenge and your responsibility to deliver a good experience to them.

Your rating: None