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:

• Can Technology Really Change Your Habits? (Fast Company)
• There’s a backlash against nudging – but it was never meant to solve every problem (The Guardian)

David Cancel has some interesting thoughts on how they split up product management and tech team responsibilities in How we transformed HubSpot into a Product Driven Company. I really liked this part about embedded designers:

While we kept the core technical team tight, they were bolstered by the presence of embedded product marketers and UX designers all fixed on the same problem and solution. Designers and UX researchers informed the product teams from the point of mockups, through testing phases, to the ultimate release and support the product. […] The upshot here is that product teams become wholly self-sufficient organisms. They are small enough to retain customer focus but still have the skilled resources they needed to design, test and market the solutions they developed.

That post led me to Jeremy Crane’s What does a Product Manager do at HubSpot, which goes into more detail on the PM/Tech team split:

Every product team’s job is, essentially, to solve problems for their customers. Solving problems involves two key components: (1) Understanding the problem, and (2) creating the solution. At HubSpot the product manager owns the “problem” and the technical team owns the “solution.”  The “problem” is defined by whatever is likely to produce the greatest value to the customer and the business at large within the area of influence. The “problem” is both long-term and short-term in scope. It addresses the immediate challenges that the customer is experiencing, while still keeping an eye the longer-term vision of the product as a whole.

This is the login screen on Walmart.com:

It looks like any other login screen, with one difference. See that check box? What does that check box usually indicate?

Yep. The standard pattern on the web is to use that space for the “Keep me signed in” check box on login screens. Here are a couple of examples I quickly went to:

That Walmart interface was designed to trick people into signing up for marketing email, since most people will simply check the box without reading the text. We really need to stop with these dark patterns.

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.

Lukas Mathis writes about our fear of empty space in visual design in Horror Vacui:

There’s a concept in visual art called horror vacui, or «fear of empty spaces.» It’s the natural tendency of humans to fill empty spaces with stuff. Your new shelf has some empty panels? Put something in there! Your flat has an empty corner? Buy a chair! Or a plant! Something! Anything!

Humans have the same tendency when it comes to visual design. No empty space! Your screen has a few white pixels? What feature can we put there! Quick! Find something we can put there!

There’s a problem with that, though. Empty space is not useless.

He goes on to explain that “emptiness equates to prestige.” In short, don’t fear the empty space!

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.

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.

Sophie Shepherd introduces some new deliverables in Rethinking Our Prototypical Process, including this one:

HTML prototypes have the potential to confuse some clients. In addressing feedback, I’ve answered questions like: Are we tied to this layout? (No.) Is this real content? (Ideally.) Is this what our website will look like? (Probably not.) The content outline strips any potentially distracting elements from the prototype: no layout, no typography, no links, no things remotely resembling design. It’s just a list of the content that will be on each page in order of its importance.

This deliverable, which she calls a “Content outline” or “Page description diagram”, seems like it fits well with my idea of Content slice diagrams. It’s great to see these new useful deliverables emerging — a sensible retreat from the “get out of the deliverables business” march of the past few years.

Craig Mod discusses single-purpose products in his product design essay There is much to learn from the paper towel:

All of these single-purpose tools or philosophies strive towards the same goal: whittle away the cruft around an idea to reveal its most base components, and in doing so, strengthen what is left.

The single-purpose lecture attendee is, in theory, a better student. The single-purpose-sized paper towel makes us happier, is gentler on the earth. Individual tools in unix are more efficient and easier to debug because of their specificity. Facebook Messenger on its own is easier to use to communicate without the deluge of Facebook notifications flying in our faces. And so on and so forth.

I’ve started using Craig’s solution for single-purpose Twitter notifications and single-purpose Facebook messages and it works really well.

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.