Posts tagged: UX

You Can’t Order Coffee Without Software

By , August 22, 2011 9:59 am

I’ve often said, “There is software in everything.” You can’t buy gas without software. You can’t drive a car without software. You can’t book a flight without software. The plane can’t fly without software. You can’t make a phone call. You can’t pop your microwave popcorn. You can’t even order coffee without software.

Last Friday I was grabbing an early morning flight out of Salt Lake City and I had to have my coffee. I went to Starbucks and overheard the pain of the barista describing her morning with broken software. “The computers were down for 2 hours this morning.” I asked her, “So what was it like?” She described the painful process of having to manually write down every sale, manually key-in the credit card transactions, and then catch-up on all those transactions once the computers were working again.

Your company’s customer experience is defined by your software. The previous blog post gave a tale of two experiences, one good, one bad. The message was: It is perilous to ignore how your software makes your customers feel.

Technology is no longer the constraint.

Marc Andressen described it well in a recent essay in The Wall Street Journal on “Why Software is Eating the World”:

Six decades into the computer revolution, four decades since the invention of the microprocessor, and two decades into the rise of the modern Internet, all of the technology required to transform industries through software finally works and can be widely delivered at global scale.

There are many companies, like Starbucks, who focus on creating the best possible customer experience they can. The layout of the stores, the training of the staff, even the language they use around their products. All of this can be destroyed in a moment by poorly working software.

The customer doesn’t even have to touch the software for the software to destroy the experience.

If the customer-facing employees of a company are frustrated by the software they use to transact business, that frustration will spill over into the customer experience. The customer may not even know why they walked away feeling like they had a bad experience.

We stated many years ago that our mission is “…to end human suffering in the world as it relates to technology.™” It’s time for every organization to contemplate how their software can be used to enhance or maybe even define their customer experience. Those that have understood this have succeeded wildly in the past few years: Apple, Netflix, Amazon, Google, and Groupon, to name a few. We can probably all name companies who are equally defined by their software experience, albeit in a negative way. Those companies have either struggled or died.

Other than employees and investors, few mourn their passing.

A Tale of Two Experiences

By , August 15, 2011 2:24 pm

One of our favorite books is The Experience Economy by Pine & Gilmore. It describes the value that can be created by moving past commodities, products, services, and into experiences. I was reminded of this over the weekend, in a very real way.

It was time for a new pair of glasses. This is something I don’t replace that often, so quite frankly, I was a little excited. I stopped in at our local mall to visit the Pearle Vision store there. The selection process was both fun and compelling. My wife and I enjoyed the opportunity to explore different looks and styles, while finding something that was both functional and comfortable.

Then came the painful part.

Once we had made the selection, we sat down with one of the sales associates who collected the details to place the order. I probably had a hint of how this was going to go when the first words out of her mouth were, “This is going to take a couple of minutes while I reboot the computer.” Given the business I’m in, I’m sure I made some joking remark about “those darn computers.”

She then began filling in the details in what seemed like an interminably complex and lengthy process. She gave me some verbal indication that she was right near the end and then got the troubling look on her face as she was waiting for the software to respond. After a couple of minutes of waiting, she declared that the computer had frozen again and that she would need to restart the entire process.

What started out as as a pleasant Sunday afternoon shopping visit to the mall now had all the makings of a retail nightmare “waste of time.”

At this point, my wife lost interest and said, “I’m going to Pottery Barn. I’ll see you later.”

Apparently the second attempt actually worked. She then had to leave her station and travel back to the retail counter to enter my credit card information. I sat patiently, assuming this would be the quickest part of the process. Twenty minutes later I finally approached the retail counter to check in on progress. I must admit, my blood pressure was now rising.

I asked if there was any trouble and she said, “Nope. I just needed to help another customer.”

I completed the order and told them I would probably never return. I felt buyer’s remorse for the rest of the day. Even this morning I am contemplating canceling my order.

After this retail nightmare I stopped at the store next door. The Apple Store. I needed a new case for my iPhone 4.

The store was mobbed. It reminded of the Yogi Berra comment, “Nobody goes there anymore. It’s too crowded.” Sales associates were outnumbered by customers at least 10-to-1. (Unlike the 1-to-1 at Pearle Vision.) My wife and I had the same fun selection experience and then it was time to check out.

I caught the eye of a free sales associate. He approached me, scanned the item with his own iPhone, swiped my credit card, asked me if an emailed receipt was fine, showed me the email address he’d send it to, and I was done. In less than 60-seconds I was walking out the door with my new purchase.

I couldn’t help but reflect on how much effort Apple must have put into ensuring they could produce this kind of customer buying experience. I must admit, I seldom go to the mall anymore, but every time I do I excitedly visit the Apple store to contemplate future purchases.

These experiences hit home for us because they go to “joy.” I had no joy at Pearle Vision and thus I will look for more joyful alternatives the next time. The Apple Store not only gave me joy for that purchase, but also helped calm me from my previous bad experience at the place right next door.

When people ask me how to define “the business value of joy” in software design and development, I describe it as widespread adoption and enjoyable use by the people for whom it was intended. As we reflect on the tenets of the “Experience Economy” we fundamentally believe that customer “shopping, purchasing, and using” experience is what separates the winners from the losers.

Ignore this at your peril.

The Theory and Reality of Sunk Cost

By , April 4, 2011 11:07 am

We often find ourselves in discussions about sunk cost here at Menlo. Many of the people who walk through our door have already invested in a piece of software they are not happy with, they don’t want to start over and they just want us to “fix it.” This feeling of trying to preserve “sunk cost” often traps even the most rational minds. It’s often hard for us to fully appreciate and understand the set of emotions at play in such a conversation.

I had an experience this weekend that made it all too real for me.

One of my more serious hobbies is playing out my personal version of “This Old House.” I have always enjoyed the practical thrill of working with my hands to make serious home improvements. This month’s project is the den that my wife and I spend most of our time in when we are at home.

I spent this weekend tiling around the fireplace. For any of you who do this kind of project at home, you know that one of the most difficult aspects is making the material selection decision. My wife and I selected a tile that we thought would be beautiful. It looked so great in the store! A little expensive, but what the heck? We’re going to spend a lot of time in this room and exactly how often does one re-tile their fireplace?

I got about 1/3 of the tile up and my daughter stopped by to check on my progress. She and I were both staring at the partially finished job. There was silence. Long silence. Finally she asked me, “How are you feeling about it, Dad?”

Darn her. More silence.

“I don’t like it,” I admitted painfully.

“What are you going to do?” she asked.

“There’s nothing I can do,” I said, “I’m too far in to it. I’ve got to finish.” Talk about a decision that felt like it had been “cast in stone!”

Here was the moment of truth about sunk cost. How far into it was I, really? I had consumed just over $150 of tile and 3 hours of my time, and I was already painfully trapped by sunk cost. I couldn’t imagine starting the whole process again even though the mortar was still wet.

Fortunately for me, a voice of reason was standing just a few feet away in the form of my youngest daughter. She asked the painfully simple and honest question, “Why can’t you start over? Just pull off the tile and we’ll go to the store and pick out a new tile. You guys don’t want to spend the next 30 years living with a bad decision.”

She was so right and yet I was still tortured by the sunk cost. It was crazy. It was emotional. It was irrational. She prodded me just a little more and I pulled off the tile.

Yesterday I spent the day putting up the new tile we had picked out. The result was far beyond our expectations and we are thrilled.

There is no more remorse about sunk cost. All I see now is the results of a project that we will be happy with for years to come.


Are Personas Really That Important?

By , March 9, 2011 1:19 pm

NOTE: Today’s blog post is from a guest blogger Mara Evans, a former High-Tech Anthropologist® at Menlo Innovations.

I have a passion for the use of personas in software development. Perhaps part of that passion comes from my background in psychology and the study of archetypes. But more pragmatically, I think my passion comes from experiencing the power of their use as a tool to deliver successful product.

There are many books, articles and blogs that describe the standard and optimal uses of personas. I thought I would spend a few minutes discussing “practices” that I’ve observed in organizations that I believe are sub-optimal uses of the power of personas.

  • Starting with too small of a persona pool – Most sources that describe the use of personas recommend creating five or six. This may be an adequate ending point, but I believe there is a great deal of value in the process of developing personas with diverse traits. This can take the discussions much deeper about the discreet traits of the personas and help avoid the quick abstractions and generalizations that often happen when creating personas around roles. Otherwise, it is too easy to end up creating the “generic user” personas of which Alan Cooper warned in The Inmates are Running the Asylum.
  • Personas become static artifacts on the wall – Too many times I have seen this happen. A team spends the time and energy to create personas as part of their requirements gathering process. They proudly post the personas on their boards or wall….and then never visit, call or write! These abandoned personas have most likely provided great value in determining the general directions of development.  However, the power of personas is in their continued use and evolution. The personas should become “real people” in the minds of those designing and developing for them. Personas should be around to help solve arguments when making design or scope decisions. 
  • No prioritization or mapping of personas – Like the abandoned personas, personas that have been created, yet not prioritized are not being used to their full potential. A chorus of competing voices can put you back at square one. Immense value is gained from just the prioritization exercise alone. Often hidden assumptions of team members are uncovered and disagreements are made transparent – allowing the team to address them directly.   
  • Forgetting to discuss for whom one is NOT designing (referred to as negative personas by Cooper) – If a team is designing and building for the sales and marketing staff…then say so…make it specific and explicit. Don’t pretend that “user centered design” is happening when sales-centered design is really the focus. 
  • Personas are used instead of real users – it’s rarely possible to have a real, live user sitting next to the designer or developer. However, personas are often used as user stand-ins when potential users are readily accessed. I think sometimes we get so ingrained in the method that we forget the reason for the method in the first place.

Just creating personas does not make your project or design user-centered. Persona development is not about going through the motions. It is a craft that when honed brings great value to the journey, as well as the destination.

Technology Is No Longer the Constraint

By , March 3, 2011 3:19 pm

I watched the Steve Jobs keynote yesterday when he introduced the iPad 2. I can’t help but to reflect on my own career in software development.

I first laid hands on a computer in 1971, when I was 13 years old. I instantly fell in love and knew what I was going to do for the rest of my career. I must admit, seeing the iPad 2, I realized I had been waiting my entire career for this to happen.

We have now entered a new frontier in software. Technology is no longer the constraint. The constraint we face now is far more challenging and exhilarating. We now face the constraint of imagination. I don’t believe any of us can actually imagine the true possibilities of the iPad 2. The amazing convergence of size, weight, capacity, elegance, design, and speed, partnered with the myriad technical features give us (the programmers) a canvas on which to paint that is unequaled in mankind’s history.

I was in a discussion yesterday with a couple of young men, students from the University of Michigan. Like many Menlo visitors they were curious about my entrepreneurial journey. Recounting that 1971 beginning, coupled with the iPad 2 announcement, I shared with the young men that I was so lucky to be in a profession 40-years on where I still have “little kid excitement” for what I do.

I now find myself excitedly looking forward to the next 40 years of my career.  Thank you Steve Jobs and thank you Apple for keeping the dream alive.

The NCIS Effect

By , February 7, 2011 5:30 am

My wife Carol is relatively new to the software industry. She is now in the role of Factory Floor Manager here at Menlo and gets involved in many of our presales efforts. She has developed a great appreciation for what we do, how we do it, and the effort involved in creating great user experiences for our clients.

The other day she asked me a question: “Why do most of the people who come in our door think that what we do is easy?” She asked me this while we were watching one of our favorite TV shows, NCIS. The technological tour de force in that show is nothing short of astounding. If only the world worked like that!

All of their systems are seamlessly integrated. They always present exactly the right information instantaneously. They seemingly answer every subtle question intuitively. And the coup de gras? A user interface that responds to hand motions on transparent glass displays wherever the users happen to be.  (We are just waiting for the episode when some programmer walks on to the set and says he just snapped it all together in an afternoon with open source software!)

We believe many people walk in our door after having watched the same episode we watched the night before and in their mind’s eye they want their software to work the same way. We call this the “NCIS Effect.”

Fiction has always played an important role in the advancement of science and technology. Often we must dream it first before we can actually build it. Turning that fiction into reality is not impossible, it’s just every day plain ol’ hard work. And hard work ultimately translates to cost.

It is absolutely our desire to create joyful user experiences for the users of our clients’ software.  Sometimes the NCIS Effect creates a desire for “cool” over “joyful” or “usable” or “useful”.  Sometimes the NCIS Effect creates the impression that this stuff is easy and quick.  That’s a myth.

Creating that great user experience is not about hand waving either in the user interface or in the project definition, but rather about really connecting with users in their world.  Our High-tech Anthropologists® meet those users in that world and find out what is really needed to create a joyful experience.  We might call it the Human Effect.

And that’s the Effect that makes all the difference.

The Role of Humility in User Experience Design

By , January 24, 2011 4:10 pm

In our last blog post we lamented the difficulty we have when new clients start with the assumption that our lack of domain expertise is the insurmountable obstacle to beginning a project.  We noted that part of a great design practice lies in the ability to draw on domain expertise without having to learn it all.  Domain expertise and design expertise are roughly equal in importance for success.

There is a third leg to this stool, however.

Equally important is the ability to discover the difference between what the domain experts know and what their intended user audience knows. This is often where the term “stupid user” first creeps into the vocabulary. We might hear from time to time, “Yes, our users are really smart about science, but they are stupid when it comes to understanding our software.”

A little piece of us dies every time we hear that.

Herein lies the greatest opportunity for dominating your market. If you learn the world of your intended user audience, you have the opportunity to discover the simple design changes that will confound your competitors. This is the reason we refer to our designers as High-Tech Anthropologists®. The only way to discover these opportunities is to spend time studying users in their native environment. It’s not about surveys, focus groups, or clever interview questions. It is about compassionate observation, curiosity, and — quite frankly — humility.

Why humility?

We make loads of design mistakes as we move incrementally toward a great design. We never ask during design assessments whether or not people like our designs. We ask them to accomplish a small goal with the design in front of them. Often they struggle to use what we first believed was a fine user interface. It is in these struggles where the greatest opportunities for innovation occur. As soon as they get stuck trying to accomplish a goal with the design we’ve put in front of them, we ask a simple question: “What were you looking for?” Similarly if they make a “mistake” with the interface, we humbly allow them to continue without correction, noting the need to circle back and identify the source of the design error.

So again, why humility? Without humility we are not likely to bite our tongues when a user takes an unexpected turn. Without humility we would proudly “teach them” why our design is correct. Without humility, the designs we create would only work when we are sitting there with the users.

A humble attitude fuels our most powerful design belief:  there are no “stupid users,” only stupid designs.

The Joy of Great Design

By , August 16, 2010 11:43 am

Of all the things that make Menlo Innovations special, our High-Tech Anthropology® practice probably falls into the category of “most special.” It is our High-Tech Anthropologists® who first coined the mission “to end human suffering in the world as it relates to technology.™”

We fundamentally believe that there can and should be joy in software design and development. How does joy manifest itself for a software team? Beyond great collaboration, a fun work environment,  and team members you enjoy working with, there is one over-arching characteristic that defines joy: thrilling the end users of the software we design and build. Building software is hard work. Knowing that our hard work is improving the lives of others is the greatest single source of satisfaction for our team. I believe this is true throughout our industry.

The other day I got to feel this joy up-close and personal. I was doing Weekend Warrior work around the house and found myself in the Ace Hardware parking lot loading bags of topsoil into my Saturn VUE. I had to block-in another car to ease the loading process and as luck would have it, the owner of that car showed up at just the wrong time. I apologized and said I’d be be finished in a couple of minutes. His reaction was fun and unexpected. I was wearing a t-shirt from one of our top customers, Accuri Cytometers. He pointed at my shirt, smiled and said, “I use that product every day!” I commented that my company built the software that goes with the product he uses. “I love that software. You guys did a great job!”

I was reminded in that moment of the joy produced by great design.

I made sure to share that story at Monday’s daily stand-up. Everyone smiled. We’ve known for years that we did a good job, maybe even a great job, on designing and building the CFlow software for Accuri Cytometers. However, it never hurts to hear an unsolicited testimonial from a happy user.

Kidnapping a User Seemed Like a Good Idea

By , April 1, 2010 11:48 am

I frequently see teams implement a bad strategy that came disguised as a good idea. I call this strategy “kidnap a user and make them part of the development team.”

As you know, I am a strong proponent of involving real users in the software development process. The question is, “Is kidnapping the user and making them part of the team a good way to elicit user input?”

The answer, “Absolutely not.”

The reasons this strategy fails are too numerous to fully catalog here, so I’ll cover just the top few.

First, it fails with how candidates are selected. Typically, this is a very benevolent kidnapping. Its starts with the development team polling the end user community and asking, “who would like to be kidnapped?” We saw this plan play out at a scientific company. The end user “scientists” who jumped up and down and called out “pick me” had a significant bias: they didn’t want to be scientists any more. These “typical” end users were learning Java at home and really wanted to be part of a software team instead of a scientific team. Can you already sense the danger here? The resulting system was very usable – by power users, or at least by “one specific” power user. But the average user did not find the resulting application either useful or usable.

When I asked the development manager about the application, he told me how “great” it was. I asked him how many target users there were for the application. He indicated there were about 300 potential scientific users at this lab. I then asked him how many were actually using it. The answer, “About six.” How sad. He expressed his frustration to me. They had made multiple presentations advertising the availability of the new application, but no one was following up to actually use it. Within six months, this entire development team was laid off. An unfortunate but predictable outcome.

You cannot kidnap a user and make them a member of the development team because any user willing to be kidnapped, by definition, does not represent the user community.

A second problem with kidnapping a user is that the user rapidly becomes a “former user.” The Stockholm Syndrome kicks in and the kidnap victim begins to identify with their captors. They start to accept the explanations that intuitive interface is simply “too hard” to implement. It doesn’t take long before the developers have fully brain washed the captive user, and the user begins to think of the “computer” as the dominant force in making interface decisions. From here it’s a slippery slope into the morass of “file selection dialogs”, “standard user interface widgets from Microsoft” and other “standard practices” in building user interface that leave the real users saying, “What were they thinking?”

At its core the “kidnap a user” approach is irreparably flawed. Any users repeatedly exposed to designs during the process of software development are unconsciously “tainted” by the process itself. Assumptions become facts, facts become reality, and serious blind spots develop. A screen that is not intuitive at all seems intuitive to the “kidnapped user” after they have seen it 100 times.

A proper software development process requires not just one user, but a continuing series of fresh users, users not tainted by earlier drafts and earlier tests.

When Hollywood is testing a movie to see how well an audience likes it, they never bring an old audience back to see if they like the next cut better. They get a fresh audience. We believe the same is true of showing test users incremental interface designs.

So what can be done?

The simple answer is: leave the users right where they are; that is, where they are the most useful to you. In fact, the most useful users are the ones who would be frightened to death if you asked them to join the “development team.” They’re convinced that they have nothing to offer since they aren’t very “computer savvy” (and don’t want anybody to find out how little they really know about computers).

Here at Menlo, we refer to the High-tech Anthropology® team as the “Voice of the User” team. Their job: be an advocate for the users. These folks are not the developers, but are empathetic, sympathetic, patient observers and listeners who discover over time what the end users actually need to do their job. They discover the vocabulary, the customers, habits and rituals of the end user community. They pay attention to every little detail along the way – and they know how to communicate with the development team.

I hope this has given you a fresh perspective on what might be hindering your efforts to build truly useful and usable software.

Dumbing Down the User Interface

By , March 26, 2010 7:31 am

I can’t tell you how many times someone comes to me saying, “Rich, our product’s user interface is way too sophisticated for our average user. We’ll really need to dumb it down.” One person went on to say, “Our users are as dumb as a bagful of hammers.”

It’s not clear to me that this attitude can ever be changed within an organization once it has been allowed to fester and grow. But it doesn’t really matter; the problem is self-correcting. In the long run, these companies won’t last.

In today’s economy, average users are learning to recognize the difference between products designed with their needs in mind and products that are designed by engineers and for engineers. And users are voting with their pocketbooks. Feel free to take aim at these competitors; they’ll be an easy target for you.

So let me offer you a significantly different (dare I say fresh?) perspective on “dumbing it down.” James Goebel, one of the co-founders of Menlo, was confronted with this “dumbing down” statement recently. His response was wonderful. He told a story about how “automatic landing” of the space shuttle was added to the user interface for the pilots. A simple sequence allowed the pilots to have the shuttle proceed “hands free” to touchdown in Florida. James told them he didn’t believe there was ever a shuttle pilot who thought of this great simplification as “dumbing down” the user interface. We’re pretty certain this was considered “smartening up” the user interface to make the pilot’s life simpler and safer.

This is one of the challenges in our industry. When a High-Tech Anthropology® team does excellent work, it’s often significantly “under appreciated”, particularly by the experts.

The experts look at the result and say, “It’s so simple, it must have been obvious. Why did it take so long to design?” It reminds me of the quote attributed to the author and mathematician, Blaise Pascal, “If I had more time, I would have written a shorter letter.” The same holds true for user interface designs. The best designs take longer, yet you end up with a simpler interface, with far less clutter. Of course, people wonder what it is exactly they paid for. The answer is simple: they paid for all the work that ended up on the cutting room floor.

A good High-Tech Anthropology® team will strive to produce the simplest thing that can possibly work (and no simpler!). The users will be thrilled and the product will enjoy widespread adoption by average users who will (perhaps unknowingly) appreciate the elegance and simplicity of the well thought-through design.

I wish you great luck in taking the time to write a “short letter” to your customers.

If you do, you will dominate your market space.

Panorama Theme by Themocracy