Part of the problem with Customer Development and/or User Research is that not everyone buys into the value. It's hard, time consuming work and, in the end, the learning isn't always all that tangible. That can leave some people mystified or feeling like the effort wasn't worth much.
And, let's be honest, there can be times when you don't really learn that much. Not every customer interview, usability session or experiment is going to bear fruit.
Many people, for example, measure progress with hard deliverables: wireframes, code, etc. Getting these people to buy into working on something that doesn't directly go into a product as code, for example, seems like a waste of time. “Learning”, to some, might not seem like a valuable end game for the amount of work it takes.
I see value, a lot of value, in making sure we're working on the right things. But I also get the counter argument. Why not just build, test and iterate from the get-go? Let the data tell it and change the product accordingly. Well, you could do that. And you might argue (correctly) that it'd be an equal effort, and you'd still be learning things. With the benefit of having releasable code at the end. A compelling argument, for sure. However, that argument falls apart if you've built something that nobody wants and that's all you learn—what you did wrong. And this happens ALL THE TIME. Sure, you'll learn from your mistakes and you, hopefully, can pivot, but now you've got a pile of technical debt, design baggage, etc. Even if it does take the same amount of time and effort, wouldn't it be better to pin down your customer and market first, before wasting time on building? I think so. And focusing on your customer on an going bases is something I'm 100% sure there's value in.
I've got a lot of thoughts I need to work through about Lean principles as it relates to design, development and running a business. In the last few months I've been in several workshops, watched quite a few talks and videos online and bunch of relevant books (The Lean Startup, Running Lean, etc.). There is a lot of dogma out there, especially around running a company, and much of it, frankly, I'm not sure of.
What I am sure of is that if you're not involving your customers in what you're doing, you're probably not learning as much as you should be and you could very well be working on the wrong things. Involving your users/customers in what you're doing is always a good thing.
Learning from your users should be something you work into your process on an ongoing basis.
So, how can we make the less tangible effort that goes into learning something everyone involved sees value in? Well I've got a few ideas:
Tailor your process. Just as in individuals, learning is different for each team, company, product, etc. You need to figure out what you need to learn and then make a plan to learn/test that as quickly as possible and in a way that makes sense for you. For example, don't just literally follow Steve Blank’s Customer Development techniques and expect to learn what you should, let alone get your teams on the same page. I don't think the traditional Customer Development process works all that well for web apps, for example, once you're past the initial learning phases.
Scale appropriately over time. You'll want to figure out a scalable and repeatable way to keep learning from your customers on an ongoing basis. Customer Development will shift more into User Research, for example. You'll probably rely more heavily on metrics-based learning, etc. Be sure you're looking to adapt as you build and iterate on your process, and always have an eye on what you need to be testing and learning as your product evolves. Do this right and the value will become clear to everyone.
Involve everyone. It's pretty hard to deny the value of Customer Development or User Research when you're knee deep in it talking to customers. This has an added benefit, especially when doing field research and getting out of the building. An extra pair of eyes or ears, and someone to record notes so you can focus on listening, is great to have.
Overshare. Tell people about your learnings. Figure out a way to share everything with them all the time. Get feedback, get ideas for new learnings.
Try to get into metrics early. Do this, even if you need to do it by hand. People tend to love bite sized information and numbers work great, especially for management and engineering types. If you do interviews, for example, share regular reports with hard, meaningful numbers in addition to qualitative data.
A little teaching goes a long way. People love to learn, it's one of the reasons why this stuff is great. It not only directly informs your work, it's fun to do. Instead of expecting folks to blindly buy in—and let's face it, we all do that at times—you might look to take some time to educate people on the value of what you're doing. User Research is a pretty easy sell, you just need to take the time to sit down and explain why it's worthwhile.
Question everything. Including your Lean practices. None of this, in my opinion, replaces vision and having solid vision means knowing what questions to ask, who to ask those questions to and when to ignore the answers. :)
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 for everyone in the room. They all stared at this map with blue yarn snaking all over the place, doubling back on itself and making complicated twists and turns from one end of the building to the other. They understood for the first time that they were taking their sickest patients, for whom time was their most precious resource, and they were wasting huge amounts of it.
Love that. I'm wondering if I can use something similar to trace a user's path through a web app? This seems like a really interesting way to use analytics to visualize an experience. Something like an on-boarding process, for example, seems perfect for this.
It's a cool story about design, architecture, people and Lean thinking. I saw a lot of parallels to my own work as a digital product designer. The work itself is different, but the problems, and solutions, are similar.
I don't want to give too much away, you should really listen to this, but here are a few thoughts and observations to think about after you've done that:
I like the caveat that the process was difficult. Staff left, and people were largely resistant to the changes, it took quite a long time, etc. I think many people look at Lean processes and think that they're made to be faster and easier. This isn't really the case. Sure, they should help you focus on what's important and do that in a way that should save you some time and money in the long run by reducing waste and putting you on a path to working on the right things. But it's not easy.
I thought it was interesting that they brought in a former patient to help with the redesign. In this case they had a “customer” directly involved in the process, but the idea that the people being impacted by the design work should be involved is a strong one.
Towards the end they talk about continuous improvement and iteration. This philosophy, in my opinion, has many solid benefits. At Desk.com one of our mantras is “continuous improvement over delayed perfection”. Learning and adapting as an ongoing process.
If you've never heard of 99% Invisible, I highly recommend checking it out. It's a great show. If you have heard of it and you've not backed their Kickstarter, you should do that. :)
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 lot.
We’ve learned that we need to approach the problem with fresh eyes. The reason we started with email, iPad, and iPhone applications was precisely because they constrained our design and forced us to challenge old assumptions.
We’ve learned that, at its best, content is a dynamic blend of smart algorithms, smart networks, and smart people.
We’ve learned that reading the news — from the breakfast table and the water cooler to the coffee shop — is nothing if not a social experience. The news influences how we interact with those around us; it shapes how we understand ourselves and our world.
We’ve also learned that we care about the same things that Digg has always cared about — delivering the most interesting and talked about stories on the Internet. We have a lot to learn from Digg and the community behind it, and a lot of experimenting to do, and we’re chomping at the bit to get started.
The focus on learning is awesome and I think makes a damn good case.
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 rephrasing.)
I'd say I was familiar with most of the material, but much of what we covered was taught from a perspective slightly different from my own and the exercises really helped to bring practicality to a lot of what I know about Lean Methodology.
As someone coming from a design and UX background, having done a lot of the same things over the years but from a different perspective and with slightly different goals, I felt the workshop did a really great job of cementing what I've been learning about Lean Startup. It would be a really good intro to Lean for someone who didn't know much at all, and for someone like me, who's had a fair amount of exposure and who's been actively practicing customer development and other Lean-based activites, it was great practice and filled with quite a few unique little nuggets.
As well, the simple act of tying the language of Seth Blank and Eric Ries, etc. to things I've been doing for years (customer interviews, data-driven design, etc.) brought a lot of clarity.
The exercises, which take up most of the day, were well organized, for the most part, and designed with clear purpose. My team (all coworkers) actually came up with what we think is a fairly viable product idea and have a lot of what we'd need to start experimenting and learning. Never mind the product was an exercise, it was clear that the process is useful and practical.
The exercises were also very fun. :)
Overall, I'd recommend it. Especially to design, UI folks looking for a better, more focused way to work a make user-centered products. I don't see any upcoming on their events page, but my guess is they've got more in the works.
One quick aside: all of the exercises were paper based, which is great an I was really intreguied and delighted by all the paper around the LUXr space. Stickys, lists, notes, etc. are everywhere. It makes for an interesting and inspiring workspace. I love working with pen and paper and it's nice to see others who feel the same way. :)
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!)
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 example of having a smart backup plan for when things are broken. In this case semi-broken is better than not working at all, but, if you really think about it, sometimes broken and inaccessible is the better choice.
A broken experience makes for a poor experience, even if you can make it work. Have you ever stepped on a broken escalator? You might know it's broken, but it's never the less a very a strange and disturbing experience. Just yesterday I stepped onto a clearly un-moving escalator. It was super weird.
Apply that same theory to almost anything. When things dont work as they are expected to, they feel broken, regardless of if they're actually broken. Even worse, there are times when something is semi-broken might actually cause harm. Stepping onto a broken elevator unaware could actually cause you to fall, for example.
In those cases, and others where the behavior and experience is going to trigger something unexpected, it's best to take the time to explicitly set expectations, even if you have to interrupt the experience to do so.
Think back to the escalator; if you know its broken and you step on, you might still have a weird feeling, but you're going to be ready for it, and probably not too disappointed. If you step on not knowing; you're going to be shocked, or startled, and you may actually hurt yourself!
With a broken escalator, for example, it's probably a good idea to put a sign in front letting people know its broken. And I think it makes sense to put that directly in front of the entrance. Especially a down escalator. You don't want someone who's looking down at their mobile phone to misjudge and go tumbling down.
How this applies to digital products and experiences.
A good example of this with a web experience is A Book Apart's handling of PayPal's long time problem of mixing up addresses. When you place an order for a book, and you're getting kicked into PayPal's system, they remind you, not once, but twice—a necessarily heavy handed decision, in my opinion—that you should double check your shipping address. It's far to easy to accidentally pick the wrong address. The folks at A Book Apart know that, and have set expectations accordingly with a warning and a reminder:
This protects against miss-delivery that, regardless of who's fault it is, could reflect poorly on their products. It's also a nice example of how setting expectations can not only limit error and provide a safety-net for when things could go wrong, but can also bring a small nugget of delight.
As someone who's had a few PayPal address snafus, I know it brought a small smile to my face.
It's also useful to explicitly set expectation when a designed experience goes against expected convention. Take this message at the bottom of iDoneThis emails.
iDoneThis is a part of the slow web movement. After you email us, your calendar is not updated instantaneously. But rest up, and you'll find an updated calendar when you wake.
It clearly states that your completed tasks won't be reflected in the calendar right away. Aside from the mention of the “Slow Web” movement here, which I find intriguing, you'll note that they are very clearly setting the expectation that their customer's data isn't going to be updated right away.
This is key. Had they not done that, they'd surely have a boatload of people hitting them up asking why the information they'd just sent into the system wasn't there.
There is also the added benefit of instilling a sense of peace and confidence in their customers. The “rest up and wake” bit is really nice. Especially in a world that's always demanding attention. Assuming the information is available when they say it'll be, that's delightful. And a really great example of how setting expectations should work.
Bottom-line: make sure your product is setting expectations if something is broken, or an experience goes against accepted convention, and think carefully about what functionality you leave exposed when parts of your product aren't working.
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 you're building a particular product or feature. You should be asking who it's for? Does it solve a real problem? Can you back that up? Can you defend your design with solid answers to those questions?
At Desk.com, where I currently work as a Product Designer/Manager and UX director, we have occasional speaker lunches. They have been really awesome, I suggest doing that if you can. Anyway, last week we had Hiten Shah, co-founder of KISSMetrics, and he talked a lot about their process of customer discovery and how it informs product decisions. Was a great, quick talk. Hiten is a smart dude.
He talked a bit about previous product failures he's experienced and mentioned that he's learned to put learning over solutions. This is no surprise, he also mentioned he was a bit fan of Lean Startup methodologies and the Learn part of Build, Measure, Learn is, obviously, a big part of that.
In essence they test rigorously (as you'd expect considering their product is all about testing and customer development) to find out the answers to the questions “why” “what” and “who for”. Their customers are deeply involved with product decisions. That is awesome and how it should be. When I started at Desk.com (then Assistly) the first thing I did was get out and talk to a mess of people using the product. I asked them why they used it, how it helped them, what they needed from us, etc. Of course, because we already had a product, I focused on current usage.
(An aside, Hiten said something that really stuck with me. Somewhat related. He was asked how, as a non-technical guy in the beginning, he was able to keep up with all the tech involved with running KISSmetrics. His answer was great, and something I'm totally down with: having a desire to understand is the most important thing. Hell yes. I feel like you can learn anything if you really want to.)
I'm currently…ah…embroiled in the process of coming up with a new product from scratch. We had some strategic direction, and an idea of our target market, but the actual product is still largely undefined. I started out with a bunch of ideas but quickly began to have a ton of questions. Would this solution solve anybody's problems? Who would use it? Etc. Luckily my team and I had been learning a lot about Lean methodology and customer development so process was fresh in our mind. In one of our product meetings we decided to back things up and get out there and talk to people about what we thought we're problems they were having. We were solutioneering and had we continued down that path, our MVP might have been something nobody wanted.
We got out there and asked people about their problems. We didn't pitch a solution or feature set or product. We didn't have anything to pitch. Just a thought that maybe we'd uncovered some problems that could use fixing. And, after talking to a whole bunch of people, those problems began to come clear. We'd learned enough that we could begin to work on a solution.
The most awesome thing about this process is that it's repeatable—throughout the lifecycle of your product. You can go back, talk to your customers, learn from them and use those learning to inform your solutions on an ongoing basis. You should be doing that. Your designs—your products and features—aren't meant to be static. They should evolve and be iterated on over time.
Whenever you feel yourself solutioneering, take some time to back up and do some learning. Focusing your process on continuous learning will improve your products and designs.
(By the way, if you're an entrepreneur of pretty much any kind, and are curious, feel free to hit me up. I'd love to have more people get eyes and minds on our product idea.)
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 working in the realm of digital product design. Most of my focus is user experience and user interface, but I've got a lot (17-ish years? has it been so long?) of experience, a fairly broad skill set and a diverse background. I've worked in all kinds of teams on all sorts of products. I've made games, web apps, mobile apps, apparel, publications, educational courseware and more. I've also written about all these things in a variety of formats and publications. (You can find a whole bunch of archives at dkeithrobinson.com.) Writing and speaking used to be a big part of my life, but recently I've turned my focus towards the work itself; design, process and learning all I can about creating products that people love.
Here are a few of the things I've been thinking about lately. This list will probably change a bit by next week, I may even flip-flop a bit, as I reserve the right to do, but, hopefully, it'll give you an idea of what's on my mind.
great products put design and user experience first, but that true quality is a result of great teamwork across disciplines.
designers need to understand, on some level, the entirety of their craft and the medium they're working in.
product design should start with (and continue throughout a product's life cycle) understanding the user and their problems and that this is best done by taking with and listening to people. Preferably face-to-face.
research, experimentation, learning and iteration are key to successful product design.
writing (not code or “small d” design) is the most important hard skill a product or interface designer can develop. Soft skills (particularly listening) might be even more important.
knowing your audience, being able to defend your ideas and communicate them accurately to a wide variety of people is more important than mastering the tools you use to do design work. If you want to level up as a designer, work on writing and listening before you learn how to code.
the best things in life are done with intent and with care, but making the most out of happy accidents is a great skill to have.
passion, process, focus and hard work are more important then raw talent.
people can learn how to do anything if they're engaged and motivated enough.
a great idea is nothing without better execution, and with the proper framework and a lot of hard work, anyone can do great things.
the more people we have in our lives doing great work they enjoy, the better our lives, and our world, will be.
I think a whole lot about process and the hows and whys that go into what we do. I've noticed a lot of patterns in my career and have been keeping track of what is going on when success (and failure) happen. Most of the time it's nothing to do with lack of good ideas, expertise, skill set or anything like that.
Great work is enabled by: clear vision and direction, an organized and focused work environment, having the proper resources, a good work/life balance and ownership of your work. These are things that can help anyone be successful. And it's the absence of theses things that cause projects to fall apart. In essence, in order to do great work, you need to enable yourself (and those you work with) to do that work first.
I've spent a lot of time over the years trying to hone my process and to provide myself with a framework that enables quality, meaningful (and hopefully enjoyable) work. I'm still working at it and will probably continue to do so forever. I've still got a lot to learn.
I'm going to be writing about all of these beliefs and a lot more, but for those who prefer lists, here you go: product design, process, productivity, creativity, work/life balance, technology and the occasional music or entertainment post. At the end of the day this is a personal blog and, like me, it might be a bit all over the place. I hope you enjoy it. If there is something you'd like to see me write about, feel free to hit me up via the usual channels (see the sidebar.)
Back to lightning.
Before I sign this one off, let's quickly go back to lightning and how it relates to the title of this blog.
Lightning represents energy, transformation, opportunity, creativity, ideas, change and more. As well, it's symbolic of a spark and a catalyst.
If you think about it symbolically, lightning seems like something worth making, doesn't it?
Writing has always been a catalyst for me. It's pushed me to learn new things, to connect with new people, and explore new experiences. It has provided me with a lot of opportunity and a fair share of happy accidents. I'm hoping that starting this new writing project will spark something new. I hoping to create an environment for myself (and for my readers) that allows for experimentation, sharing, fun and adventure. And in that way, this is my small, metaphorical attempt at learning how to make lightning.
