A few days back my friend Cap wrote a great post about curiosity. In that post he postulated that curiosity is a must for (I assume) creative professionals, but, as I’m sure he’d agree, it applies to anyone.

In this I agree with him 100%. I had, coincidentally, been writing a similar post about Kickstarter and how much it inspires me. (And how much it drains my wallet.) My (as-of-yet not entirely formed) point was that we need things like Kickstarter to encourage and help those folks out there who are taking risks. By supporting ideas, even wacky ideas like some of what you’d see on Kickstarter, we allow for us to be inspired, educated and entertained, even if some of those endeavors don’t come out the other end as planned. As well, too many people are content with letting life pass them by. Those of us working in tech often forget that we’re not representative of the masses when it...

I’m not a huge fan of personas, at least not in the traditional UX sense. They’re kind of a “fuzzy” deliverable that often ends up taking more time than they’re worth and, if taken too seriously, can become a pretty poor stand-in for your actual customers.

Personas aren’t all bad though; I like to think of them as the coffee table book of UX design deliverables, and that makes them a least a bit interesting. They’re great for getting a conversation going—for setting a user-centric tone and keeping customers front of mind—especially among a group of diversely skilled people.

Regardless of my own personal bias, almost every team I’ve been on in has used them in some way or another. Some take them very seriously and others use them as a starting point to frame a discussion around customers, which is my preferred way. Probably because of that bias, I’ve got some ideas of how to make the...

I’m a big fan of lists. I’ve got lists everywhere: multiple to-do lists in multiple formats, item lists, shopping lists, people lists, goal lists, etc. One of my lists, and a favorite trick I use to remain focused, is to keep what I call the don’t do list.

The don’t do list is a list of things I’m not doing, or things I was doing and have eliminated from my to-do lists. It might seem silly, but the act of going through your projects and to-do lists and moving them to a don’t do list helps you prioritize and focus on the important things you should be doing. It also helps to shed light and add clarity to your process and workload. It’s pretty amazing to see all the things you could be doing but aren’t.

Keeping a don’t list is pretty straight forward. For me, I just have a big list in Evernote for when I record those things I’ve killed or said no to.

I do have a few rules:

• It’s...

Just the other day I was talking to one of my fellow Desk.com co-workers about our product and I mentioned that I thought we needed to be vigilant in maintaining our product’s opinion.

As you may imagine, a product like Desk.com has some significant challenges when it comes to meeting and exceeding the expectations of our user base. While we do have a few key customer types we design for, there is a great variety within those customer types as far as how they work, the kinds of customers they service and the needs they have for our product.

Desk.com is very flexible in some ways and while we’ve got a professional services team that—with a bit of magic and hackery—can bend and shape the product to suit some of our more demanding customers, one of our goals is to keep things consistant and maintaining a core product that is opinionated.

Products with a strong vision, that put forth a...

It was announced today that Square will be teaming up with Starbucks to handle their debt and credit card payments.

This fall, Square will begin processing all credit and debit card transactions at Starbucks stores in the United States and eventually customers will be able to order a grande vanilla latte and charge it to their credit cards simply by saying their names.

This is big news and a clear indicator, to me anyway, that leading by design is the way to go.

I’m sure I’m not the only one to make this observation. If you’ve been following Square, you know they’re a design-focused organization. Clearly they’ve got the chops there. But, if you’re living in San Francisco and used their products you also may notice they’ve got the process down as well.

Before they hooked up with Starbucks, Square hooked up with a smaller, local shop: Sightglass. It was big news back in 2010 when...

People occasionally ask why I write more about process than I do design.

The answer: great work comes down to execution.

Execution is first and foremost about people, process, discipline, focus and communication. It’s less about ideas, feasibility, knowledge, skill or tools. Those things are important, but without the former, you’ll have a hard time getting anything done with the latter.

As well, if you don’t have ideas, knowledge, skill, etc. you’ll need to work (practice) to gain those things. I believe that with enough hard (and smart) work you can learn just about anything.

But first, you need to learn how to work.

Wouldn’t it be cool to work on one project, or task, finish it completely, take a break and then move to another? Well, yeah, but it’s not very realistic.

Even if you’re focused on one larger project you’ve probably got numerous tasks within that one project that require you to regularly switch contexts. And don’t forget all the day to day distractions you’ve got to contend with.

Context switching is difficult. (And don’t get me started on “multi-tasking.”) The more often you have to do it, the less you’re going to get done. That’s a fact. :)

But it’s not just about productivity. What kind of hits to your stress level are you taking if you’re unable to focus? How much better would the quality of your work be if you weren’t having to jump around so much?

I’ve been reading Thinking Fast and Slow by Daniel Kahneman and while it’s much deeper in its analysis of how we think, it’s got...

Here’s a fun way to look at running projects: like a tamalada, which is a tamale making party. :)

A couple weeks ago I went to a tamale making class, or, as our instructor “The Tamale Princess” called it, a tamalada. The tamalada is essentially a party where you hang out with people you love, drink wine, chit chat and make a bunch of tamales.

Sounds fun, right? It is!

But it’s fun with a very clear purpose. The goal of the tamalada, historically, was to prepare food for soldiers out in the field. Clearly, that’s an important job! Now-a-days the purpose of the tamalada is more about gathering friends and family together, to make a lot of delicious tamales for everyone. The product, in some ways, is the process.

But let’s be clear. The tamale making process is work. And as I sat there, stuffing masa into my husk, I couldn’t help think the tamalada was similar to a very well run...

There’s a great thread over at Branch.com on shipping products. Well worth a read and probably a bookmark.

There is one particular passage from Evan Williams responding to Jason Goldman that really caught my eye. Goldman is talking about how you need to build something that delights you and that before you have users, you—and your team—are the user.

I’ve been thinking about this a lot over the last few weeks or so, as I’ve been immersed in the “Fail Fast” ideas of Lean. On thing that really didn’t work for me was the idea that you can just throw any old thing out there and learn from it.

A few months ago I heard this great interview with Ryan Singer where he talks about designers looking at and thinking critically a design before they build/show/ship it. I really agree with this. There are times when a designer can critically look at their own work (or ideas) and realize they’re...

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...