Notebook

This is a new thing I'm doing. During work breaks I'm mixing and recording. I'm rediscovering DJing and realizing how much I've missed it, so I'm making it part of my life again as a bedroom/studio DJ.

This is my first baby step in. Be gentle. Headphones on? Let's go.


Sunny Day Session by Konigi on Mixcloud

I love Berg's demo of their Cloudwash smart washing machine concept. The company created the prototype to demonstrate how a smart networked appliance might be better designed. The video provides an excellent walkthrough of their design process.

They simplify the face, which consisted of many controls for dedicated functions, reducing that to "high value functions" only. More functionality is accessible via a smart phone app, which also integrates the device with services such as warranty and supplies management and purchasing.

I haven't been very interested in the current offerings of smart appliances, particularly networked refrigerators and stoves, but the value of design in this concept is communicated so well that it is compelling. The future of networked appliances is also getting interesting with Google's acquisition of Nest, for example. The greatest concern I might have for core appliances is trust in the security and reliability of these products. Maybe I just watch too much sci-fi.

Ridley Scott, director of Alien and Blade Runner, talks about the importance of fast thumbnail sketching and storyboards in helping him make movies. Scott discusses how storyboards help him capture the imagery of scenes, and how talking through storyboards prepare the creative team by establishing a direction for what they intend to create.

Read more at the article on Open Culture.

Via Ian Smile.

We know that starting with why is important to product design, but what comes next? "How" would definitely come soon after. But there are many ways to propose how to begin exploring possibilities.

The 99u points to a number of questions to ask before starting a project, and how language matters. They refer to Warren Berger's article in the Harvard Business Review about one of the questions top innovators ask when confronted with a design challenge. It starts with the phrase "How Might We?" (HMW). It boils down to the selectivity and power of words, and in this case particularly with the choice of the word "might" rather than "can" or "should."

Here's why the words make a difference:

When people within companies try to innovate, they often talk about the challenges they’re facing by using language that can inhibit creativity instead of encouraging it, says the business consultant Min Basadur, who has taught the How Might We (HMW) form of questioning to companies over the past four decades. “People may start out asking, ‘How can we do this,’ or ‘How should we do that?,’” Basadur explained to me. “But as soon as you start using words like can and should, you’re implying judgment: Can we really do it? And should we?” By substituting the word might, he says, “you’re able to defer judgment, which helps people to create options more freely, and opens up more possibilities.”

Tim Brown of IDEO talks about how the words carry meaning for problem solving.

[W]ithin the phrase, each of those three words plays a role in spurring creative problem solving. "The 'how' part assumes there are solutions out there — it provides creative confidence," Brown said to me ""Might' says we can put ideas out there that might work or might not — either way, it’s OK. And the 'we' part says we're going to do it together and build on each other’s ideas."

Check out how IDEO are using the HMW phrasing at Open IDEO to get people thinking about and proposing how to solve challenges for social good.

I've been trying to do more to accentuate the positive, and keep conversations open to possibilities in my personal life and work, but it can be difficult to talk about solving problems without bias given agendas, missions, roadmaps, prior knowledge, and history.

Choosing the word "might" feels like one way to begin early problem definition and solving without the weight that comes from words like "should" or "can." It's like the freedom in the tentative and erasable nature of a pencil rather than the indelibility of a pen. "Might" leads to conversation that is open to consider different directions rather than saddling you with choices that feel cemented too early.

Min Basadur's story about discovering the concept for Coast soap at Proctor and Gamble embodies this idea of opening up the conversation. The word "might" can lead to re-asking the question, and maybe even realizing that you're asking the wrong one. What I love most about that story is that ultimately asking "How might we" led back to asking "Why?"

Along with the broader notions of starting with why, the HMW question seems a very powerful tool for facilitating design discussions and problem definition. I don't see very concrete, prescriptive techniques here, which is a good thing. The suggestion of asking the HMW question may be enough, but Brown warns that the size and types of design problem matter. HMW may not work for problems as big as "How do we solve homelessness?"

Read more about HMW in the Harvard Business Review.

Thirst Studios and UX Mastery kicked off their UXmas 2013 user experience design advent calendar. Every day throughout December in the lead-up to Christmas, a new ‘gift’ to the UX community will be revealed. It could be an article, a video, a sketch, or something else.

After repeatedly using a pattern of term + description to describe something, I wondered if other people in my Twitter-sphere used the same or similar language to describe a common artifact.

My question started:

I was wondering if people used different terms to describe either drawings made in software or on paper that describe a screen view at a high level of abstraction that uses only lines and labels.

Accompanied by this screenshot:

It's interesting to learn that we use so many terms to describe essentially the same thing, although some of the confusion in this discussion might be with understanding what I meant by my question:

Flow Diagrams, Low Fidelity, Doodles and Notes, Page Maps, Schematics, Storyboards, IA, High Level Concept, Gray Box Wireframes, Whatever the client calls them, Boxes and Lines, Blockyframes, Scribbles on Paper, Blueprints, Page Zones (also Zoning and Zone Diagrams), Models, Conceptual UI Sketches, Thumbnails, Sketches

You can imagine the challenge we have educating about the pieces of a design process when the language is so variable. The thread is captured at Storify.

Nice collection of design principles, and new to me. Design Principles FTW collects both universal and specific design principles and is curated by Gabriel Svennerberg at Meetod, Sweden.

I can't imagine email ever being the right way to critique design, or give feedback as a client, but nevertheless it happens, and Julius Tarng, who works on the Branch app, came up with some good advice for those about to give email, and those about to receive it. I think the advice applies for any feedback that's not face to face to face including chat and in comments.


  1. Get on the the same page

  2. Talk about what you felt, not what you think the user will feel

  3. Use past tense, not present

  4. Question constructively by asking for opinions, not challenging them to convince you

  5. Try to be specific, and avoid subjective words

  6. Don’t be dramatic

  7. Give the design some time, and ask yourself if that email needs to be sent now

Don't just read this list. Read the article at Medium.

Fastco interviewed Chrissie Brodigan, design and UX researcher at GitHub to talk about how they're using deprivation to study people's reaction to removing elements from a product.

The gist of the technique is to work with a set of participants who develop a pattern of use around a feature or design characteristic and journal their experience. After some time, at a point when they've had time to be accustomed to that thing, they take away or alter it, and observe through the journal what the users' reactions are to its removal.

It seems like A/B testing with a greater focus on qualitative measurement. Deprivation could be a powerful factor and tool for assessing value of features on both new and existing products. Designers and developers get to measure the features by removing them, and seeing how upset their users get within a controlled group. Removing features from an existing product is difficult, but the upside in measurement could be that features that have a cost to the user or vendor might turn out to be unnecessary, or the research could lead to improvement.

This is technique is new to me, but I'm not unfamiliar with the pain of having features removed for me, or the backlash you can experience when you change something as a designer.