Foregoing assumed value in favor of rapid feedback

The goal of developing any software should be to provide functionality useful to the majority of its users.

While doing business analysis or writing user stories for a feature of a project (especially those that are an attempted re-design of an existing one), it is important (and exciting) to brainstorm, be visionary, and think up great ideas for how you can please your customer base. However when planning those features for release, it is tempting to attempt to complete all of those stories before making the feature available to users.

The reasoning behind this argument usually sounds something like “our customers have used the product for years with these features, and they will not use it if they are not all present”. Another spin on this is “our competitor has these features and we will not be competitive without them”. There are several flaws in this argument.

1. The argument assumes that users are currently using all the features. Unless you are measuring the use of the feature in the field (google analytics etc.) and have data to back up this claim, it is highly unlikely that a compelling offering could not be made available to users with a smaller subset of features.

   This applies to competitive analysis as well. Comparing your planned features to an existing product sheet will simply align you with them, which can be a disaster if many of their features are unused by their customers and you will now be spending money building them too. It also reduces your ability to differentiate yourself from them.

2. The argument assumes that users will not provide accurate feedback on their needs of the software. When you choose to implement the kitchen sink around a feature, what you’re really saying is, “I know more about the user’s needs than they do, so I will decide everything to offer them”.

   When you go this route you spend excessive time getting to market, excessive capital implementing features that may not even be used, and place release cycle pressure on yourself by having a larger workload – making it less likely that you will be in the relaxed mindset necessary to listen to your customers and be able to respond to requests for changes.

   It’s more efficient and realistic to simply release the smallest subset of those features necessary to make initial use of them available, measure usage and gather feedback, and give users exactly what they want once they’ve used the feature. While it’s true that this approach can result in designs that are different from what you originally envisioned, your vision is not as important as the successful adoption of a feature by its users.

3. The argument weights delivering assumed value over used value. What this means is that by focusing development on robust implementation of features that have not been even initially deployed to users, the backlog and priorities are being driven on assumed need. Even if your customers tell you they need a feature, unless you are measuring that they are using it in the field, and they are providing you with feedback that they like it, you are taking a risk with the effort needed to implement it. It makes sense to reduce that risk so that if you deploy a feature that turns out to not be useful, the lost capital is minimal.

Where I’m going with this is that organizations should spend serious time reviewing their backlogs of features, working with user experience experts to come up with designs that deliver the smallest, simplest design that accomplishes what you think the user needs and then get it out there. It is always more viable to bolt on a feature that you verify is needed after an initial offering than to spend money on assumptions only to find that it was a waste.

The 4 priorities of software developers

Over the years that I’ve worked on teams developing software, I regularly hear of the “three legged stool”, a metaphor for balancing three opposing aspects of the development process. The metaphor works well because if any leg of a stool is shorter than the other, the stool can stay upright but any pressure can cause it to fall over. Not practicing one of them at all can make it not even able to stand. These three legs are quality, features, and schedule. The motivation between choosing these 3 aspects is to help business stakeholders, managers and developers make smart decisions about the compromises we inevitably make on projects. In practice however, I find that business owners will always choose features, managers will always choose schedule, and developers will always choose quality.

The reason behind this is simply a human desire for self-preservation. Business stakeholders’ performance is measured by what features they deliver, managers are measured by their ability to deliver on time, and developers are often measured by their ability to write solid code and deliver it with minimal defects. Since most organizations are structured where developers report to managers, who in turn report to the business; this places an uneven emphasis on adding new features at the expense of consistent time to market with new features of high quality.

As a developer or architect, the list of features and desired release date is often out of our hands, even with a backlog and a fairly well followed set of agile processes. Rather than continue this trend, I’m of the belief that even though business stakeholders are supposed to be the best people at knowing the business, they are often not well versed enough in technology to understand the implications of ignoring requests for refactoring, and making smart decisions with respect to technology selection. Developers are still the core of the value chain in this aspect of the development process. Rather than argue this point, I’d like to propose a list of 4 priorities that developers can regularly consider when making technology and design decisions. If you follow this set of priorities, you’ll find yourself regularly making the best decisions for all parties.

1. Can I implement the feature?
2. Does the design allow extension of features along planned integration points?
3. Is the design flexible enough to allow unplanned changes to be made?
4. Is the design, and are the technologies, the most modern available?

Can I implement the feature?

If you don’t make the software do what the business wants it to, you’ve failed as a developer. It doesn’t matter if you’ve used to most forward thinking technologies and patterns, and written unit tests to give you 110% code coverage (chuckle). If you don’t deliver to market what your business expects, users won’t have compelling reasons to use the software, your business stakeholders won’t have much to sell, and you probably won’t be seen as having much value in the company at one point or another. This assumes that the business is choosing the right features, and designing them to be usable, for success in the marketplace. If you don’t trust the business to make the right decisions here, I’d suggest you join another company you can be passionate about where you believe in the vision and leadership there. Above all else, evaluate design decisions and technology selections by their ability to enable you to meet the requirements and make the feature work. Usability and quality are included in this priority. I’m of the opinion that one should never deliver features that are unusable or of bad quality to the market. If a feature is hard to use, users won’t use it, or worse yet use it as an example of bad design to laugh at with their peers. If a feature doesn’t work, they will say bad things to their friends about your company and kill your brand. Enough said.

Does the design allow extension of features along planned integration points?

When you build a software product, unless you want to see a competitor blow you out of the water very soon after you ship your first version of a feature, you’ve got to have a backlog of new features to add in future releases. I’m of the opinion that this list of future features should be readily available to developers to provide transparency into the direction of the business. While it’s true that an inexperienced developer may look at a backlog and be tempted to make design decisions that extend the schedule and don’t add value needed in that feature or release, a quick read of YAGNI and a revisiting of that principle during design decisions should be all it takes to avoid this. The downside to not letting developers see the backlog of future features is much more nefarious; they can make design decisions that make it difficult, if not impossible to support features planned in the short to medium term future. There is a delicate balance here, but the heading says it well. Make decisions in your design that allow extension of features along integration points you really have planned. Stakeholders should have a way to identify features on the backlog that are uncertain (nice to have) or a duration of time past the current release after which they should not be considered in design decisions. If you’re not sure, don’t do it.

Is the design flexible enough to allow unplanned changes to be made?

I often encounter developers new to OO, data driven design, and contract-first development that go crazy with decoupling and make their designs overly complicated to implement with little value. They add interfaces to classes with trivial logic to enable unit testing (thus adding un-necessary assets to maintain, test, and revisit during refactoring), use solution-specific patterns to implement logic that really belongs in one method, and create complicated multi-step ETL processes to cover up for bad database design. As a developer, you should try to select patterns and technologies that follow best practices in the industry for enabling refactoring, testing, and feature integration; but only to a level that is sufficient to support the first two priorities. This priority is closely related to the one above with a crucial difference – the 2nd priority has a business stakeholder driving the decision for flexibility while this one is driven by a developer desire to use patterns that make the code easy to maintain or rapid to extend but that will be difficult to explain to business stakeholders and management. Usually it’s easy to convince management or stakeholders that you have to design an interface to support integration with data providers they have planned integration with in their backlog. It’s not as easy to convince them that a set of your classes need interfaces for passing into a processing pipeline of some sort when the processing could be done in one method, and there are no plans to modify the pipeline’s order. Read the Tradable Quality Hypothesis from Martin Fowler to help you convince management of the importance for supporting activities that fall into this priority when you feel the need for them.

Is the design, and are the technologies, the most modern available?

Last on your set of priorities should be using new technologies. ASP.NET MVC3, JQuery Templates, OData, Ruby, and F# may offer significant advantages over past technologies or patterns; but if using these doesn’t result in more success with the first 3 priorities, it’s hard to make a logical case for it. There are times where using a technology is necessary for marketing purposes, and in this case use of that technology becomes a feature itself (thus bumping it to priority 1) but otherwise there are many times when using an older version of a database, framework, or language is more than sufficient to enable the business to consistently deliver quality value to customers. Unless your organization has a handle on the first 3 priorities, you’ve got work to do before tackling this one.

The state of Inductive User Interface (IUI): here to stay

Back in 2004 I left Rockwell Software (a subsidiary of Rockwell Automation) to join a small company that needed technical and design leadership for a potential touchscreen application for the pharmaceutical industry. As part of my design, I had to do research on usability of touchscreen interfaces. This led me to study panel designs in Japan and the manufacturing industry and eventually Inductive User Interface (IUI). IUI is a user interface design approach that emerged with Microsoft Money 2000 and has infiltrated many of the software applications we use today, most notably Windows itself.

IUI emerged as a realization that there are two different classes of use of software. The first is through deduction which is common to power users such as myself that are typically programmers, IT personnel, or other more technically sophisticated roles in an organization. When a new application is installed on our computer, we typically flip through the menus at the top of the window, or hover over the tooltips of the toolbar buttons to find out what was available. Sure there is online help, but we can usually deduce what to do simply by exploring these common controls. Deductive user interfaces are better for people who use the same application over and over again. Once a graphic artist has used Photoshop or Illustrator for a while, they want many actions available in the same place and in the same screen. An IT administrator also needs a single page they can use to administer a user account and modify anything about them.

Microsoft realized that the other way most use software is infrequently. The most common example of this is the control panel in Windows. Many home users of Windows rarely use the control panel and so when they go in to configure settings, they don’t remember anything at all about the screens. IUI makes the user interface’s purpose on each screen explicit – there is no exploration or guesswork involved. It also forces UI designers to break the software up into more steps or screens, and as a result will slow the process down some for power users. However Microsoft (correctly) determined that the 80/20 rule applies here – 20% of users of their OS are power users.

This screenshot from Microsoft’s IUI guidelines whitepaper (published 2001 but still very relevant as I’ll get to) illustrates the paradigm shift well:

Microsoft Money 99 “Account Manager” screen

The first thing a user thinks when reaching the page is “what can I do here?” The title says “Account Manager” but the primary purpose of the screen isn’t clear. There are buttons on the bottom of the screen that allow the user to do something, but they are disabled until an item from the list is selected. Additionally, there’s no easy way to get back to the previous page or a “home” screen of sorts.

Here’s Money 2000’s version of the same screen:

Microsoft Money 2000 “Pick an account to use” screen

Here the purpose of the screen is clear – “Pick an account to use”. Once the user selects an account from the hyperlinks on the right (which still show the rollup dollar information) they are then presented with a new page with links that allow them to do things with that account. Links are available allowing them to navigate back to the previous page. Additionally, IUI allows for a “task panel” of actions on the left or right side of the screen that are related to account management but not a single account itself.

Read the full whitepaper for more information about the background of IUI. Interestingly, Microsoft’s Windows Vista, and more recently Windows 7 User Experience Interaction Guidelines don’t mention IUI explicitly but the common controls of the operating system are designed for these exact types of user interfaces. Specifically, check out Silverlight and WPF’s navigation framework that allows you to create separate pages easily with built-in browser-like “back” and “forward” buttons. A look at any Windows control panel applet, many screens and dialogs in Visual Studio 2010, as well as the task panels in Office show that IUI is a powerful tool throughout Microsoft’s suite. Other vendors like Intuit, Apple, and Google regularly use IUI in store checkouts, configuration screens, and other infrequently used parts of their applications.

I’d encourage you to learn the IUI design principles and adopt them to the way you design software for your clients to give them more usable interfaces. Here are a few of the ones I use the most (and some I’ve come up with on my own).

• Select a title that asks the user to do something.
  
  • Don’t use the words “and” or “or”. If this happens – you need to design two screens!
    
  • For screens that allow the user to review something, make the title “Review the details of this <object>”.
    
• Include an instructions line below the title that gives additional information about what’s presented. For example in the Money 2000 screen above this line might state “Account totals are listed to the right of each account. To perform more actions on the account, click on its name.”.
  
• Avoid horizontal scrolling (and vertical if on a mobile device or tablet/touchscreen!).
  
  • If you have a grid, show only the most important columns of info about an object being viewed.
    
  • Allow the user to select the items in the grid to get more information about them.
    
  • Alternatively, don’t use a grid and use custom XAML or HTML markup that creates rows of detail/header information.
    
• Place “global” actions (like “Home” or “Logout”) in a dedicated panel at the top or bottom of the screen where they are always available.
  
• Make mockups in Balsamiq, Sketchflow, or another low-fi mockup application of the main screens
  
  • Once you have the mockups go through the flow of the application and look for opportunities to connect related screens through related actions on the task panel.
    
  • Identify user roles that need access to each page and/or link and design your permission system around this.
    
• Designs screens after domain objects in the business’ natural language e.g. Orders, User Accounts, Patients, Subscriptions etc. Then design the related screens for each domain object.
  
• When you have more than 5 actions that can be taken on an object selected in a previous screen, break the actions up into categories and make the user select a category first. These are “category navigation pages” and I’ve found numerous cases where they make an application highly usable.

IUI is not a perfect fit for every application, but many product managers and power users at companies who are designing new versions of their applications, or new products altogether, do not have a background in modern UI design and are unaware of this approach. They can also be tainted by previous experience and knowledge, leading them to believe their user base doesn’t need things to be broken up into “so many screens”. Use the research Microsoft has provided and examples of modern applications as leverage to open up the discussion and enable them to take part in designing the software in a more usable fashion. Whenever I’ve had the opportunity to use this approach, the results are often eye opening to everyone involved and can have a dramatic effect on users understanding the big picture of their flow of work.