"ux" entries

Accessibility: Why I Hate Checklists

A truly accessible website is both accessible and usable

Every time I give a talk about making accessible websites, I get the following question:

“What checklist do you use to make sure a site is accessible?”

My response always surprises them:

“I don’t use a list.”

Why not? There are so many lists out there that I could be using! Practically every US government agency has a checklist published on their site, and several non-government sites offer checklists of their own. With so many free resources, why do I ignore checklists?

Read more…

Comment

Knowing and Understanding Your Audience

Measuring impact and changing behavior

I had the opportunity to sit down with Laura Klein (@lauraklein) and talk about the importance of creating effective user experiences. Laura is a UX expert and consultant. She stresses the need to figure out what works by talking to users and determining what works through usability testing. She’s also author of O’Reilly Media’s UX for Lean Startups: Faster, Smarter User Experience Research and Design. It hit home when Laura told me, “If people aren’t getting it, you’re probably doing it wrong.”

Key highlights include:

  • How to figure out what works, so you can avoid a poor user experience. [Discussed at 0:19]
  • It’s important to avoid porting a traditional process to a new product and service. Instead you need to think about how to design a new and natural experience. [Discussed at 2:16]
  • Think about context when designing new processes. [Discussed at 2:37]
  • The first step in creating a successful UX is knowing and understanding your audience. [Discussed at 3:49]
  • Using these principles beyond web sites. In all good UX applications, the goal is not to notice the interface. [Discussed at 5:16]
  • It’s critical to observe people, so you’re not assuming a knowledge base. [Discussed at 7:35]
  • The importance of A/B Testing. And how design is not an art; it’s trying to solve a problem. [Discussed at 9:54]
  • How the build, measure, learn lean methodology fits with UX design. It’s all about measuring the impact and changing behavior. [Discussed at 11:11]
  • You can view the full interview here:

    Related:

Comment

Purposeful Design Principles for Behavior Change

How to design products and services that help users change behavior

Steve Wendel (@sawendel) is the Principal Scientist at HelloWallet where he develops applications that help users take control of their finances. He’s also currently writing Designing for Behavior Change. I recently sat down to talk with Steve about the importance of testing and iteration, role of psychology, and resources and tools.

Key highlights include:

  • Describing the general principles of designing for behavior change. [Discussed at 0:16]
  • When we get it wrong, how to turn it around. [Discussed at 2:12]
  • Good examples of products and services. [Discussed at 4:45]
  • Read more…

Comment

Investigating the state of UX and UI design in tech

As web and industrial design begin to collide, UX and UI design are particularly ripe for disruption.

The last major shift in design arguably occurred in the 90s as print design gave way to web design, and designers suddenly had to deal with web safe colors, alias fonts, and the information design challenges of a non-sequential medium. Two decades later, design is approaching a similarly monumental shift as designers move from designing for the web to designing for systems.

Software developers and hardware engineers are starting to face difficult — and atypically similar — questions in terms of user experience (UX) and user interface (UI) design as web and industrial design begin to collide. Software developers must now think about designing for hardware interfaces, and hardware engineers must now design with UX and UI in mind. This collision presents an opportunity for a tectonic shift in the design space, with the potential to spread across industries on a larger — and more personal — scale than design has experienced before. That’s why, beginning today, we’re kicking off an exploration of the companies and people experimenting with and innovating in UX and UI design.

We can already see the beginnings of this shift as wearable interfaces, such as Google Glass, Fitbit, and Jawbone, become more and more mainstream. But what about designing for a wearable computing system for assistance dogs that allows an animal to alert or even command its human? Or for a sensor system for your teeth that could monitor what you eat and drink?

Read more…

Comments: 8

The True Cost of Lemonade

Learn to resist vanity metrics

One of the things we preach in Lean Analytics is that entrepreneurs should avoid vanity metrics—numbers that make you feel good, but ultimately, don’t change your behavior. Vanity metrics (such as “total visitors”) tend to go “up and to the right” but don’t tell you much about how you’re doing.

Many people find solace in graphs that go up and to the right. The metric “Total number of people who have visited my restaurant” will always increase; but on its own it doesn’t tell you anything about the health of the business. It’s just head-in-the-sand comforting.

A good metric is often a comparative rate or ratio. Consider what happens when you put the word “per” before or after a metric. “Restaurant visitors per day” is vastly more meaningful. Time is the universal denominator, since the universe moves inexorably forwards. But there are plenty of other good ratios. For example, “revenue per restaurant visitor” matters a lot, since it tells you what each diner contributes.

What’s an active user, anyway?

For many businesses, the go-to metric revolves around “active users.” In a mobile app or software-as-a-service business, only some percentage of people are actively engaged. In a media site, only some percentage uses the site each day. And in a loyalty-focused e-commerce company, only some buyers are active.

This is true of more traditional businesses, too. Only a percentage of citizens are actively engaged in local government; only a certain number of employees are using the Intranet; only a percentage of coffee shop patrons return daily.

Unfortunately, saying “measure active users” begs the question: What’s active, anyway?

To figure this out, you need to look at your business model. Not your business plan, which is a hypothetical projection of how you’ll fare, but your business model. If you’re running a lemonade stand, your business model likely has a few key assumptions:

  • The cost of lemonade;
  • The amount of foot traffic past your stand;
  • The percent of passers-by who will buy from you;
  • The price they are willing to pay.

Our Lean lemonade stand would then set about testing and improving each metric, running experiments to find the best street corner, or determine the optimal price.

Lemonade stands are wonderfully simple, so your business may have many other assumptions, but it is essential that you quantify them and state them so you can then focus on improving them, one by one, until your business model and reality align. In a restaurant, for example, these assumptions might be, “we will have at least 50 diners a day” or “diners will spend on average $20 a meal.”

The activity you want changes

We believe most new companies and products go through five distinct stages of growth:

  • Empathy, where you figure out what problem you’re solving and what solution people want;
  • Stickiness, where you measure how many people adopt your solution rather than trying it and leaving;
  • Virality, where you maximize word-of-mouth and references;
  • Revenue, where you pour some part of your revenues back into paid acquisition or advertising;
  • Scale, where you grow the business through automation, delegation, and process.

Read more…

Comment

Not Your User’s Problem

Understanding the Difference Between User Problems, Business Needs, and Solutions

First, let me say that I love all the emphasis on Customer Development, Early User Research, and Product Market Fit that I’ve been seeing these days. What I don’t love is the massive confusion that often comes along with it.

There’s a particular type of confusion I’ve seen on teams at the very beginning of the product development process that I’d like to try to clear up. Or possibly add to. We’ll see.

Some people don’t seem to understand the difference between a Business Need, a User Problem, and a Solution. But you have to understand the difference, because if you don’t, you’ll end up doing the wrong sort of research and designing the wrong product.

A Business Need

At its very simplest, a Business Need is what a product will do for your company. This can often be expressed in the form of a metric that needs to be moved or a hypothesis about how building a new feature or product will make you a billionaire.

Here are some examples of business needs:

  • Improve the conversion rate on a landing page so that we get more people trying our product.
  • Increase revenue by selling more widgets.
  • Get more registered users for free by getting our current users to share our product.
  • Increase engagement with our product so that people are more likely to be retained users.
  • Build a huge user base so that we can eventually monetize it.

What’s interesting about these Business Needs? Well, in one way or another, all of these things, if executed correctly, should eventually increase our revenue or decrease our spend. We need to do these things to have a viable business. But there are all sorts of ways to do them, some of which are great for users and others that aren’t.

To identify a business need, typically you’re going to want quantitative data. You need to know what your metrics are in order to figure out which ones need to be higher. You don’t determine a business need by talking to users.

Obviously business needs might be caused by user problems. For example, if your onboarding process is hard to use, you could have low conversion rates. But the business need is increasing the conversion rate, which you might do in a number of different ways.

A User Problem

Your users have problems. Some of the problems they’ll pay you to solve for them. Some of the problems you’re probably causing for them with your terrible UX. Some of the problems they don’t even know they have.

Here are a few examples of user problems:

  • It’s hard to share documents across different computers.
  • The first time experience with a particular product is confusing and complicated.
  • The user can’t use an app when it’s not connected to the Internet.
  • A person has trouble finding a good hair salon in her area and booking an appointment.

You’ll note that these user problems are all quite different. The first one inspired lots of companies, like DropBox. The second one is common to many products. The third one is mobile specific. The fourth one could be solved by a number of different types of products, some of which are quite low tech. There are roughly an infinite number of other user problems that could exist.

The common factor here is that these are problems experienced by humans. The other common factor is that there is no guarantee that solving a user problem will actually fulfill a business need. Sure, solving problems for people is generally a good thing, but there are some user problems that people will pay you to solve and others that they won’t.

To identify a user problem, your best bet is observational and generative research. Watch people in the wild using your product or other products. Follow people around while they perform various tasks or do their jobs. Understand the things that make life difficult for people and then identify the biggest, most important problems that you could solve for them.

A Solution

A solution, as the name implies, is how you solve a problem. Ideally, your solution will solve a user problem which will fix a business need.

Here are a few examples of solutions: Read more…

Comment: 1
Four short links: 24 July 2013

Four short links: 24 July 2013

Good Dev, User-Hostile Patterns, Patent Victories, and Drone History

  1. What to Look For in Software Dev (Pamela Fox) — It’s important to find a job where you get to work on a product you love or problems that challenge you, but it’s also important to find a job where you will be happy inside their codebase – where you won’t be afraid to make changes and where there’s a clear process for those changes.
  2. The Slippery Slope to Dark Patterns — demonstrates and deconstructs determinedly user-hostile pieces of software which deliberately break Nielsen’s usability heuristics to make users agree to things they rationally wouldn’t.
  3. Victory Lap for Ask Patents (Joel Spolsky) — story of how a StackExchange board on patents helped bust a bogus patent. It’s crowdsourcing the prior art, and Joel shows how easy it is.
  4. The World as Fire-Free Zone (MIT Technology Review) — data analysis to identify “signature” of terrorist behaviour, civilian deaths from strikes in territories the US has not declared war on, empty restrictions on use. Again, it’s a test that, by design, cannot be failed. Good history of UAVs in warfare and the blowback from their lax use. Quoting retired General Stanley McChrystal: The resentment caused by American use of unmanned strikes … is much greater than the average American appreciates. They are hated on a visceral level, even by people who’ve never seen one or seen the effects of one.

Comment

Rotating a UIView in 3D

OSCON 2013 Speaker Series


Jon Manning (@desplesda) and Paris Buttfield-Addison (@parisba) are co-founders of Secret Lab and authors of the forthcoming Learning Cocoa with Objective-C, 3rd Edition. They’ll be speaking at OSCON this week in Portland, OR. Here they explain how to rotate a UIView in 3D on iOS.


One of the simplest visual tricks you can do in iOS is to make a part of your UI pretend to be a 3D object. We’ve found that this is an excellent way to add some life and visual interest to both apps and games.

Below, you’ll learn how to make a view rotate in 3D and have a perspective effect.

phone

First, your project needs to use the QuartzCore framework.

Next, when you want the animation to begin, you do this:

To stop the animation, you do this:

How It Works

CABasicAnimation allows you to animate a property of a view from one value to another. In the case of rotating a view, the property that we want to animate is its rotation, and the values we want to animate from and to are angles.

When you create the animation using [CABasicAnimation animationWithKeyPath:], you specify the property you want to animate. In this case, the one we want is the rotation around the Y axis.

The animation is then configured. In this example, we made the rotation start from zero, and proceed through to a full circle. In Core Animation, angles are measured in radians, and there are 2 * π radians in a full circle. So, the from value and to value are set thusly:

Next, the animation is told that it should repeat an infinite number of times, and that the full rotation should take 5 seconds.

The animation is started by adding the animation to the view’s layer, using the addAnimation:forKey: method. This method takes two parameters: the animation object that you want to use, and a key (or name) that the animation should be referred by.

Don’t be confused by the similarity between the “key” that you use when you add the animation, and the “key path” you use when creating the animation. The former is just a name you give the animation, and can be anything; the “key path” describes exactly what the animation modifies.

The last step to this is to give the rotating view a little perspective. If you run the code while omitting the last few lines, you’ll end up with a view that appears to horizontally squash and stretch. What you want is for the edge that’s approaching the user’s eye to appear to get bigger, while the edge that’s moving away from the user’s eye to get smaller.

This is done by modifying the view’s 3D transform. By default, all views have a transform matrix applied to them that makes them all lie flat over each other. When you want something to have perspective, though, this doesn’t apply, and we need to override it.

The key to this part of the code is the second line: the one where the m34 field of the transform is updated. This part of the transform controls the sharpness of the perspective. (It’s basically how much the z coordinate gets scaled towards or away from the vanishing point as it moves closer to or further from the “camera“.)

As you can see, adding 3D and perspective effects isn’t terribly difficult, but the results can provide an excellent payoff in terms of user immersion.

Comment

Securing User Content in the JavaScriptable Web

OSCON 2013 Speaker Series

Recent work by a W3 Working Group plans to expose many powerful cryptographic operations for web applications. Although the planned API adds much needed functionality to JavaScript, it doesn’t address the JavaScript runtime’s terrible security properties. For instance, any script running in the web application has the power to hijack the web app’s content and UX. Just last February a mistake in Facebook’s “like” button brought down millions of web sites. Further, if you are an online service provider wanting to support higher privacy use cases like encrypted chat or web-based PGP email, the trust model is fundamentally broken since you can’t serve cryptographic JavaScript code without making the server a potential attack point.

The security challenges faced by JavaScript are mitigated by Privly, also labeled “the Web Privacy Stack,” by addressing two issues: (1) scoping code to the data, and (2) pre-distributing the code to the clients when possible.

Scoping Code to the Data

Every website has its own navigation structure, layout, and audience, but when you strip away these unique attributes of websites, you are left with data– chats, emails, photos– that can be treated uniformly across all websites. Operations on these data like encryption and signing, can be performed with indifference to their context and their contents.

Privly uses data indifference to create the notion of “Injectable Applications,” which are full web applications that are injected into the context of other web application. Since these applications are scoped to data and not layout, their properties are simplified and usable across the web.

Privly works within browser extensions by scanning web pages for specially formatted hyperlinks. When the extension detects the hyperlink, it “injects” the link into an iframe that is served locally from the browser extension.(footnote 1: This is currently how the Chrome extension performs, but different platforms are at different levels of sophistication. This approach can be universally applied to all platforms and does not necessarily require locally-served JavaScript code. However, without serving the JavaScript code locally, the security properties of the system are lost) Since the injected application is a full web application, the app could potentially support any web-implementable feature, including APIs between the host page and the injected application.

In short, if you scope an application to the data, then the cryptography can be viewed in potentially untrusted contexts.

Pre-Distributing Client Code

Privly creates an ecosystem of apps with known properties because it allows us to reason about security uniformly across the web. However, security is only as strong as the weakest attack point, which is why great care must be taken to appropriately distribute these applications. By packaging a set of applications for integration into browser extensions and mobile apps, the code is not re-loaded from a remote source every time the browser loads a new page.

Requiring the pre-distribution of applications is not normally compatible with the free and open internet. However, pains must be taken to realize the differences between the limited use cases of injected applications, and the general cases supported by web applications in general. Distributing every website to the client before visiting a website is impossible, but distributing a set of general injectable applications is lightweight and perhaps the only way to achieve security within the modern JavaScript runtime.

Requiring users to install an extension before they can view content is likely an impediment for any security system looking to gain users. However, since Privly uses hyperlinks to reference the content, it provides opportunity for a hosted fallback application. Depending on the nature of the injectable application, clicking the hyperlink could either present the same application as normally delivered by the extension, or present a prompt to install the appropriate browser extension.
Read more…

Comment

Four Qualities of Successful In-House Innovation Teams

Considering the "two pizza" team

One of the most common questions I get about applying lean ideas to product design and development is, “How can I make this happen in my organization?” Between entrenched corporate silos and existing team management structures, it can seem impossible for these ideas to take root in large companies. Over the course of a series of blog posts, I thought I’d share a few tactics I’ve used and have seen work with other teams to help get you started. In this first post in the series, I’d like to talk about how to structure your teams.

As much as who you hire, structuring your teams effectively is key to a lean team’s success. Many companies see the individual disciplines in their product development organization as service providers—internal agencies. The business reaches out to these agencies (engineering, UX/design, product management, et al.), expresses a need for staffing and the discipline lead provides the resources based on expertise, availability, and project fit. It sounds like a reasonable and efficient way to staff a project and to that extent it is—however, our goal should not be to simply staff a project but to build a team.

When building your team, focus on the following four criteria to maximize their chances for success:

1. Small

Keeping your team small means everyone on the team knows each other—on a first name basis. It’s easier to manage a small team. It’s simpler for the team members to know who to go to when they need something specific. It’s easier to keep track of work accomplished and work left to do.
Read more…

Comment