All postsEXPLORE TOPIC

#UX

Bob Moog and usability heuristics

Here's a rare intersection of my interests. This is actually a great article for UX folks who don't know anything about synthesizers.

The author makes the (accurate) argument that Bob Moog changed the game by hard-wiring some signal paths and abandoning the fully customizable cable-based routing of modular synths.

This is essentially what Apple did in terms of UI as well that led to their early success:

  1. Preset the red routes.
  2. Enable other routes with some switches that are not part of the main UI.
  3. Just abandon the ability to do some things that most users won't need.

That made Apple popular with artists, designers and musicians, just as the Model D became the first synth truly popular with a wide range of musicians. Sure, the Rick Wakemans (and Linus Torvalds) of the world might want more, but they have their complicated alternatives. For the rest of us, it was finally time to make music with synths. Just watch any gear-focused interview with John Foxx, Gary Numan, George Clinton, Rick Wright, you name it — the Model D hugely influenced their worlds so they could influence the rest of the world.

This philosophy can still be controversial at times, as with GNOME 3 (which, incidentally, has become less loathed in the years since its release), but in general the idea of solving for the 90% of users who don't need 50% of the features is considered an obvious one nowadays.

Of course, modulars have seen a resurgence lately because once you're in deep you inevitably want to start making your own synths. But that hasn't stopped the steady stream of simplistic analog boxes like the Volca series or Behringer's slavish old-school synth imitations. Options are great, but menu diving is no fun and the quickest way to get a musician to love your instrument is to get them creating quickly.

And this, as the article gets across pretty well, is what we should learn from Moog.

Apple would've patented the pitch wheel though.

Discuss

When you "have" to do a focus group

Most UX researchers will parrot the line that focus groups are terrible, and even if they are parroting, they're right. Erika Hall, in Just Enough Research, calls focus groups "research theater."

But often, you'll find that budget and/or time constraints can manipulate your beautifully planned user research into a focus group. Is there anything you can do about it?

As usual, Pentagram and other gatekeeping haters be damned, design thinking (or human-centered design) comes to the rescue. Co-design doesn't just mean working in cross-functional teams in your own organization, it means involving your users. If we truly believe that they know best, then why not involve them?

About a year ago, I got access to a group of young people who were acting as an advisory board to a client. The client made e-learning modules for an urban teen market and we were building the interface and helping with their product design philosophy. The problem with this access was that not only were the kids biased — they had volunteered for the position and were paid a stipend — but when they got together they were effectively a focus group. All of them were smart and motivated, but they weren't always motivated to give the kind of feedback we needed, and we continued to see patterns of one person leading the group (a standard focus group behavior).

Since we met them regularly, I started to give them homework. They put together mood boards and talked about the kinds of sites they regularly visited. Maybe they all colluded, but it didn't matter quite as much because it was an intentional collaboration on their part in this case.

Then we eased into some design thinking exercises, and conducted a design studio workshop. I instructed them to think of the particular details of what made them frustrated with, apathetic to, or unable to operate the current layouts. Then they drew. Standard practice applies here:

  1. We were remote, but I instructed the moderators to give them sharpies so we didn't fall into the detailed drawing trap.
  2. The youth liaison to the company, as well as the product leader and another product manager, participated.
  3. The drawings were timeboxed, then presented and lightly critiqued as a group.

They took pictures and sent them to us, and we did affinity mapping and more detailed analysis after the workshop.

None of this is really rocket surgery, but it's worth mentioning that as long as you have the right participants, any user research should be considered useful and there's a lot of value in being able to "make lemonade."

Discuss

Microsoft's persona spectrum

I think the headline is bait and the sentiment is a little radical — as someone who's been working with more behavioral-based personas for a long time, I'd say there's plenty of use personas still have as a design tool. It's just that people, especially marketers, have been using them poorly for years.

However, Microsoft's inclusive "persona spectrum" idea is great. It helps to demonstrate that accessibility and inclusion aren't just about (for instance) serving blind users, they're about serving everyone in as many cases as we can.

Discuss

PURE Framework

This article came out early last year, but PURE is a new-to-me usability evaluation method from Intel Security and the master of UX metrics, Jeff Sauro. I'm always looking for low-impact, low-cost ways of evaluating the usability of features before (or, god forbid, in lieu of) a full moderated test.

In some cases, that can be done. Even if you're against the idea as a useful method on its own, it can point to the places that need to have full testing done on them. PURE is nice because a decently-trained person can do it without having to hold tons of heuristic guidelines in their head. And you get a pretty nice-looking chart result at the end.

Here's the full whitepaper.

I've created a spreadsheet that calculates up the scores, and some Figma components to build the chart. I think this might be the case I've been looking for to develop a tool for Figma using their API.

Discuss

Is the golden age of UX really over, and what does that really mean

Maybe the "golden age of UX" really is over. I think a better way to put it is that we've been discovered out here in our clubhouse and now we're gonna have to grow up and play ball with everyone else. But this widely-shared article from Marvel (a tool I like a lot) has missed the mark in a couple fundamental ways.

First, strategy is not for everyone. We did what I think is a great job designing strategy at D&B, and it was in itself a design challenge. But not everyone on the team was involved or wanted to be involved. Disparaging non-strategic UX as a "production" role is an insulting mistake. This is skilled practitioner stuff, and there are still very few people who are actually good at it. The fact that there are exponentially more UX designers out there doesn't mean there are infinitely more good ones, especially since new folks are being raised on hot takes. So trying to convince the relatively few good ones to move on to strategic roles in companies that still need their user advocacy is not gonna help those companies.

Especially if your next aim is to get those designers on the growth or marketing trains.

"Growth hacking" is what UX designers are destined for now? Or social media marketing? Turn me into glue now, then, thanks. UX efforts are necessary in all of these worlds, and product marketing is inextricably tied to product design — but the core tenets of UX are unaffected by Valley trends (like "growth hacking") or marketing efforts, which are famous for attempting to subvert the true needs of the user.

Let's not lose the voice of the user in an attempt to stay relevant to a fad-driven Product Hunting world. And if the going wisdom is "we solved that, time to move the talented designers on to growth hacking and marketing," then I'd consider that all the more reason why UX is still badly needed on the ground.

Discuss

Inline validation considered harmful

Just kidding, this article didn't really use that word. And rather than an alarmist view, this is a fairly measured take. However, most of the arguments are actually against realtime (onblur) validation, not inline validation.

I spent two years dealing with some serious problems that were born entirely out of the fact that an application used realtime+inline validation. And that was primarily in a series of wizard-like dialogs, which really didn't make any sense (the pattern of "disable the continue button until validation is cleared" would've worked well).

Our problems included:

  • forms that didn't require a certain order to filling them out, but validation that did
  • false positives triggered by mouse actions that left users in an unresolvable state if they clicked "wrong"
  • field groups often in a false-positive state (point #4 in the article)

This isn't the same as saying that per-field validation is wrong, and I still strongly believe in that, but this article has a lot of solid points.

Discuss