Category Archives: Uncategorized

Today’s Tiny Wow: Basis

While I often focus on the big picture, sometimes the little things stand out and wow me. Yesterday, I got my Basis Band. This fitness watch measures all kinds of things from steps taken, calories burned, sleep quality, heart rate, and much more.

One thing I noticed quickly was that whenever I checked the time, the backlight went on. This is very helpful and a clever use of the accelerometer in the device. It detects the wrist movement that means ‘checking the time’ and turns on the backlight.

This is not remotely necessary to the function of the device, and I can easily touch one of the metal nubs on the face to turn on the light (another tiny wow), but this small behavior adds a bit of delight and intelligence. I wonder if there are any other gestures that the device recognizes?

‘How to change the CEO’s mind’ – My Response

The following was in response to Mark Hurst’s recent post How to change the CEO’s mind.

UX rarely has power in an org. Often, we must convince those who make decisions that to do what we recommend is beneficial to the company, their teams, and to them as individuals (not necessarily in that order). It’s a permission game. The more permission we are given, the better we are able to do our jobs.

Sometimes we have champions in the org that recognize our value and what we can deliver. Often there are those who at worst know the UX buzzwords and at best aren’t willing to give UX enough of a priority to be effective. Those are the cases where we don’t have much permission to act and can be frustrated at our lack of impact.

In these cases, a more modest approach may be necessary. Each additional bit of value we deliver and can take some amount of credit for will typically give us a little more confidence and permission until we have earned the trust of the one with the power. That can take time. Sometimes a lot of time.

A key decision as practitioners is whether it is possible to change this person’s perspective and if it can be done in a timeframe we are comfortable with in terms of our own growth and career (and whether there are other options available). I’m not saying quit as soon as you hit a wall with a stakeholder. Recognize that change takes time. Recognize that not everyone will change. Decide whether you have the patience to wear down the rock.

That being said, I agree with Mark. The transformations that stakeholders can have from seeing real users interact with their product can be amazing. However, as many commenters pointed out, you need to have permission to first do the testing and then for the stakeholders to trust you enough that they are willing to change their minds based on the test results in order for it to be effective. This is less about the techniques you employ then it is about your relationship with your stakeholders.

Pulling the what?

It’s a classic struggle, up there with good vs. evil and IM vs. grammar, and that is the struggle between scope and resources. It’s a familiar tale to anyone who has ever had to get anything done at any time, even if its only the weekend chore list. I had a professor who said, “Fast, cheap, and good. Pick two.” You likely had a mentor at some time with a similar maxim.

While deadlines (fastness) can move, there is only so much time available, so that leaves scope (goodness) and resources (cheapness) as the two things to manipulate. Rarely do those in charge want to do less. It happens, and when it does, it can be wonderful. Typically, however, stakeholders push for as much as they can get.

Then just add more people, right? Sometimes that isn’t possible and sometimes it’s not desirable. There may be limited resources (cash) that prevent a team from hiring. It may be a tight market with few qualified candidates. Even if the right people are out there, it will take time to find them, bring them on board, ramp them up, and make them productive. That will add an additional drain on the existing team. In the long term, if a larger team is called for, it’s a necessary and proactive sacrifice, but if may not help, and may exacerbate, an existing short fall.

If time is finite and scope is larger than the resources available, what is to be done? Well, the short answer is cut scope. Of course, it’s not that easy.

Today, I’m not going to offer anything new to help solve this problem. I’m still working on that myself. I had been frustrated with how to succinctly describe it. I was talking about scope as the unstoppable force and resources as the immovable object, but it didn’t work that well.

While sitting with a colleague in a conference room talking about this, I said, “Caleb, you have kids right? You’ll get this. Remember when Winnie the Pooh ate too much honey and got stuck in the entrance to Rabbit’s Howse and everyone tried to pull him out?” Caleb nodded.

“We’re pulling the bear,” he said.

I may not have helped anyone solve the problem, but, hopefully, now you at least have an amusing way to describe it.

The gang tries to pull Pooh out of Rabbit's house

The gang tries to pull Pooh out of Rabbit's house

Ira Glass, Killer

You may have seen this video on the 37 Signals blog, but it was so evocative for me that I wanted to add a few additional thoughts. First of all, I’m a big Ira Glass fan. If you’ve never listened to This American Life on the radio (or the podcast on iTunes) or seen it on Showtime (or bought the shows on iTunes), I highly recommend it. It is modern documentary story telling at its finest.

In this interview excerpt, Ira Glass is talking about finding and developing the stories that will eventually make it to the show. Watch it. It’s short, ~4mins.

In their post, 37 Signals author Matt focused on the ‘less is more’ theme, how we have to be relentless ‘killers’ in order to maintain focus in our design. This is one of the reasons I started this blog. An efficient process should lead to a focused design. 37 Signals already addressed this, so I wanted to talk about some of the other points in the video.

Glass says that his team spends most of their time not in production or editing, but in looking for the story. In user experience, that is our focus as well, finding the meaningful story that dramatically improves the product for our users and justifies the development efforts. We talk to people, understand them, and figure out the plot of our users’ experience and design how we will bring it to resolution.

He talks about interviewing people constantly so that you will eventually find that one person with the really evocative story that will be meaningful. If you’ve done usability testing, ethnographic research or some related activity, I’m sure you’ve had this experience. You see a trend developing and there is one person who expresses the need in such a succinct and memorable way that it solidifies your understanding of the problem. Sometimes it’s the opposite, where there is not a trend, but you hear a story from one user that you may not have heard from anyone else, but based on what you know, it feels true and universal.

We only have these insights when we continually engage with the community.

One of the aspects of agile that I was drawn to immediately, was the emphasis on involving the users. It was exciting to read about an ‘engineering’ process that was embracing user centricity. Finally, UE and development could work together with a shared understanding of the importance of user engagement.

Unfortunately, the reality can be much more challenging. As the drive for new features increases, the time and resources available for user engagement diminish.

So what can we kill so that something better will live?

Where’s the fire?

It has been quite some time. I wanted to give Drew’s comments some thought before responding, but the gap has more to do with sleep deprivation than soul searching.

I thought I’d look at what kind of companies are driven by the sales process. From my experience, these are companies that are typically either consulting companies, start-ups with few clients, or large products that depend on a small number of very large deals.

Consulting companies are a no-brainer. If you don’t succeed in the sales process, you have no deal, no money. Ideally, salespeople work to build long term relationships, but it doesn’t always happen. These are also the cases where I’ve seen annual budgets come into play on the client’s side. A client may have a limited budget for a period of time, typically the fiscal year, and they are going to use a significant part of it on professional services for the proposed engagement. This makes them feel like they need every feature they can possibly imagine delivered over the course of the engagement. Their rationale is that if they don’t get it during the 3 or 4 months they’re paying for consultants, they will have to wait until the next time budget cycle. Of course, most of the engagements I’ve seen have been waterfall and not iterative. That would be one way to address the concern.

For start-ups with few clients, the need for revenue and to please these few clients and partners often leads to acquiescing to many demands. I’ve been on the partner side in the past, where I’ve heard it said that the risk of working with a new company is often offset by the price and the ability to dramatically impact the product development. This can also happen with companies whose product management or product vision has not quite matured.

Large, expensive products often have long sales cycles and sell fewer licenses per year. The power of these deals often can exert significant influence over the product design in order to satisfy the customer. I’ve also seen product companies with no strong user experience expertise engage with clients with no strong user experience expertise. As you can imagine, this resulted in the product company having a list of clients that their sales people were not allowed to reference because the implementations were so poor. If they were asked about one of these clients, there was a canned response they gave and then dropped the subject.

For companies with mature product management and many smaller companies, it seems less likely that any single customer will exert enough influence to significantly effect the design. So why are there the same problems? In my comment, I hypothesized that these organizations are still choosing to develop/refine features based on existing knowledge, rather than spend time validating or performing new research. Why is that? Are we really under the pressure we think we are? How important is the first-mover advantage?

One of my favorite examples is from the removable hard drive war. At the time, Syquest was the clear leader in the space. When most people still used 1.4mb floppy disks, Syquest offered 44 and 88 megabyte cartridges. They were large, but they worked well. Then along comes the Iomega Zip Drive in 1994. It was fast. It was cheap. It held 100megs in a fraction of the space of a Syquest disk. It was also a piece of crap, and yet four years later, Syquest filed for bankruptcy. So it would seem that being first means a lot.

On the other hand, we’ve got Apple’s iPhone. Launched in 2007, it was late to the game. Smartphones had been around for anywhere from 5 to 14 years, depending on what you consider the first one. Little more than a year later, it is the most widely used mobile browser in the US. That may not be a measure of financial success, but clearly, they have put out a product that has changed the way the mobile computing experience is measured.**

So where’s the fire? Or more importantly, is there a fire? Should we rush to market like Iomega or take a slow and careful approach like Apple? Which approach do you prefer? Have you experienced both? What do you think are other salient success stories? Jason at 37Signals thinks urgency is poison. What do you think?

**Disclosure: I don’t yet use an iPhone. I’m patiently waiting for the next version.

I Forgot!!! Happy Cheese Weasel Day!

This is a bit off topic, but April 3rd is Cheese Weasel Day. This is one of my favorite holidays. Read on.

Unknown to most, April 3rd is Cheese Weasel Day, the holiday where the Cheese Weasel brings dairy goodness to all the good boys and girls in the tech industry. While the origins are murky, it seems to have started around 1992 when a weasel was spotted carrying a Kraft Single. This, they assumed, must be the Cheese Weasel, and therefore, that it must be Cheese Weasel Day. What was the weasel going to do with the cheese? He must be off to put it under the keyboards of good tech workers everywhere.

The practice of the holiday seems to spread through word of mouth. I first heard of it when I showed up to work on April 3rd many years ago and a fantastic spread of exotic cheeses was laid out in the middle of the office. It wasn’t until a few hours later, after the food coma had started to wear down, that I started to think about the legend, “The Cheese Weasel leaves cheese under the keyboards of good tech workers… cheese under the keyboards… keyboards.” I looked, and there was a cheese single, still wrapped. I wonder how long it would have lasted had I not found it.

The holiday does seem to be growing. Each year, more and more sites show up with a reference to the holiday or the song (yes, there is a song). One site even offers Cheese Weasel Day (CWD) ecards. The methods of celebration vary. Some prefer to celebrate with the best cheeses and freshest baguettes, while others eschew that practice and insist on keeping with the tradition of cheese food singles.

For many years, I brought cheese to my office on CWD, but this year, I forgot. I will make amends soon, and you can too. Spread the joy of dairy goodness!

Thanks to John @ crunchgear for reminding me.

Pointing the Finger

The problem is sales! (well, inheritance, but it’s not as catchy, so I’ll say sales. See this post for more.) Is this because sales people are a bunch of greedy, selfish, blood sucking leeches? Occasionally, but mostly not. Most salespeople worth their frequent flier miles do have some regard for the organizations they work for and the people who will ultimately deliver what they have sold.

I think there are two primary issues. The first is explained by the old adage, “you get what you measure,” which could be modified for salespeople as, “you get what you pay for.” How are these people typically compensated? Usually, their pay is tied to a percentage of the selling price. So they are incented to sell as much work as possible for as high a price as possible. Nothing in there about project success. There are a few places that do compensate based on customer satisfaction, but few look at the long term success of the project. No one hangs around that long. Can you imagine how things would change if a person’s commission was based on client satisfaction, on-time delivery, the final margin, and whether the project met the long term business goals set out in the beginning of the project?

That leads us to the second cause, which I believe is historically long delivery cycles. People are used to long waits in between releases. If it will be a year or more before changes can be made, you better believe I’m going to try and get every feature I can into this release. The irony is that most of these features aren’t used. Jim Johnson of the Standish Group noted that 64 percent of the features in a typical system are rarely or never used. (1) On the one hand, that boggles my mind, but on the other, I’m not surprised. Just think of how much faster the next release would come if you didn’t have to design and build that 64% of features that will hardly see the gentle click of the mouse.

Here’s the rub. Given a fixed time and budget, the more features I want, the less time I have to spend VERIFYING THAT THESE ARE THE RIGHT FEATURES TO BUILD! Let’s follow the logic. The longer it is between releases, the more I need done now. The more I need done now, the less time I have to validate that what I’m doing really solves my users’ problems. I’m starting to wonder if it’s much more than 64% that goes unused. We know intuitively that less is more, but now we attach a business value to it.

The latter is one of those problems that agile/iterative/lean/etc. development is intended to solve. You get less, but at regular intervals.

That begs the question of how can exert influence when we are fighting a poorly conceived compensation structure and the weight of years of experience? Thoughts?

(1) Johnson, “ROI, It’s Your Job.”

Balance

Before jumping on others, assuming this is their fault, let’s take a moment and look at ourselves.

My job is to be an advocate for good user experience, but more than that, it’s to contribute to a successful project delivery. It’s good to remind ourselves, and our team mates, of that. Often, the business owners are concerned with getting their features in the next release, the engineers just want to build something that works, and we want to design the best experience possible. The conflicts are obvious. Something that is important to the business may not be desirable for the users. The great design we come up with may be very difficult to implement.

So step back. We’re all in this together.

To be successful, we must balance the business needs, the user needs, and the technical needs. These are the three legs that our project stands on. If one is short, we fall.

This doesn’t mean give in to the needs of the other groups. It means show some sympathy for the pressures they face. Try to understand what is driving them and their needs. This helps us make better design proposals and will likely make others more sympathetic to what we are trying to do.

Do you think this is the way to go or are there enough others fighting for what they want and we should defend our turn?

Inheritance

Sorry for the delay in posting. I’ve been battling the flu for a week now. I’m much better, but not yet healthy. However, I can finally concentrate enough to write something coherent.

First of all, I want to thank those who wrote for their thoughtful and articulate comments. I think you nailed some of the core issues from a variety of perspectives. I won’t address all of them individually here, but they will give me material for a number of posts.

To some extent, this has validated, and also refined, my idea of the biggest root cause. What is clear is that it isn’t part of the traditional design process. Novel ways to gather user research don’t help you convince someone of the need for it in the first place or that a project should sacrifice time used for feature development for validation instead. Improving requirements gathering, use cases/stories, wireframes, etc. aren’t what is holding us back.

Initially, I would have said that the root cause was the sales process. That perspective comes mostly from a consultant’s point of view, but its the same in product companies as well. Everyone has customers. Sometimes those customers are who you sell your product to. For others, the customers are internal. Before design begins, promises are made. That’s where our problems begin. The sales process. The commitment phase. I’ll-say-anything-just-sign-here. Whatever you call it, it’s a problem of inheritance. We are given conditions to work within that handicap the project before it has even begun.

Do you agree? How much impact do you have upstream on the conditions your design team inherits?

In upcoming posts, we’ll look at why this happens and what we can do to effect positive change.