Monthly Archives: February 2009

Do Disruptive Startups Need UX?

By agile, , , , , ,

According to Clayton Christensen in The Innovator’s Dilemma, markets for disruptive technologies may not be known prior to release and therefore often cannot be planned for. Where does that leave UX? How can you do research if you don’t know who to talk to? How can we do any user-centered design if we don’t know who the users will turn out to be and how they may use the product? So what is the value of UX in an early stage start up or similarly innovative team?

While he doesn’t say so explicitly, his research seems to favor an agile approach. Constantly evaluating  the product to determine who is using it and what value they are deriving will allow a team to focus their efforts on the goals most important to this new found audience.

This points to two clear uses for UX in the early stages of the creation of a disruptive technology. The first is to give the product the best chance of success by inc0rporating design standards and best practices. The second is in researching the new population of users, their activities, goals, and behaviors.

You only get one chance to make a first impression. Leveraging interaction standards will help give a new product the best chance for a positive initial reaction. Design standards may not work for everyone. They are, by definition, generic. However, it will make the product most likely to be usable by the broadest possible audience. In addition, while aiming for ‘just barely good enough,’ make sure that there is a shared definition of the level of quality required and that there is a UX component to that definition.

Once the first release is live, analyze the user activity. Reach out to some of the most active users. Talk to them about what they love, what they don’t like, how they found out about you, etc. Keep probing each answer for more detail. Find some users who signed up but never became active. What made them interested initially? How did they find using the product? Why did they stop? See if you can define the gap that prevented them from becoming active users.

Once similar stories of real people deriving real value begin to emerge, then we can start to leverage familiar UX tools to move beyond best practices to create a tool that supports the unique needs of those using it.

Having UX involved from the beginning will help you recognize the market when it emerges and be ready to meet its unique demands.

Share your experiences designing new or disruptive technologies. When was UX involved? While you’re at it, please rate this post using the stars beneath the title.

When Adding Waste isn’t Waste

By 2 commentsagile, , ,

Naresh Jain over at Managed Chaos was griping about The Bloat Effect. The gist is that as time moves on, everything gets bigger and more bloated, including the software, the team, and the process. This makes everything less valuable as a result.

There is often waste in our process. Sometimes it’s given to us and we have to deal with it. Occasionally we introduce it willingly. Often, we start out bloated. We may have an idea of what the streamlined, efficient process looks like, but it’s not what we adopt. Often there are good reasons, or at least reasons. We are, after all, smart, intentional people.

First of all, a definition of waste. Anything that does not directly add value to the customer is waste. Anything that causes you to spend more time than is necessary, is waste. Anything built but not used is waste. Anything that hinders progress is waste. A common goal of any process is to minimize waste, but sometimes we need it. Sometimes waste in the micro saves work in the macro. Waterfall is kinda like this. The theory is that the more you can remove uncertainty with upfront work, the smoother the project will be, ultimately saving time than if the project had tripped over some of the intricacies later in the cycle, or at least having predictable results with predictable resources. Of course, we know how well that usually works out. Agile aims to minimize all of this waste through multiple iterations and is comfortable with whatever revisions may be necessary later on, based on what we learn.

Recognize the role that waste is playing.

If you are being asked to do something you consider unnecessary, find out what need it is filling. If there isn’t one, you may have an argument for eliminating the task. If there is, you may be able to find a leaner way to solve that need. If you don’t have the authority to make the change, you may have to figure out who in the organization can and convince them. Unfortunately, waste is often thrust upon us with no recourse. Then it’s back to a software version of the serenity prayer, accepting what we can’t change and working on what we can. Sometimes that’s just just ‘how it’s done’.

However, you may choose to add steps into your own process to save time later on. If you experience a frequent roadblock that causes a lot of churn, you may need to add extra steps upfront to deal with it. For example, if you have difficulty communicating new concepts to key stakeholders, perhaps more time needs to be spent fleshing out those ideas before they are presented, especially if you believe that they are justified by the business and user needs. Do you spend time that feels unnecessary? What steps could you take earlier to minimize this unnecessary expenditure of effort? Would the trade-off be worth it?

Simplify as you go

Even if you can’t immediately change the process, you can work to simplify over time. Just because there may be legitimate reasons why you live with the excess now, don’t let that keep you from working to improve the process. This is one of the 12 principles of behind the Agile Manifesto. Can you take a small step the next sprint, or the next release, to streamline? Can you keep educating those insisting on inefficient methods in better processes? Is it waste or is it really saving you time later on? People may be hanging on to tools and processes that they are familiar and comfortable with. Moving them away from them too quickly may be difficult or undesirable in the short term. As you demonstrate success, you will have the freedom and trust to make changes and put past process attachments to rest.

Is it Agile?

As you evolve as a team, you may encounter people who tell you that, ‘You’re not Agile.’ They may be right. You may not be capital-A Agile, but I think the key questions are:

1. Are we doing better this sprint than last sprint?
2. Are we making changes that we expect will enable us to perform better in the next sprint?

Adding value

To often I’m concerned less with removing steps than with adding them. It seems common to encounter an engineering team that has been using agile without the benefit of UX and now they are experiencing some pain. There is often the misconception that waste is anything that is not working code. At the recent Deep Agile Conference, James Coplien indicated that, “Rework in implementation is waste, rework in design is agile.” Adding in a quick usability test to uncover design flaws early is not an outdated process to be slowly abandoned. It is a positive practice that should be introduced where it is lacking. Engage with your users, gather feedback on your product/designs, measure your results. These are steps that do not directly contribute to customer value, but they are some key elements that form the foundation of a solid product. Waste needs to be looked at in the context of the entire product, not just the tasks that any one individual or team are performing.

Failure: The Secret to Success

By philosophy, , , , ,

Honda has produced a series of short ‘documentaries’ promoting Honda innovation. I’m usually quite critical about this kind marketing content masquerading as entertainment, but having watched two so far, I can say they are well produced, engaging,  and only tangentially talk about Honda.

This one is about failure. I don’t think about failure much, even though some might consider that I’ve been around it quite a bit. Many companies that I’ve worked for didn’t make it, or had to cut back during hard times, but I never thought of them as failures. With each one, I often had great results with my piece of the company puzzle, met brilliant and talented people, and learned a hell of a lot. For me personally, that’s a success.

Projects come and go. I try and make sure that whatever I spend my time on is going to give me a great experience, draw on my strengths and knowledge, and give me new challenges to learn from. If it doesn’t work out, I’m very disappointed, but I take what I’ve learned to the next opportunity.

Oh, and it needs to  pay the mortgage. Can’t forget that one.

From Salon (login or adroll required) via Neelakantan at Interim Thoughts.

If you are an older subscirber, please update your RSS feed, or if you haven’t yet, subscribe to this blog’s RSS feed. Don’t know what RSS is? Check this out for an explanation of RSS.