I’ve been slowly working my way back through old 99% Invisible episodes and I came across one that really grabbed me. Probably because it resonates with a lot of what I’ve been doing and thinking about lately.

In this episode the story is about how Virgina Mason, a hospital in Seattle, used learnings from Toyota’s production process to make their hospital better (and save money, etc) by striving to reduce waste (in this case patient waiting rooms, etc.) and construct an environment that put the customer (the patients) first.

This entire, multiyear overhaul started with a ball of blue yarn. The staff met with a Toyota Production System sensei and he took out the ball of blue yarn and a map of the hospital and told the staff to trace the path a cancer patient would take on a typical visit for chemotherapy treatment. When they were finished, it was an immensely powerful visual experience...

Betaworks and the News.me team are re-thinking, re-designing, re-building and re-launching Digg and they’ve put a call out for feedback. We saw something similar with Flickr this week.

I love this stuff. Put a public stake in the ground. Share your ideas and intentions and ask for feedback and help. Only good came come of this. Bring interested parties (customers, users, etc.) in and give them a feedback mechanism. Open up the process. Of course you don’t have to act on every idea or criticism, but taking the time to listen and think about feedback from outside makes for better products.

I particularly love this part, where the News.me team justifies why they’re right group for the job and shares what they’ve learned in the past:

We’ve spent the last few years building news applications, and diving deep into how and why people find, read, and talk about the news. And we’ve learned a...

Yesterday a few of us from the Desk.com product team attended a Lean UX workshop, hosted by Kate Rutter, over at LUXr. My overall impression? The workshop was really good. Kate was an engaging speaker and the material was well thought out and delivered in a fun, informative way.

To sum it up: it’s an intro to Lean Startup methods focused on User Experience-minded folks and very early stage startups (or early stage products). It doesn’t go too far, but covers user research/customer development, the basics of Lean and a bit about metrics-based research and learning. The goal of almost everything we were taught was about either learning or focusing on what’s important. Awesome.

(Note: they actually call it “User Experience for Lean Startups” but I felt it was really more about Lean Startup than UX. Might just be my take though, and, to be honest, there is a top of overlap, so forgive my...

Just as you should have a clear vision and clear expectations for your product, your product should convey a vision and clear expectations to your customers. People work better, and are generally much happier, when they know what’s expected of them and when they know what they can expect.

Managing expectation is a big part of product design. Especially when things don’t go as they should. Having something work is just the beginning.

The amazing escalator. And Mitch Hedburg.

Recently I was reminded of a great “design joke” by Mitch Hedburg. (Thanks to Roman Mars and the awesome 99% Invisible podcast!)

The Joke goes something like this:

I like an escalator, man, because an escalator can never break, it can only become stairs.

There would never be an escalator temporarily out of order sign, only an “escalator: temporarily stairs.”

Sorry for the convenience.

Escalators are a great...

Back in the day, when I was one of the owners of Blue Flavor, a design and UX shop, we used to use the term “solutioneering” quite a bit. I don’t use it near as often today, but I still love the term. In essence:

Solutioneering is the term used to describe the act of working up a solution prior to really understanding the problem that solution is set to solve.

—Definition by me, D. Keith Robinson. :)

It’s a common practice. I’ve been guilty of it. You’ve been guilty of it. It’s not always bad, as good ideas can come from solutioneering, but you should always stop at some point and ask yourself some questions about what you’re doing.

Know why.

This probably sounds obvious, but here it is: it’s very important to know why you’re doing something. This is particularly important with product design. You should be asking yourself (and your teammates, and your customers, etc.) why...

Jon Russel over at TNW Entrepreneur highlights a few cases where startups, in this case declining startups, are failing to communicate with their users and doing potential damage to their products in the process.

All startups are inherently focused on their users to help them grow, but that same focus needs to be maintained when companies are in a less successful position, or perhaps even a downward spiral towards closure.

Yep, this is true. And I think it should be obvious that successful companies are those that communicate with—and listen to—their customers.

In my mind it’s the single most important thing you can do if your designing or building products.

Last fall I gave a talk down in New Orleans at Tribecon where I explained part of my design process. It’s called Talk/LISTEN and it pretty much sums up my approach: get out there and talk to people.

I don’t know how to make lightning. Hell, I don’t even really know how to spell it. Is it lightning or lightening? Both?

Lucky for me, I don’t think anyone knows how to make lightning, so I can get away with the obnoxious (and slightly misleading) title of this blog.

Regardless, I think lightning is interesting. Assuming we could make it; can we control it? What would we do it with? What is its purpose? Why would one want to make it?

I make things. These are questions I ask a lot.

So, what is the purpose of this blog? I’ll get back to that in a bit, but first let me tackle a more pertinent question: What am I going to be writing about here? Well, lots of things, but let me start by giving you a little backgrounder on me and how as it relates to my writing here.

Danger is my first name.

(Ok, no, it isn’t, but that would be cool, wouldn’t it?)

I’m a designer and product manager...