Links and articles about technology, design, and sociology. Written by Rian van der Merwe. Follow @RianVDM
Dave Pell—in the context of Facebook’s plan to host news sites’ content natively—explains what tech people are good at (and usually not good at) in Don’t Take a Flying Leap:
But building a really successful app or site does not mean you know more about education than educators. Disrupting the photo-sharing space does not qualify you to disrupt higher education. Or to understand the health system better than doctors. Or to understand the woes of urban poverty better than those who have spent a career on those corners. […]
This is not the time to give up and it’s not the time to give in to one of the most prevalent myths of the era: that people who can build technology know how to run your business better than you do.
Douglas McGray’s How Carrots Became The New Junk Food is not about carrots. I mean it is, a little bit. But it’s mostly about product positioning and marketing.
“Everyone else pitched baby carrots as an antidote to junk food,” [Jeff] Dunn says. “Where [ad agency Crispin Porter + Bogusky] came out was almost the exact opposite. We want to be junk food.”
They realized that junk food is desirable. So instead of pitting carrots against that industry, they decided to play to its strengths instead. And it worked:
Crispin imagined individual snack packs made of opaque, crinkly plastic, like a potato-chip bag, with bold, junk-food-style graphics (the new packaging would cost about 25% more than traditional veggie bags, but Dunn could justify it as a marketing expense). “People are now grabbing a bag of these, you know, eating them in the car,” Dunn’s marketing chief, Bryan Reese, says. They’d look right at home by a convenience-store checkout.
Beth Kowitt’s How Ikea took over the world is a great look inside the Ikea machine. For me, the biggest takeaway is how research and prototyping drive everything Ikea does. On research:
One way Ikea researchers get around this is by taking a firsthand look themselves. The company frequently does home visits and—in a practice that blends research with reality TV—will even send an anthropologist to live in a volunteer’s abode. Ikea recently put up cameras in people’s homes in Stockholm, Milan, New York, and Shenzhen, China, to better understand how people use their sofas. What did they learn? “They do all kinds of things except sitting and watching TV,” Ydholm says. The Ikea sleuths found that in Shenzhen, most of the subjects sat on the floor using the sofas as a backrest. “I can tell you seriously we for sure have not designed our sofas according to people sitting on the floor and using a sofa like that,” says Ydholm.
And on prototyping:
Products under development go through rapid prototyping in the pattern shop to provide a sense of what they will actually look like in the flesh—or at least in plastic. On a recent visit, one of the four 3-D printers was outputting a toilet brush. Apparently this is one of the more normal items. “We have a lot of strange things,” says Henrik Holmberg, who manages the department. “That is very good that we can do it in our own shop rather than spreading the crazy ideas externally.” One of the oddest things he’s ever worked on was a lamp made from the same material as egg cartons. “I thought that was very crazy,” he says, “but we proved the technique was possible.”
Great article on the power of user-centered design.
Susan Pinker explains why face-to-face contact matters in our digital age:
Our survival hinges on social interaction, and that is not only true of the murky evolutionary past. Over the last decade huge population studies have shown that social integration — the feeling of being part of a cohesive group — fosters immunity and resilience. How accepted and supported we feel affects the biological pathways that skew the genetic expression of a disease, while feeling isolated “leaves a loneliness imprint” on every cell, says the American social neuroscientist John Cacioppo.
And here’s the problem: being “more social” online doesn’t help:
Recent MRI studies led by neuroscientist Elizabeth Redcay tell us that personal contact elicits greater activity in brain areas linked to social problem-solving, attention and reward than a remote connection. When the identical information is transmitted via a recording, something gets lost.
I guess catching up for coffee is still better than texting.
Jessica McKellar gives some fantastic career, management, and leadership advice in This Is What Impactful Engineering Leadership Looks Like. The interview goes into detail on three main areas:
“When engineering management is done right, you’re focusing on three big things,” she says. “You’re directly supporting the people on your team; you’re managing execution and coordination across teams; and you’re stepping back to observe and evolve the broader organization and its processes as it grows.”
Even though the interview is focused primarily on engineering teams, it’s applicable to all types of leadership and management. Highly recommended.
Virginia Heffernan’s A Sucker Is Optimized Every Minute is a deeply cynical, extremely funny rant on our obsession with data:
These days, optimizers of squeeze pages, drawing lessons as much from the labcoats at Optimizely as from the big daddies at Google, recommend creating a three-to-10 minute video that’s introduced by a “magnetic headline” (“Find the Perfect Lampshade for Any Lamp”) and quickly chase it with an “information gap” like “You’re Not Going to Believe the Trick I Use While Lampshade Shopping.” (Article of faith among optimizers: humans find information gaps intolerable and will move heaven and earth to close them.) Next you get specific: “Click the play button to see me do my lampshade trick!” — after which the video unspools, only to stall at the midpoint with a virtual tollbooth. You can’t go on unless you hand over an email address. Presto.
A sucker is optimized every minute.
In How do Smartphones Affect Human Thought? Jenny Davis addresses the recent research behind the “Smartphones are Making Us Stupid” narrative:
[The research] hypothesis implies (though does not state) a research question: How does smartphone usage affect cognitive processes? This is an important question, but one the research was never prepared to answer thoughtfully. Rather, the authors recast this question as a prediction, embedded in a host of assumptions which privilege unmediated thought.
This approach is inherently flawed. It defines cognitive functioning (incorrectly) as a raw internal process, untouched by technology in its purest state. This approach pits the brain against the device, as though tools are foreign intruders upon the natural body. This is simply not the case. Humans [sic] defining characteristic is our need for tools. Our brains literally developed with and through technology. This continues to be true. Brains are highly plastic, and new technologies change how cognition works. Our thought processes are, and always have been, mediated.
I’ve been spending way more time with Google’s Material Design guidelines than I ever thought I would, but such is life.
Anyway, as I was going through it, and started to think about the Android side of an app I’m working on, I tweeted this:
Concerned about Material Design's reliance on label-less icons. Pretty sure most users don't know what these mean. pic.twitter.com/aH1IZvAyG6— Rian van der Merwe (@RianVDM) March 11, 2015
That screenshot is from the section on Icons in the guidelines, but it’s not the only example. The whole document is full of screen shots of label-less icons. There’s not a single label in the section on Typography.
There’s lots of research about why this is a bad idea, but I’ll just cite two articles on the topic. First, Aurora Bedford sums it up nicely in Icon Usability:
A user’s understanding of an icon is based on previous experience. Due to the absence of a standard usage for most icons, text labels are necessary to communicate the meaning and reduce ambiguity.
And Josh Porter also makes a good point in Labels always win:
I think labels should be kept around in almost all cases as they turn guesses into clear decisions. Nothing says “manage” like “manage”. In other words, in the battle of clarity between icons and labels, labels always win.
Beyond that, there’s also plenty of evidence from A/B testing that even much-used icons like the hamburger menu is simply not well understood (see Hamburger vs Menu: The Final AB Test). So, be kind. Label your icons.
Update March 16, 2015
I’ve received some interesting and helpful responses from the Android community:
@RianVDM on Android a long press should show you the label of the icon, it's required when you develop an app for Android— Omar Tosca (@otozk) March 16, 2015
My day didn’t start great. The first thing I read was Michael Dubakov’s statement about enterprise software people (i.e., people like me) in Enterprise software vendors have no taste:
My current theory is that enterprise software vendors have no taste. CEO, VP of development, Product managers that focus on enterprise market — all of them have no fucking taste. There is no taste in companies [sic] DNA, nobody cares about design and aesthetic. Profits, revenue, sales and new features — yes! Beautiful design — no.
Nobody, you guys. Literally nobody. I guess I don’t blame Michael for this false cause fallacy. It sure seems like a logical conclusion: product bad, therefore product person bad. As with most things, though, it’s more complicated than that.
Let’s start with the most difficult thing about designing in the enterprise space: in most cases, the people who buy the software and the people who use the software are completely different, and therefore have completely different needs. This is not a problem in the consumer market, where the person who gives you money is usually also the person who uses your product.
The people who buy enterprise software — IT managers, HR managers, etc. — care about things like configurability, control, more features than a competitor, and most of all: the ability to customize the thing just so, so that it fits in with whatever systems already exist. End users care about none of those things. They care about getting a job done as quickly and with as much enjoyment as possible.
So, what happens is what happens in most organizations that rely on outside sales. Many Sales teams go out and sell things that don’t exist in the product. And they often sign contracts that have two things in it that make designers wake up in a cold sweat: (1) a list of features (or — ugh, I hate this term so much — “product requirements”), and (2) delivery dates.
Product people then have to fulfill the needs of the contract/promise (as opposed to the needs of end users) in never enough time. Instead of having the time to understand a problem and user needs, building hypotheses and testing them, and taking time to iterate, they make a thing to hit a deadline and then move on to the next thing that has a deadline.
And that’s why enterprise software looks the way it looks. It’s not that product people don’t have taste. It’s that they don’t have agency.
But, I do want to say, there are welcome signs that this is changing. There is a new realization that the needs of buyers and end users can co-exist peacefully, and the result is better products. As an example, our new CEO is a huge advocate for design, and is pushing the organization to create “simple, smart, beautiful products.” This will take time, of course, but if you look at the new suite of apps that we’re working on, you’ll see that these are starting to look more like consumer products.
There are other things I think we can do to help along this shift:
- Train sales teams on the ins and outs of product development. How prioritization works, how long things generally take, what the major user needs are that the product is trying to solve, etc. If they have more knowledge about how their promises affect the teams, it will go a long way to change behavior.
- Spend as much time with end users as possible, record the sessions, and share it widely. Nothing gets an organization riled up about good design like seeing end users struggle with a product.
- Start on a small product that no one cares about (like the mobile site maybe?). Follow a Lean UX process (or whatever methodology you subscribe to). Build it well, and show people the results. Then start moving the process into other areas.
So, anyway. Yeah, enterprise software is still, for the most part, pretty bad. It’s time for us to break out of the constraints of the past that caused that, and do something better. It’s actually a good time to be in enterprise software. There’s so much opportunity, and a newfound agency for designers. I’m optimistic. The day can only get better from here.
I’ve been thinking about product feedback. We do alot of it at Jive, since most of our work happens in the open. It’s one of my favorite things about Jive and I wouldn’t change it for the world. We all want to make the best product possible, and you can only get that if you put everyone’s heads together.
So I’ve been thinking about how we can make sure we give each other good feedback. I went back and reviewed some of the things I’ve learned over the years about what makes product feedback useful. I wanted to share three articles in particular that have been really helpful to me. I’m going to try to use these techniques more, and I invite you to join in.
First, Mike Monteiro wrote a great post called How To Give Better Design Feedback (it’s now mysteriously gone from the internet, but I managed to resurrect a copy from my Pinboard archive and post it on Evernote). This part, in particular, is a great point to remember:
First rule of design feedback: what you’re looking at is not art. It’s not even close. It’s a business tool in the making and should be looked at objectively like any other business tool you work with. The right question is not, “Do I like it?” but “Does this meet our goals?” If it’s blue, don’t ask yourself whether you like blue. Ask yourself if blue is going to help you sell sprockets. Better yet: ask your design team. You just wrote your first feedback question.
Cemre Güngör’s How to give better product feedback is also a great article to go through, and this is some good advice:
Describe objectively what you expected and what the product delivered (or fail to deliver). Speak about your particular experience “I got confused when I used this…” instead of generalizing “This is confusing…” or speaking of hypothetical user-beings “Users will get confused…”. This should help disarm the team and empathize.
The worst kind of generalizations speak on behalf of the whole wide world: “Nobody will like/use this”. Being dramatic is unlikely to make the product team start thinking about their work in a new context and change their ways.
But my favorite article on this, because it provides such a great framework for feedback, is Jared Spool’s Moving from Critical Review to Critique. The whole thing is fantastic, and it goes over how to structure a good review. Here’s the gist:
What makes a critique different from a critical design review is we are not there to find flaws. We’re there to learn from the design and to explore where it works well and where it could be improved.
In a well-run critique, we explicitly separate out the discussion of “What are we trying to do with this design?” from the discussion of “Does this rendition accomplish it?” By separating out these two pieces, we avoid digging into the designer’s work just because they unaware of a critical requirement or need.
This part is particularly effective:
The audience also now can explore the design. Often this is done, not with critical commentary, but with exploratory questions. “Have you thought about how users will share the photos with their friends?” “Have you considered how the application works when there’s no network connectivity?”
By posing their thoughts as questions, the designer can say whether they’d thought about that issue or not. If they have, it gives them a nice chance to talk about their thinking. If they haven’t, well, they just say, “No, hadn’t thought about that yet.”
If you have any other tips on giving good feedback, please let me know!