ENTRIES TAGGED "ux"
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?
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:
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:
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.
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, 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…
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.
First, your project needs to use the
Next, when you want the animation to begin, you do this:
CABasicAnimation* animation = [CABasicAnimation animation WithKeyPath:@"transform.rotation.y"]; animation.fromValue = @(0); animation.toValue = @(2 * M_PI); animation.repeatCount = INFINITY; animation.duration = 5.0; [self.rotatingView.layer addAnimation:animation forKey:@"rotation"]; CATransform3D transform = CATransform3DIdentity; transform.m34 = 1.0 / 500.0; self.rotatingView.layer.transform = transform;
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.
CABasicAnimation* animation = [CABasicAnimation
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:
animation.fromValue = @(0); animation.toValue = @(2 * M_PI);
Next, the animation is told that it should repeat an infinite number of times, and that the full rotation should take 5 seconds.
animation.repeatCount = INFINITY; animation.duration = 5.0;
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.
[self.rotatingView.layer addAnimation:animation forKey:@"rotation"];
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.
CATransform3D transform = CATransform3DIdentity; transform.m34 = 1.0 / 500.0; self.rotatingView.layer.transform = transform;
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 “
OSCON 2013 Speaker Series
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.
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 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.
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:
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.
OSCON 2013 Speaker Series
Tony Santos, (@tsmuse) is a User Experience Lead at Mozilla and OSCON 2013 Speaker. We talk about Human-Centered Design and how it can make all the difference.
NOTE: If you are interested in attending OSCON to check out Tony’s talk or the many other cool sessions, click over to the OSCON website where you can use the discount code OS13PROG to get 20% your registration fee.
Key highlights include:
- Defining human-centered design. [Discussed at 0:20]
- Hey Developers, Want your app, software, or product to be a success? Then you need to care about this, seriously. [Discussed at 1:05]
- So, what do users actually want? [Discussed at 2:10]
- Some (user) research is better than no (user) research. [Discussed at 3:03]
- Open source sort of abides by human-centered design by its very nature, but can do even better. [Discussed at 4:01]
- A human-centered design success story. [Discussed at 6:26]
You can view the full interview here:
Why "flow" and "context" are more important than screen size
Are we done with the Mobile First meme, yet? Can we be? Please?
Look, don’t get me wrong. I fundamentally agree with a lot of the thoughts behind the annoying catchphrase “mobile first.” For example, I agree that mobile devices are now the primary (if not only) mode of connecting for many markets. I also think that having some sort of mobile strategy is absolutely required for almost every product.
The problem is that “mobile first” often equates “mobile” with “small screen” or “responsive layout” or “native vs. mobile web.” Now, those are all incredibly important decisions. But if you’re thinking about the size of your screen or the technology you’re going to use first, you are designing wrong.
Of course, if you’ve read anything else I’ve ever written, you know that the first thing you must figure out is an important customer problem or need that your product is aimed at solving for real people. We’re going to just skip over that whole part where you get to know your most important users. But that’s always first. Promise.
Once you’ve done all that though, you need to start designing. And there are two things that you should always know before you even start considering things like screen size or technology.
Those two things are: Flow and Context.