Comments (1)

By Rich, 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.

Comments (0)

By Rich, August 13, 2010 11:43 am

was not choosing Menlo Innovations to do our software design and development.”

- a former prospect having coffee with me the other day.

Arrrggghh.

This is a common theme and there is no joy, no schadenfreude when I hear this.  My frustration does not stem from the lost revenue, losing to the competition or simply a missed opportunity.  The maddening part is that a good idea didn’t make it to market and the product wasn’t widely adopted.  There will be lost investor dollars and another company that one day soon will close it doors, or perhaps  just limp along rather than enjoy enough success to hire more people, expand into other markets, improve the overall state of the economy.

When I hear this lament from former prospects, I ponder why? There are a variety of reasons they chose another path two years ago.  Sometimes they have their own internal resources, sometimes they have an existing relationship, sometimes they just believe they can get things done less expensively.  Somehow, they decide they didn’t need what we had to offer.  We could see at the beginning that they were headed for trouble, but its way too self-serving to harp on that point.

So for those who are contemplating starting a software product effort, I encourage you to think about these things as you launch the effort to build the software product you dream about:

1.  Your budget may be wrong. You likely have a $number in mind for how much it will cost to build the software.  How did you pick that number?  What if you chose the wrong number?  What is the cost of being wrong?  Might you expend your entire budget and only be half done?  If you end up 50% done when the money runs out, the “market” will conclude you are 0% done!

2.  There may actually be strong evidence that suggests your budget is wrong. Have you thought about how much others have spent to build something similar?  Its amazing how much information is available to see how much others have spent on building something close to your imagined system.  Find that information and be mercenary about challenging your own assumptions about “how easy this is going to be?”

3.  Your plan has too many “Miracle Occurs Here” boxes in it. Designing and building solid, competitive software products that thrill end users is plain ol’ everyday hard work.  Miracles never happen when you need them, and each time they do, they are typically offset by “catastrophe occurs here.”

4.  Your plan to build a quality team is flawed. Too often the plan to build a great team starts with an e-mail akin to “Rich … if you know any good programmers who are looking for work, tell them we are building a team that’s going to bring an awesome product to market.”  How will you know they are good programmers?  How long will it take you to figure that out?  How will they organize the work?  How will you know they are doing a good job?  How long will it take to figure out if they are not doing a good job?  Who will do the “non-programming” work of project management, user experience design and quality assurance.  What approach will be used?

5.  Your plan lacks ruthless focus! Who exactly are you building this for?  Trying to be all things to all people means you will not serve anyone well.  Everyone will be frustrated.  Having a specific target end user audience in mind is critical to success.  Bad Example: This patient appointment product will be used by professional services firms such as doctors, lawyers and dentists.  Good example:  Dr. Alicia Zahn, DDS has her own small dental practice that she has run for 17 years.  She is frustrated with her current patient scheduling system because …

There are many other pathologies that lead to failure.  I will touch on those in future posts.

There is hope.  It can work.  Success is possible.  There can and should be joy in software design and development.  The ultimate joy is when a user stops you in a parking lot and thanks you for the wonderful software you built for them.

I wish you joy! in your efforts and results!

Comments (1)

By Rich, May 4, 2010 1:51 pm

I love to spend one-on-one time with customers away from the office, where people drop their guard and tell you what they are really thinking.

Recently at a breakfast meeting, an old friend and Menlo customer asked, “Rich, don’t you need expertise in the particular domain of your clients in order to do an effective job at High-Tech Anthropology®?”

My answer surprised him. I told him that when our High-Tech Anthropologists® do have domain expertise in a particular business we typically DON’T ASSIGN THEM TO THAT PROJECT! Not having domain expertise in our client’s business is a key strength for our High-Tech Anthropology® team.

Needless to say, my friend was surprised at my response. But I went on to explain that without domain expertise, we are not “unconsciously competent” in the domain of our customer. This allows us to bring a very fresh (one may even go so far as to say refreshing) perspective to their domain.

Upon reflecting on my seemingly contradictory approach, my friend recalled his previous job at AT&T. They were looking to design a new phone handset, and they called in the famous industrial design firm IDEO to help with the design. As IDEO began bringing in new, fresh designs to AT&T’s labs, the long-time AT&T domain experts would instantly assess why none of the new designs would work.

As it turns out, the domain experts were too close to the problem, and knew too much history. They were in fact wrong. The final result: A fresh new design that was VERY successful for AT&T, despite all the nay-saying domain experts; a design that would never have been produced by their domain experts.

A good High-Tech Anthropology® team DOES need domain expertise. But that domain is the process and practice of High-Tech Anthropology®. The team uses their practices to carefully harvest the business domain expertise from business domain experts and from real users.

Our industry is plagued by the mistake of hiring “business domain experts” to join or lead the development teams as the “voice of the user.” As soon as these “experts” join the team, they begin a very rapid descent into being a “former industry expert.” Suddenly they understand how “hard” it will be do something “intuitive” for the users and how compromises must be made in the user interface to accommodate the technology team’s approach. As soon as this transition occurs, the game is lost. The users are the ones to pay the price – over and over again each time they use the software and each time a new user is introduced to it.

If the “expert user” avoids falling into the trap of over-identification with the technology team there is still a second trap almost every expert user we’ve ever met has definitely fallen into: they believe that because they were a user once they can easily speak for all users now! We call this using the “Mirror Persona.” “Mirror Persona” discussions are best characterized by “I.” “I don’t think it should work like this.” “I think it would be better if it worked like this.” It is a trap to hire and rely on “domain experts” when it comes to designing your products’ user interface. Domain experts play a very important role in every company. They represent the core competence of a company’s offering in the marketplace. They provide excellent feedback and guidance in the development of a software product.

However, they are anything but “average” users and will never represent the heart of your target market. Therefore, they will fail EVERY TIME to design an intuitive user interface for the average user.

The next time you are tempted to let a domain expert design the user interface for your product (or evaluate the one designed by your engineers) ask yourself this question: How many domain experts are there in my industry? The answer to that question will roughly define the maximum market size for your product. Then ask: how many “average” users are there? Those are all the people who will not be able to enjoy using your product.

I wish you great success in defining a user interface that thrills your end users and enjoys widespread adoption among your target audience.

Comments (0)

By Rich, April 29, 2010 9:56 am

At Menlo we combine High-Tech Anthropology® with agile software development. We find that agile teams allow us to deliver our projects faster and with better results – including increased adoption of the software by the user community.

I’m often asked, “Shouldn’t we spend more time writing requirements?” The subtext to this question is “If creating usable software is so important, shouldn’t we spend more time getting the requirements and user interface specification perfect before writing even a single line of code?” The obvious answer would seem to be yes, spend months or years, however long it takes to get the requirements right. Unfortunately, this answer is wrong. Too many times I’ve heard the story of a “year long specification process” that ended in no results at all.

“We had one of those kind of projects”, lamented a student once at a class I was teaching. “We spent $18M and a year developing the specification and when we got done, we threw it away.” Sensing the entrepreneurial opportunity, I quickly responded that I would be happy to write the next throwaway spec for half that price! “That’s only the half the story” he went on. “The first time we spent $30M with the same results.” I asked if the story was really accurate and another student replied “Rich, the real question is, which one of our four projects that failed like that was he referring to?”

One organization spent close to $100M to gather requirements, that resulted in no working system. There are many reasons efforts like this fail. One I would like to focus on today is that fact that many organizations spend too much time and money writing requirements without getting working systems in front of real users. This is one problem that agile software development seeks to solve.

Users vote with their keyboards. If they don’t like a piece of software or if it doesn’t produce better business results, they won’t use it. If user’s don’t use it, sales people won’t be able to sell it (at least not for long). This is also true for in-house IT projects where “selling” the results of the project can still be a difficult proposition.

What we’re ignoring in all of this is human nature. It’s why anthropology is such an important element. Anthropology is the study of human behavior. Without studying the humans, the machines cannot be programmed properly. And we can’t just ask the users what they need, because they can’t always express it. This is an important point worthy of repeating – the users don’t always know what they need! We must observe them and then show them what we discover as we go along. Early on, we may be wrong no matter how well we listen. We may be wrong because the users only discover their real needs incrementally, as we tease it out of them with early mockups, prototypes, and incremental releases. Only as they see and work with real systems will their true needs be fully revealed.

The results can be stunning. We’ve seen competitors literally exit a market upon the release of such a product design effort. We’ve seen users thrilled and businesses achieve a dominant position in their chosen market.

“Shouldn’t we spend more time writing requirements?” No, most of you are already spending too much time writing requirements without getting feedback from real users. Instead, embrace an agile development process that allows you to get feedback by putting real working results in front of real users. This isn’t easy, because it’s so different. It’s difficult to break the mold of our old behaviors. But it is possible. We just need to start acting differently, now!

Be encouraged, be courageous, be strong, and be agile.

Comments (0)

By Rich, 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.