Archive

Archive for June, 2010

Crafting Great Software Features Part-1

June 1, 2010 1 comment

Yaacov Apelbaum-Useless Technology  
Latest Features: Driver’s Entertainment System and Password Protected Gear Shifter

Trying to do anything well is difficult. Developing useful features is no different. It takes more effort to create useful functionality than to produce eye candy.

Good feature design comes from a reliable and repeatable process (not dissimilar from CMM). Unfortunately, many organizations still have not figured this out and instead of investing in usability engineering, they slug it out in isolation and tragically, like Sisyphus , doom themselves to getting the wrong functionality and spend eternity (or until the project is canceled or runs out of money) patching their mistakes, version after version.

If your goal is to build a useful product, you should schedule your project so you can develop the needed functionality. Habitually excusing yourself by claiming that you "just don’t have the time" to develop quality is a cop-out. If you find that your team is spending a significant amount of time on feature seesaws (taking them out-putting them back), it means that you’re not planning well, and that the technical goals are not aligned with the product objectives.

Feature Framework

In a functional development organization, everyone should fully understands how their individual contributions will impact the end user. To help achieve this, there should be a feature framework in place.  The feature framework  must cross organizational lines and bridge development, PM, product planning, sales, and marketing.  The chief purpose of the framework is to determine what challenges end-users have and how a proposed feature, functionality, or technology will solve those problems. Without utilizing some degree of Feature Driven Development, you stand the risk of creating features that may look great (like password protected gear shifter) but solve no real problems.

Management Knows Best, Well, not Always…

In order for you to master the product usability question, you have to conduct real life tests with real would-be users. Talk to your customers about their pain points and ask them what they love (and hate) about your product.  The earlier you get the bad news, the better you’ll be in the long run.

Keep in mind that most failures in software usability can be attributed to poor decisions at the executive level, which are promulgated due to a culture of silence. Developers and designers should be encouraged to think critically about their work and be provided with official channels for expressing their opinions (in a non polemic manner).

Make sure they talk to the the other members of your team to broaden their horizons.  Invite their participation in every feature conversation. When considering new or revolutionary UI changes, solicit input from your customers and your organization.  Without sufficient end-user, business justification, and sales input, its easy to develop functionality that universally disliked (like the notorious Microsoft Clippy feature).

One of the most common development failures (after underestimating feature complexity and the cost and time to develop it) is the inability to correctly define the problem space and instead to develop solutions that are looking for a problem.  If the project objective is vague and not granular enough, it’s impossible to know whether it has been solved or not. Furthermore, even if the objective is well defined, you may still be working with the wrong assumptions about what the customer really needs.

A video screen built into a steering wheel that plays looped safety movies won’t help your user drive any safer. These two types of problems—vague objectives and the wrong assumptions—have nothing to do with your team’s technical ability. If you can’t side step these kinds of issues, even the best software engineers and designers are bound to fail. You may write great functionality and create whooping UI, but if you can’t solve the right user problem, all of your hard work will be wasted.

Do you have a Problem with That?
The first step towards critical feature analysis is to take an objective view on the nature of the problem. As a developer, you are inherently biased towards the value of your features and suffer from a certain degree myopathy. You’re inside the tech bubble looking out and so you cannot possibly see your creations the way your users do.

Yaacov Apelbaum-Team Structure To improve visibility, you need to supplement your view with external sources. These should include: UI team, technical developers, product business champion, actual customers, sales, training, and marketing.  Get as many alternative views as you can. Again, make sure to talk directly with the users effected by the design, Don’t take single  camp’s word for what the problems are. Think of yourself as a newly elected congressman trying to keep your constituents happy. Don’t only consider the opinions of the power lobbyists.

Another challenge is that the way approach your customers for feedback will impact the type of information you get from them. If you unintentionally bias your questions, you’ll get skewed data. The art of observing and understanding customers needs is an acquired skill and it may take several trial runs before it’s honed.

When researching the problem, keep the following key questions in mind:

  1.  Who are your user’s, what are their skills and job functions?
  2.  What is your user’s workflow and how does your product enhance it?
  3.  Do your users use other products to supplement your app?
  4.  What business assumptions are you making about your users and their environment?
  5.  What are your user’s specific deliverables (spreadsheets, reports, presentations, etc.)?
  6.  How do your competitors solve the same problems you are working on?
  7.  What is your user’s strategic information roadmap and how does your app fit into it?

If you don’t have complete responses to these questions, you cannot start to design or develop any features or functionality. a solid understanding of your customers and the answers to these questions form the foundation of your application.


You Only Get One Chance, So Chose Wisely
As you are preparing to work on your next version, you will discover that there is an infinite number of issues that need solutions and a mile long list of most have features. But just having a raw list of bugs and features isn’t enough to build a product.  As it goes in life, some problems are not worth solving once you consider their poor return on investment and time.

Often, a solution to one problem spawns multiple new problems (and bugs). You need to exercise good judgment, which means having the ability to distinguish what should be done from what can be done. After collecting the business requirements, the next step is the development roadmap. You have to synthesize the requirements and create a specific action plan for where to invest your time and resources.

With the data collected from customers and internal sources, distill the information into short one-sentence lists. These sentences should be written from the point of view of your end-user. For example, "Enable password field to accept 11 characters" is not a problem statement. But "Password field must support strong passwords" is. The difference is significant. You rarely want to define the solution and the problem in the same statement: If you do, you’ll miss the real problem.

In this example, there may be many other ways to solve the problem of password strength, including hard coding the logic to accept 11 characters. But if you are too focused, you’ll never see the alternatives (make the password length database driven, integrate it with LDAP, biometrics, etc.). Good feature development is all about understanding your alternatives.

Yaacov Apelbaum-problem to a solution For each problem statement, provide supporting information. Include details about which users have the problem, how it was discovered, and what the potential workarounds are. Determine whether the problem only occurs in certain configurations. Following Feynman’s rule of scientific integrity, provide as much details as you can to allow others to confirm or challenge your assumptions.

If you’re the owner of the usability study or market research data make it available to everyone.  Don’t ask anyone to “trust you”. The more open you are about your feature sources, the less likely it is that people will suspect you.

A solution looking for a problem

Hold your Fire
Only start coding when you see “the whites of their eyes”.  When the goals are set and the problems to be solved have been well defined and understood, you can begin to build the features. Instead of adopting a top to bottom approach (where the development team is told what to do), engineers and UI designers should have free rein to generate the ideas that will solve the problems. Time should be allocated to investigate different alternatives that might provide the necessary functionality, and to run usability studies on prototypes to see if they actually improve the end-user experience. Only once you evaluate all your potential solutions and pick the best one can you engage in full speed development. The rest of your solutions do not have to be disregarded; you can shelve them for future releases.

As long as you are working within a feature framework, you are guaranteed to be marching in the right product direction. There should be a lot of innovative and creative juices flowing in your team, and even if you can’t completely solve all of your feature functionality challenges, a partial solution to the most important problem will still be superior to a perfect solution to the wrong problem.

 

© Copyright 2010 Yaacov Apelbaum All Rights Reserved.