Menu

Posts tagged “user research”

Designing for behavior change

Dan Lockton’s As we may understand is unnecessarily long and rambling at times, but it’s still worth it for the very interesting views on the Internet of Things and designing for behavior change:

Many of the issues with the ‘behaviour change’ phenomenon can be characterised as deficiencies in inclusion: the extent to which people who are the ‘targets’ of the behaviour change are included in the design process for those ‘interventions’ (this terminology itself is inappropriate), and the extent to which the diversity and complexity of real people’s lives is reflected and accommodated in the measures proposed and implemented. This suggests that a more participatory process, one in which people co-create whatever it is that is intended to help them change behaviour, is preferable to a top-down approach. Designing with people, rather than for people.

Again, it comes down to understanding people and their needs before embarking on a design. I wonder if we’ll ever fully learn this lesson.

Also see:

In defense of enterprise software

I like Jordan Koschei’s defense of enterprise software work in UX for the Enterprise. This is what I get to do every day at Jive:

As designers, we live to solve problems, and few problems are larger than those lurking in the inner depths of a global organizations. After all, Fortune 500s tend to have a “just get it done” attitude toward internal tools, resulting in user experiences that aren’t well designed or tested. By giving those tools the same attention to experience that you give consumer-facing products, you can improve the lives of your users and support the organization’s values and brand.

And this is so important — it’s why it’s essential to do research with end users:

A successful enterprise UX project considers the users’ needs, the clients’ goals, and the organization’s priorities. The best user experience sits at the intersection of these concerns.

Product design: a balance between vision, intuition, and data

I really liked this interview with Josh Porter where he talks mainly about good product design, and the importance of user feedback:

Good product design is the result of persistence as much as anything else. That’s why you hear companies like Airbnb and Evernote and others say that it can take years to figure out user onboarding or free trials or other sophisticated flows. It takes a lot of time to get your message right, get the user incentives right, get the interaction right, etc. It is easy to become impatient and throw out some great ideas prematurely.

And this:

The interplay between vision/intuition and data/feedback is that you need both. You need to be able to assess how you’re currently doing with data but also not let data stop you from taking risks with your product. Many teams become conservative over time as they rely more and more on data to make decisions. They ultimately become paralyzed and unable to build something really new.

Usability testing in Agile environments

There are some great answers in the Quora thread How do you prevent scope creep in agile projects when usability testing? From Todd Zaki Warfel’s answer:

Usability testing doesn’t have to be a formal 3 month engagement. There are plenty of resources out there for doing rapid testing, which can easily be worked into a typical 3-6 week sprint cycle. We do it all the time. Take a week out of the sprint to plan, test, compile recommendations and get to work implementing them. Or as Jeff Gothelf commented, just pick a single day each week to test. You won’t need may participants. If you test weekly, then 3-5 will show a pattern. And anything you don’t catch this week, you’ll catch next week.

From Jeff Gothelf’s answer:

Usability testing needs to be worked in to the sprint timeline. In fact, it should take place during each and every sprint. We test every Thursday. It’s never more than 3 or 4 people. We show whatever we have ready on that day. Sometimes it’s live code and sometimes it’s a paper sketch. Everything in between is fair game. The purpose of this is to get constant feedback, mid-iteration, on the work being designed. In many cases, developers and product owners view portions of these sessions and see the issues that arise. An expectation is built within the team that, based on how things test on Thursday, there may be some tweaks to the scope.

The importance of understanding both user and company culture

Peter Morville’s Creating a Cultural Fit: Using ethnography with users and stakeholders is one of the most useful UX articles I’ve read in a while. He talks about the importance of understanding the cultures of both users and companies to create good products. He concludes:

In short, the right design is one that fits the company and its customers. A mismatch on either side results in fatal error. We must use ethnography with our users and stakeholders to search for a bi-cultural fit. This is tricky since culture is mostly invisible. That’s why we should start with a map.

This is a must-read.

Makers vs. Users

I really like Alex Maughan’s post In a word, Human. He discusses the dangerous gap between those who make software, and those who use it:

Successful user experiences happen when producer whims get sidelined, and primary focus is placed on that little bit of common sense shared by the majority of humans using your product or service. It’s when you empathetically put yourself in the most common psychological flow of a human using a piece of technology they know almost nothing about.

This is a topic I’m very passionate about, so I agree wholeheartedly with Alex.

Know thy (entire) audience

Lauren Chapman Ruiz shares an interesting viewpoint about the role of empathy in design in Inside the Empathy Trap. The issue is that we can’t just have empathy with one person, we need to have an understanding of a wide variety of goals and needs:

When we design, we pursue a broader type of empathy. As a colleague once said to me, designers need to identify with the whole user base. User-centricity is about the ability to recognize that there are a number of personas, each with different goals, desires, challenges, behaviors, and needs. We design for these personas, recognizing that each has different goals they’re trying to accomplish and with different behaviors in how they go about achieving them.

This is another good argument for why personas aren’t dead — they help us to keep our entire target audience in mind without getting overwhelmed.

Wells Fargo: a big, lean company

I was a little reluctant to click on Greg Satell’s How Wells Fargo Learned To Innovate Around the Customer. First, it’s on Forbes, which has become virtually impossible to read on mobile devices because there’s so much blegh on the page that’s not related to the article. Second, whenever you see people talking about “The Customer”, you should be sceptical. There is no average “user” or “customer”, so this kind of thinking usually results in defining an impossibe target market:

Target market

Image source: Tom Fishburne.

That said, despite my fears, the article is quite good. It discusses how Wells Fargo uses ethnography in their business, and there are also signs that they don’t operate like a large, slow-moving corporation at all:

However, it is not just internal processes that have changed, but the culture as well. Ellis’s bankers don’t sit in cozy offices, quietly examining financial statements (nor does Ellis himself), but work in open cubicles designed to promote collaboration. They are constantly iterating, experimenting and testing.

This part, especially, surprised me:

Perhaps most importantly, they are not limited by a long range plan. There is no “five year death march” toward a transformation that will never happen—or be outdated by the time it does. Instead, their purpose is to improve their customers’ businesses and adapt quickly to shifts in technology and the marketplace.

I’d love to see more detail on how Wells Fargo remains lean despite being such a large company. If this is really how they operate, it’s encouraging proof that big doesn’t have to equal slow and tired.

Using technology for healthcare intake

Tom Jacobs discusses some new research that shows people are more comfortable sharing their medical information with virtual people in I’d Never Admit That to My Doctor. But to a Computer? Sure. The implications are interesting:

When it comes to fixing our healthcare system, very few people would agree that part of the answer lies in less human interaction. Patients generally want more, not less, contact with health professionals. Yet this study suggests that, at least for the intake interview, a little less of the human touch — and a little more perceived privacy — may be precisely what the doctor ordered.

How to change destructive behavior

In What If Doctors Could Finally Prescribe Behavior Change? Sean Duffy explains why behavior change is so difficult, particularly in healthcare:

Whether it’s for weight loss, smoking cessation, diabetes, or otherwise, the best research shows that meaningful behavior change outcomes require not just guidance from a trusted health professional, but also positive social support, easy-to-digest insights about their condition, a carefully orchestrated timeline, and a process that follows validated behavioral science protocols. That’s hard to squeeze into a phone call. Or a doctor’s visit, for that matter.

The good news is that this research is resulting in a new field called Digital Therapeutics, and despite quite a bit of snake oil out there, some apps are having success:

Another example is Jenna Tregarthen, a PhD candidate in clinical psychology and eating disorder specialist. She rallied a team of engineers, entrepreneurs, and fellow psychologists to develop Recovery Record, a digital therapy that helps patients gain control over their eating disorder by enabling them to self-monitor for destructive thoughts or actions, follow meal plans, achieve behavior goals, and message a therapist instantly when they need support.