Rune Madsen wrote a really interesting post on how our design methods need to change when we work in software (as opposed to print). He explains in the post On meta-design and algorithmic design systems:

So what is meta-design? In a traditional design practice, the designer works directly on a design product. Be it a logo, website, or a set of posters, the designer is the instrument to produce the final artifact. A meta-designer works to distill this instrumentation into a design system, often written in software, that can create the final artifact. Instead of drawing it manually, she is programming the system to draw it. These systems can then be used within different contexts to generate a range of design products without much effort.

I’ll add my vote for the need to spend much more effort on design systems (like Atomic Design) upfront, to standardize (and eventually speed up) later development.

Kevin Roose and Pendarvis Harshaw wrote a fascinating 3-part series for Fusion on technology in prisons. I was particularly drawn to the part about allowing inmates to use tablets: Can technology and prisons get along? —

He can’t just hand out iPads, of course. The tablets being used in the Napa jail are manufactured by a Chicago start-up called Jail Education Solutions, which runs them on a secure, proprietary software platform called Edovo. The tablets can’t be used to connect to the Internet; instead, inmates can connect to a local intranet administered by the correctional facility itself. Using the tablets, they can stream Khan Academy lectures, run cognitive behavioral therapy apps, study for a GED, or take courses from Narcotics Anonymous and Alcoholics Anonymous. They can also opt for lighter fare – games and movies, which can be “purchased” with points they earn by completing more educational tasks.

I’m intrigued by stories like this because it shows how designing under severe constraints can result in big innovations.

(I know it’s bad form to explain a joke, but I’m pretty happy with the title of this post)

Buzz Usborne’s “God is in the details” is a great reminder that spending just a little time thinking things through a bit more that usual can have a big impact on user experience:

But it’s those little things, the tiny minutia of detail, that ultimately make beautiful products, and beautiful houses.

Unfortunately, when I refer to the “details” in product design, I’m not talking about obvious design things; like colours, drop-shadows or placement. Instead I’m referring to something harder to define; experience and subconscious patterns that help the user feel more at-ease with an interaction. That detail might come in the form of a change in cursor, a “down” style for a button, or a helpful animation.

Whatever form that detail takes, I’ll bet that it wasn’t designed in Photoshop, or included in even the most detailed spec document. It’s the details that fall outside of titles like UX, or UI. It’s interaction detail that can only be found after using a product for real, then dedicating solid design and engineering time to building.

I definitely agree with that last bit as well. I’m working on a prototype for a new app at the moment, and it’s only after we did usability testing with real target users that we discovered some interactions that would make the app a lot easier (and more useful) for users.

Michael Andrews brings up some interesting concerns about cards in Are UI Cards good for content? However, I’m left thinking that most of the “cons” in the article are actually Information Architecture problems, not problems with the card metaphor:

UI cards can contribute to content usability problems that may not be immediately evident.  Users often like UI cards when they encounter them, and don’t notice their limitations.  They see tidy cards often with colorful thumbnail images.  The cards seem optimized to make good first impressions.  But often, the cards end up squashing the content that must go in them, or omitting content details that don’t fit the layout vision.

If content is squashed and truncated in cards, it’s not the card element’s fault, it’s the content’s fault. It happens when content isn’t written while keeping the context of use in mind.

Here’s another example:

Another issue with UI cards is their lack of hierarchy. When all cards are the same size, all cards look equally important, whether they have detailed information, time sensitive information, sparse information, or optional information.

Again, visual hierarchy is a larger design problem, and not the fault of cards.

I point this out because it reminded me of one of the big dangers in design that we have to watch out for. We often see a UI issue and immediately switch out the pattern instead of trying to understand what the the real problem is. It’s great if we can look at something we designed and say, “Hmm, that doesn’t work.” But we have to go further and also understand why it doesn’t work before we just take the easy why out and replace the UI element.

If content is squished on cards, is it because we used cards, or because we didn’t write the content concisely enough to be easily consumable in small spaces? If all cards look the same, should we stop using cards, or design different card types to address visual hierarchy better? I would argue that in both cases, the latter should at least be considered. Of course, if cards are wrong for the interface, then burn it with fire. But be sure.

Further reading on cards:

• Card Architecture and Card Design
• How to Champion Your Content with Cards
• Why Cards are the Future of the Web
• Twitter, canvases and cards

I’m currently working on the design of a native app for Jive Software, and we really wanted to do some usability testing on a prototype before development starts. There are, of course, a multitude of reasons to do usability testing on prototypes, but we had some very specific issues we wanted to address:

• We are a distributed team. Product Management is in Palo Alto, Product Design is in Portland, and Development will happen in our Tel Aviv office. So we knew from the beginning that a functional prototype would be essential to communicate within the team. Flat wireframes / PSDs just weren’t going to cut it.
• We’re working on something in a fairly new market, so we need to do quite a bit of validation to make sure we get the utility of the app right.
• And of course, our designs are never as good as we think they are, so we wanted to make sure we correct the majority of the usability issues before development starts.

I read a lot about prototyping native apps and mobile usability testing, and since everyone’s process is different, I wanted to give an overview of the process we settled on, since we’re really happy with it so far. It was very important to me that all our offices would be able to observe the usability tests, so that guided a lot of the decision-making. Here’s how we’re doing it…

Prototyping

After reviewing and trying out every prototyping tool known to man, I settled on Proto.io for this project. There are so many great options out there that it’s hard to go wrong on a choice of tool. Proto.io was the best for me because of a few key features:

• I needed full interactivity — since we used the prototype for usability testing it needed to feel as real as possible.
• I needed lots of flexibility in the animations/transitions supported, since we’re in new territory and need to try out lots of different things. Proto.io supports any interaction I threw at it.
• I needed to use a mix of built-in components and my own assets, and Proto.io handles that pretty well.

Of course, I can’t show what the prototype looks like at the moment, but as soon as the app launches I’ll update the post and embed it here.

Mobile usability testing rig

I got lost in mobile usability testing guides for days — there are so many good ways to do it. At first we considered remote testing, but it just wasn’t a good option for us because we were going to do part IDI (in-depth interview) and part usability testing, so we needed a way to be in the room with users and dig deep into certain areas.

I’ve seen some crazy setups — my favorite and weirdest is probably MailChimp’s “hug your laptop” idea. It’s a brilliant hack, but I was worried our non-tech savvy users would have trouble with this, so I needed another solution.

I ended up going with Bowmast’s Mr. Tappy kit, and I attached a Logitech HD Pro Webcam C920 to it. We played around with it in the office first to make sure it’s going to work:

With that out of the way, it was on to the next challenge — how to stream it everywhere.

Streaming to observation rooms

This part was much easier than I thought, simply because we already use Vidyo for videoconferencing in all our offices. So every time I started a usability test I would start my meeting in Vidyo, and then people from our other offices could dial into my meeting from their observation rooms. They could see the room on one screen, and the participant’s phone on another. It worked like magic:

What we ended up with is a setup where I can do usability testing in person on mobile devices, record the sessions, and have people observe these sessions from anywhere in the world. It was an incredibly productive few days, and I’m now working my way through fixing all the usability issues we picked up. Can’t wait to show this to you when it goes live!

Further reading:

• Recording Mobile Device Usability Testing Sessions
• How we built a research lab for mobile app testing in just a few hours
• Remote Usability Testing on Mobile Devices
• How to Conduct a Usability test on a Mobile Device
• Eight Lessons in Mobile Usability Testing
• Secrets From Facebook’s Mobile UX Testing Team

In Netflix’s Secret Special Algorithm Is a Human Tim Wu writes about the importance of human intervention in data-driven decision making:

Of course, there is a big difference between using data in combination with intuition and relying entirely on an algorithm—the decision-making equivalent of Siri finding gas stations near you. I don’t think anyone—Netflix, Mitt Romney—makes big decisions that way. As Chris Kelly, the C.E.O. of Fandor, an indie-film Internet channel told me, “It just isn’t true that you can rely on data completely.” Even Google, the champion of algorithms, employs substantial human adjustments to make its search engines perform just right. (It cares so much about this that Google claims First Amendment protection for its tweaks.) I do not doubt that companies rely more on data every day, but the best human curators still maintain their supremacy.

It’s a good reminder that following data blindly is a pretty bad idea. Joshua Porter’s Metrics Driven Design is stil the best presentation I’ve seen on this topic and how it relates to design.

This is pretty fantastic. The new Sonos logo pulses like sound waves when you scroll up and down. Brand New comments:

There is no doubt this is a party.

Indeed.

Designed by Bruce Mau Design.

Laura Sydell tells a great story in At 90, She’s Designing Tech For Aging Boomers (but when did NPR decide to go all Upworthy-like with their headlines?):

Addi says when Beskind is in a room, young designers do think differently. For example, Addi says IDEO is working with a Japanese company on glasses to replace bifocals. With a simple hand gesture, the glasses will turn from the farsighted prescription to the nearsighted one.

Initially, the designers wanted to put small changeable batteries in the new glasses. Beskind pointed out to them that old fingers are not that nimble.

“It really caused the design team to reflect,” Addi says. They realized they could design the glasses in a way that avoided the battery problem. “Maybe it’s just a USB connection. Are there ways that we can think about this differently?”

We need so much more diversity in the design community — not just in terms of gender and race, but age as well. Here’s a story that proves how valuable design diversity really is.

So I guess it’s quarterly “Designers should learn to code” day on Twitter. This appears to be the crux:

Good discussion today w/ friends who are “designers that code.” It’s no longer even a question of “Should designers learn to code?”

— Nathan Smith (@nathansmith) January 20, 2015

Because that ship has sailed. It’s more like… If you’re a designer that doesn’t code, you’ll just be left behind. Not even a debate anymore.

— Nathan Smith (@nathansmith) January 20, 2015

I have two questions.

1. What is a “designer”?

I don’t mean that in the metaphorical sense. I mean literally, how do you define design in this context? Is it visual design? User experience design? Product design? Content strategy, or any or all of the other things that make up well-rounded design?

Because here are the things I’m currently trying to get better at by reading books and practicing and writing and working it into projects:

• Usability testing and ethnography
• Information architecture across multi-platform experiences
• iOS native app design

I’m a little busy right now, so I’d like to know: which of these things should I drop to learn to code?

2. What does “left behind” mean?

Does it mean designers who don’t code won’t get hired in The Future? I don’t know about that. I spend a lot of time with designers. Some of them code, some don’t. Those who don’t specialize in something else that those who code aren’t good at, and that makes for stronger teams where work can be distributed more evenly and more effectively.

Let me put this another way: once every designer can code (since it’s “not even a debate any more”), who’s going to make sure we build the right things? Who’s going to discover user needs, create IAs that work for target personas, and design scalable holistic systems that work across devices and contexts?

What I mean to say is this:

• Heaven help us if we become a community of executors at the expense of all the planners out there. We need both.
• It’s really, really dangerous to tell people they’ll be “left behind” if they don’t become part of a homogenous group of people all focused on the same thing. That has never worked out well for anyone, in the history of mankind.

So go forth, follow the design thing you’re most interested in. If that’s coding, awesome. If it’s how to best understand user needs and translate that into design systems, go do that. As long as you do it well, you won’t be left behind.

Adam Greenfield reminds us that the “smartness” of technologies comes from the people who use it, not the technology itself. From The smartest cities rely on citizen cunning and unglamorous technology:

It’s simply that in both these cases, the sustaining interactivity was for the most part founded on the use of mature technologies, long deglamorised and long settled into what the technology-consulting practice Gartner refers to as the “trough of disillusionment”.

The true enablers of participation turn out to be nothing more exciting than cheap commodity devices, reliable access to sufficiently high-bandwidth connectivity, and generic cloud services. These implications should be carefully mulled over by developers, those responsible for crafting municipal and national policy, and funding bodies in the philanthropic sector.

I like the term “deglamorised” very much. It’s a reminder that our goal as designers isn’t to make cool stuff—it’s to help people do great things with the stuff me make.