On August 7, 2014, UX designers and developers around the world cheered to the news that Microsoft would officially drop support for older versions of Internet Explorer, effective January 2016. Yet by and large, the outcry was less “hooray for Microsoft!” and more “why didn’t they do this sooner?” The answer is “because people still use IE,” and yet people still use IE because it’s supported, and it’s supported because people use it. It’s a vicious cycle.Two years ago, Nicholas Zakas wrote an article for Smashing Magazine entitled “It’s Time to Stop Blaming Internet Explorer,” in which he said:
It’s not actually old browsers that are holding back the web, it’s old ways of thinking about the Web that are holding back the Web.He went on to explain that constraints will always exist, be they older browsers, business requirements, or user needs, and it’s the UX designer’s job to focus on what can be done rather than how to rid the world of the constraint. It’s an intriguing idea. We do work within constraints on every project, and many of them will never wane no matter how much we complain about them, but some constraints can be cracked, or at least altered, if we know where to begin. We’re often told to ask for serenity to accept the things we cannot change, courage (or coffee) to change the things we can, and the wisdom to know the difference. By understanding where constraints originate and why users react to a given constraint the way they do, we can gain the wisdom we need to identify whether each constraint should be accepted, or challenged.
The MAYA principleOlder browsers aren’t the only constraint subject to a vicious cycle. The same is true of any constraint that users are familiar with – users, after all, prefer “the devil they know.” Think, for example, of the best practice “keep the interface simple,” and how often it is broken because usability testing shows the site’s users don’t think to visit a second page, click on a “see more” link, or hover over a dropdown navigation. As UX designers, we’re (generally speaking) technologically savvy with access to the latest design fads and sleekest interfaces. However, websites created for “everyone” must include the large portion of the population without our technological prowess – which means sometimes breaking with our sleek, hip best practices. It’s in creating for “everyone” that we settle into the cycle of “the users wouldn’t recognize anything else, so we can’t give them something new.” The way to break out of this cycle is summarized by the industrial designer Raymond Lowey’s “MAYA principle.” The MAYA principle states that designers are responsible for creating the most advanced creations they can, without creating interactions or interfaces that users will be unable to understand. In this way, they can push the envelope bit by bit, gradually breaking out of old cycles and teaching users to recognize new concepts, be they a “swipe” as a method of scrolling or a phone as an acceptable camera-and-iPod replacement. There are tools that can help users to progress to more advanced, yet still acceptable, ideas. For example:
- Progressive reduction: providing beginners with additional content to help familiarize them with a new application. Essentially, this works as an in-context help manual.
- Gradual rollouts: to upgrade an existing tool, follow Google’s plan for integrating Hangouts into Gmail. Rather than updating everyone at once, they are slowly rolling out the tool, allowing users to revert back to “classic chat” for over two years – though we’re approaching the mandatory update!
- Skeuomorph for familiarity: when creating a new product, utilize familiar models to help users feel comfortable. Kindle, for example, has done a great job of maintaining a familiar “book” interface to help users with the transition away from paperbacks.
Identifying constraintsMuch has been written on constraints’ ability to provide shape to creativity. Constraints can add inspiration, and enforce the need for simplicity. But constraints are like walls; some walls are helpful because they keep us from wandering too far astray. On the other hand, if walls are all around us, they merely box us in. Scope, schedule, and resources are often acknowledged as the three primary constraints we come up against – the “Iron Triangle” of constraints, where each impacts the other two. If the scope is constrained, the project may become easier, as long as the schedule and resources are not also severely constrained. These three constraints are typically constraints that act as helpful walls, guiding us on our way.
- Do I have the power to change this today?
- Do I know who to ask, to change this in the next few weeks or months?
- Are there steps I can take to change this gradually, over time?
If the constraint comes in the form of business requirements contradicting user needs, a UX designer will likely know who to address and how to remove the barrier. However, if the constraint is due to browser choice, it will take more than stakeholders’ permission to change.