I love this quote from Suzanne Slatcher, who worked at Pixar in the early years. From the really interesting article Building The Next Pixar:

“Business is just an idea, like a movie,” says Slatcher. “What if we did this in this place at this time, in this style of packaging, with this choice of flavors? Would it work? There’s still a back and forth between creative and the audience, and you can’t be like ‘if I build it, they will come.’ No, we’re in a democratic world where everyone has opinions. If you’re making your cartoon and your joke’s not funny, it’s just not funny, it has to go. If people don’t like a flavor, they’re right, we’re not right.”

That last sentence is a key concept in product development as well. If people don’t like our “flavor” of product, they’re right and we’re wrong. We have to fix it, not try to convince them that they don’t “get it”.

Gary Graham writes about some of the dangers of the smart city movement in Too-smart cities? Why these visions of utopia need an urgent reality check:

Ideally a future city will have inner-city areas that are sustainably created through private, for-profit initiatives, and investment based on genuine competitive advantage — not through artificial inducements, charity or government mandates.

The people living in cities far outnumber the people making decisions about what those cities should look like in the future. They are disconnected from the plans being made by companies and even governments on their behalf.

We need to start working with everyday citizens to find the right questions — and then work with them towards developing solutions to the problems they raise.

The article also mentions the city of Brasília as an example of a failed experiment because it didn’t take the needs of its citizens into consideration. That’s a topic that’s near and dear to me:

Together, we can avoid building digital Brasílias — projects that generate buzz, but don’t meet the needs of the people who live there.

Peter Seibel discusses data-driven design at Etsy in his post Building websites with science. After going over the dangers of relying solely on A/B testing for product decisions, he concludes:

Ultimately the goal is to make great products. Great ideas from designers are a necessary ingredient. And A/B testing can definitely improve products. But best is to use both: establish a loop between good design ideas leading to good experiments leading to knowledge about the product leading to even better design ideas. And then allow designers the latitude to occasionally try things that can’t yet be justified by science or even things that my go against current “scientific” dogma.

This echoes Julie Zhuo’s thoughts in The Agony and Ecstasy of Building with Data:

You can’t A/B test your way into big, bold new strategies. Something like the iPhone is impossible to A/B test. If you had asked people or invited them to come into the lab to try some stuff out, they would have preferred a physical keyboard to a virtual one. If you had them use an early prototype of the touch screen where not every gesture registered perfectly, it would have felt bad and tested poorly. […]

Data and A/B test are valuable allies, and they help us understand and grow and optimize, but they’re not a replacement for clear-headed, strong decision-making. Don’t become dependent on their allure. Sometimes, a little instinct goes a long way.

This all relates back to the difference between variation (trying out different ideas) and iteration (small changes to improve an existing idea). A/B testing is great for iteration, but not for variation. For variation we need our brains, and lots of paper and pencils.

Evie Nagy did a fascinating interview with danah boyd about her new book, It’s Complicated: The Social Lives of Networked Teens. On how teens use Facebook and Twitter:

They’re also more likely to have protected accounts, and use it to talk to a small group of their actual friends. To them Facebook is everyone they ever knew, and Twitter is something they’ve locked down to just a handful of people they care about — which is often the opposite of how adults use them.

A lot of the teens I talk to, they’ll have like 30 followers. It’s a small world for them, as opposed to trying to grow large followings. There are teens who are themselves microcelebrities, which is a different game. There are also a lot of teens who use Twitter around interests. An obsession with One Direction, and just talking to other One Direction people. That becomes Twitter, and then they’ll use Instagram with another group of friends. This one girl I talked to said, ‘Yeah, if you’re not into the things that I’m into, don’t follow me on Twitter.’

I’ve long been a fan of danah’s work, so I just bought the book and can’t wait to read it.

Related, Kayleigh Roberts wrote a very interesting article on how teens try to get celebrities to follow them on Twitter. From The Psychology of Begging to Be Followed on Twitter:

It’s not rare for a teen who is spamming to reach what is known as the tweet limit, something that the average user of the site might not even know exists. The tweet limit is 1,000 tweets per day, and many teens reach it regularly, especially when seeking the attention of a celebrity. It may seem excessive, but celebrities with millions of followers receive so many tweets, that it’s easy for even 1,000 to go unnoticed. Reaching the tweet limit can happen by accident, but it’s often a premeditated decision.

This is a world I didn’t even knew existed. I feel pretty old right now.

Mark Boulton’s How we work is a great post about their design process. I particularly like his point about personas, a method that I have defended before as well:

The tool is not the important thing here, [what’s important is] how you can use something to help people think of other people. To help an organisation to think of their customers, or designers to think of the audience they’re designing for, or the CEO to think in terms of someone’s disability rather than the P&L.

What I find generally useful about running a workshop like this is that it exposes weaknesses in an organisation. If a client pays lip-service to a customer-centric approach, it will soon become very evident in a meeting that that’s what’s going on.

I also like his view on agile in an agency environment: “We make things and then fix things as we go.”

MG Siegler in Going Against The Grain:

We’re seeing over and over again now that the behemoths can’t simply add a startup’s funtionality into their own app as a feature and kill said startup. But it’s equally important to note that if you are able to establish your startup, especially those in apps form, it may be hard to get your users to do anything other than what they originally came to do. Especially if the new funtionality is against the grain in any way.

This comes back to understanding what job users hire your product to do for them, and realizing that it’s very difficult to convince them to use the product for a different job.

Sean Madden makes some interesting points in American-Centric UI Is Leveling Tech Culture — and Design Diversity:

Just as user-centered design transformed technology in the 1990s and early 2000s, cultural fluency needs to transform it today: user experience (UX) design that’s familiar enough with a user’s cultural background to meet him or her halfway.

Cultural fluency demands abandoning the idea that functionality is a universal language, and that “good UX” is culturally agnostic.

He goes on to give some examples of this cultural bias:

Consider the use of gestural interfaces in a world where gestures mean very different things in different cultures. Or using scrolling for timelines when time horizons (among other culturally sensitive dimensions) represent different values to different societies. Even the idea of touching our screens is a culturally sensitive UX action.

We see this not just in how people use products differently, but also how we interact with them during the user-centered design process. Last year I started working on a talk called The challenges and opportunities of user-centered design in developing nations. Somewhere along the line I ran out of steam with it, but I still think it’s an important topic. For example, a usability lab in an office full of Macs and giant screens can be quite intimidating to users if you’re doing research on low-end phone usage, so that’s something you have to account for. Even our user-centered design methods need to be user-centered, but it’s unfortunately something we tend not to pay much attention to.

In Snow Fail: Do Readers Really Prefer Parallax Web Design? Eric Jaffe reports on a recent study done at Purdue University by graduate student Dede Frederick:

“I’ve read from many blogs how people say it’s going to attract users and create so much of a better user experience,” Frederick tells Co.Design. “I thought it was going to be superior to a typical website in every aspect.”

As it happens, the parallax site was only superior in one sense — fun. None of the other survey measures indicated a significant difference in user experience between the two sites. Parallax didn’t even edge the standard site in questions about visual appeal (although participants did think it looked slightly more “professional”). Frederick also discovered one critical disadvantage of parallax: test participants who suffered from motion sickness found the style disorienting.

This doesn’t mean parallax scrolling can’t be used well, just that we shouldn’t jump on every new design fad without understanding its usability impacts first.

I’m a big fan of the recent move away from user stories to job stories to design better products. Alan Klement provides a good overview in Designing Features Using Job Stories. That said, I’m worried that personas are on the verge of extinction as collateral damage of this evolution. We can’t let that happen. Alan explains his issue with personas as follows:

The biggest and most pertinent problem with Personas is this: Personas are imaginary customers defined by attributes that don’t acknowledge causality.

These attributes, generally in the form of demographics, do not bring a team closer to understanding a customer’s consumption, or non-consumption, of a product. The characteristics of a Persona (someone’s age, sex, race, and weekend habits) does not explain why they ate that Snickers bar; having 30 seconds to buy and eat something which will stave off hunger for 30 minutes does explain why.

The problem with this argument is that it refers to marketing personas, which are generally not very useful for design. Marketing personas are usually based on segmentation data, and ends up being mostly about demographics that cluster similar groups of users together.

But we shouldn’t confuse marketing personas with design personas, which are specifically created to guide the development of product features. How are they different? Well, first and foremost, design personas are based on needs, goals, and dimensions that have a direct impact on their interaction with the product. In other words, they incorporate causality, which takes care of Alan’s gripe.

For example, below is a design persona for a short-term loan company. There are a few things to note:

• There’s very little demographic detail — just enough to help us get to know this persona. Most of the persona is focused on their goals and needs, and what they want to accomplish.
• Note how causality is all over the story and the goals — Monde needs a loan now for an urgent need. This is very different from someone who just wants some money for a new TV.
• The key to these types of personas are the dimensions, or in this particular case, the loan drivers. Note that for Monde, the monthly instalment is not important. What’s important is that she gets the amount she needs to pay for her travel. For the persona that just wants a TV or some new shoes, this is different. For that persona the amount is less important — what’s most important is whether or not they can afford the monthly instalment.

My point isn’t that job stories aren’t necessary. On the contrary, I think job stories are much better than user stories for product design. But job stories are a valuable augmentation to design personas, not a replacement for them. There is still a huge amount of value in personas. They have names and faces, so the whole team can picture them. As opposed to a mythical “average” user, they are solid people we can imagine using our product to achieve their goals. This is helpful because by focusing on individuals that are closer to the edges of the experience, instead of the average, we’re able to cater design for a larger portion of the user base.

In the documentary Objectified, Dan Formosa from Smart Design says, “What we need to do to design is to look at the extremes. The middle will take care of itself.” As an example, he talks about how they once designed garden shears specifically to cater for people with arthritis. They knew that if the shears worked for that “user”, it would work well for everyone. That’s the power of personas.

I understand and agree with the concern that personas can sometimes be oversimplified caricatures of users that don’t take specific situations and actions in consideration. Without proper research personas also tend to be be shallow and not very useful. But those are dangers that are easy to avoid. Remember that personas aren’t prescriptive, they’re descriptive. You can’t identify a persona and then try to predict people’s behavior off it. But with solid research and analysis you can use personas effectively to help focus development efforts on target users, and help define what features should be included in (and just as importantly, excluded from) the product.

As a side note, in addition to the job story format I also sometimes like to use what I call problem stories. These are like user stories, except that they incorporate “triggers”, which takes causality into consideration. The format I use for problem stories are:

User has problem when trigger.

For example, a Product Manager on a financial services product might have a problem story that states, “Investors are not able to submit supporting documents online when they need to make changes to client portfolios.” That becomes a statement of the problem that needs to be solved through product improvements, and a good way to develop features by focusing on user needs.

All this to say that job stories (and problem stories!) are great ways to guide product and feature development. But if we use them to replace design personas, we’ll be throwing tons of useful context and understanding out along with it.

David Streitfeld takes an interesting look at the complicated relationship between digital and physical books in Out of Print, Maybe, but Not Out of Mind. This part jumped out at me, because it points to a mistake companies often make:

“A lot of these solutions were born out of a programmer’s ability to do something rather than the reader’s enthusiasm for things they need,” said Peter Meyers, author of “Breaking the Page,” a forthcoming look at the digital transformation of books. “We pursued distractions and called them enhancements.”

As Barbara Nelson points out in Who Needs Product Management?:

It is vastly easier to identify market problems and solve them with technology than it is to find buyers for your existing technology.

That’s the mistake that many ebook companies made. They let technology lead, where the better solution is to be led by user needs.