PrinciplesChris Palmier

AQ Works • Omotesando, Tokyo • August 20, 2015

Chris Palmier is a co-founder and principal at AQ, a digital product design studio in Omotesando, Tokyo. We spoke on integrating user research into every part of the process, solving the real problem, and avoiding solutions that are kuki yomenai.

 

Research how to improve people’s lives, not how to sell them something 

Assume you know nothing

Go into a new situation with an open mind and leave all your assumptions at the door. Moving to a foreign country is a great way to slap yourself into that skill. If you’re designing for someone with a different cultural background, you start from the assumption that you know nothing, more humble.

It’s interesting for Eiko [Nagase, AQ’s cofounder] and I to work together because we can fill in the blanks for each other. One of us can go in with an open mind, with less bias, and the other one can fill in the gaps.

Solve the real problem

It has to do with how business is operated, on structural level. You have a department, who’s been given a budget, to build a piece of software, because someone decided this is a software problem. And if you research it, software isn’t going to solve it.

But since decision-making is a one way street, that guy can’t give his budget back, can’t ask for the decision to be reversed. Often, companies are doing research and can’t even act on it because they’ve already predetermined their solution.

 

Identify the transaction a user is making with your product

Mediate the transaction

There are three different types of transactions in software: person→←organisation, org→←org, person→←person. Each party is bringing something to the transaction: time, attention, idea, money.

The software articulates the rules of the transaction. We’re designing the way the transaction is presented to each party: the benefits, the risks, the way you engage in that transaction. We’re designing mediation.

Design the most basic level

There is very little you can say is objectively true unless you’re designing something for a very small, narrow group of users. So, when designing for millions, you have to bring your expectations of the thing down to the most basic level.

Consider those very practical things like loading pages, order of loading, [and fundamental human values]. Filling your life with beautiful aesthetic experiences helps point you in the right direction.

 

Broaden your product experience before narrowing it

Add complexity as you gain certainty

Ask the most blunt, basic questions at the beginning of your product, and add complexity as you gain certainty about what this user wants out of the transaction.

We’ve all gone through a customer support system that dead-ends you because they ask a question at the end that they should have asked at the beginning.

Let the user narrow themselves

It’s not about dropping someone into a fully formed experience where they don’t need to do anything. That’s not a good experience because you as an individual you can’t take ownership of that, it’s just something that’s happening to you.

If you leave a little bit of meaningful effort on the person on the receiving end of the experience, that can help them form a memory and also grasp meaning from what they’re doing.

Read the air

We call a bad product “KY”. That stands for kuki yomenai, or "cannot read the air". One who says things that are badly timed, or inappropriate, from lacking awareness of the social chemistry of the moment. Not knowing how to read the air, particularly for a teenager, is the worst. A lot of bad software is KY.

There are aspects of software that should remain invisible. But on the other hand, you don’t want to be guided around by a ghost. At the right moment, it should peek out and help. It’s not about the software becoming invisible, but more polite.