What UI characteristics are necessary when adding functionality to an existing product?

I happened across my copy of “The Design of Everyday Things” the other day while I was helping a client specify how to add new functionality to their existing product.

As I browsed through some of the key sections of this book again, I got to thinking — What user interface (UI) characteristics are necessary when adding functionality to an existing product?

First, let’s establish a couple of obvious assumptions:

  1. Appropriate Functionality — We’ll assume that the new functionality actually addresses a real need or requirement.  Otherwise, it wouldn’t (or shouldn’t) be added in the first place.
  2. Appropriate Performance — We’ll assume that the new functionality will perform about the same as the rest of the existing functionality.  It wouldn’t make sense to add a new function that was extremely slower than the rest of the application because nobody would use it.  And if you added new functionality that was extremely faster, the rest of the application would suffer by comparison.

Now, let’s define the necessary characteristics for the UI for our new functionality:

  • Must Fit — The new functionality must” fit” into the existing product.   In other words, users should not be able to tell where the existing functionality ends and the newly added functionality begins.  So, even if the rest of the product has got a horribly ugly color scheme that you’ve been dying to change, don’t change it only for that new button that you just added.
  • Intuitive — The new functionality must be intuitive to use.  We often assume that our users are very sophisticated and understand completely every button, menu choice, and operation.  Thus, we often don’t think twice about adding new functionality that only our most experienced users will understand (or appreciate).  However, the goal should be to drive down the level of knowledge required to use our products so that more users, including those that only use our products infrequently, can benefit from the functionality that we are providing.   Repeat after me:  “If you have more users, you usually have more revenue, which is a good thing.”
  • Multiple Paths — The new functionality must be accessible through multiple paths, or sequences of steps.   We sometimes assume that all users will only use a particular function in a specific sequence.  For example, we might assume that the user “Saves their work and then Exits”.   So if the user decides to “Exit” first, should their latest work be lost?  Of course not.  We should detect that they have not saved their work and prompt them.  This simple example illustrates the importance of allowing users to perform each new function in variety of ways and in a number of different sequences whenever it is possible.

Each of these characteristics seem pretty clear (and somewhat obvious) to me.  So, why is it that too many of the software products that we use everyday continue to violate these fundamental concepts?   Is it a question of laziness or do we simply lack the resources to do something right, so we band-aid something together quickly with the idea of fixing it later and “later” never comes?   Or perhaps our users have gotten so used to applications that are clunky and difficult to use, that we don’t feel the need to give them anything better.

What do you think?



5 Responses to What UI characteristics are necessary when adding functionality to an existing product?

  1. Peter says:

    The biggest thing that everybody forgets is to really find the target who will be using the *whatever*… If it were a device, does the average user has big thumbs or wears gloves? If it is software, are you designing based on what you think they want, or what actual users want.

    How many products have we used that ignores this? Too many.

    • David Fulton says:

      Your point is good, although when adding functionality to an existing product, this should be less of a problem. Otherwise, the entire application may need a facelift.
      Thanks for the comment.

  2. Andy Sage says:


    In my humble opinion I think you’ve covered the points in your paper. Two additional points for thought;

    – management information – when (I have been) looking at a web-offering, there is little information available on the user ‘journey’ – i.e. where did they visit from, how long did they stay there, did the follow the user experience as the designed expected, did they return to the site at a different time. This type of info can be significant in working out if the UI is meeting the customer needs;

    – you touched on the ‘user experience’ in terms of functionality intuitiveness – for me much more of the design stage needs to look at the overall user-journey, and the different audience segment needs the UI is targeting – to a degree, Microsoft have this with software updates – with the “I know what I’m doing so give me more options” button, and the “I know I need this but am clueless about it, just install it without giving me more things to think about” option.

    Hope this helps,


    • David Fulton says:

      Thank you for the very thoughtful comment. I agree with you — the user experience is much more of a “journey” than a simple collection of individual actions. The user knows what they want to accomplish and must intuitively understand how each action that they perform contributes to achieving their objective. Otherwise, the user is more likely to abandon a sequence of actions before it is completed and try something else. And if they are not able to achieve their objective using several different approaches, they are very likely to discard their current objective or even discard the entire application as “too hard to use”.

  3. Ravi Kondepudi says:

    Hi David,

    I have seen your points and they read excellent. I think the most important point is the must-fit. Not only for the look and feel but also to ensure that the user does n’t have to learn an interface that is altogether new. For example, I manage an ETL product which is made to deal with different kind of data formats / interfaces like relational databases, XML , EDI etc. While we may need additional features in the GUI to negotiate the more complex formats like XML compared to a relational format like database, spreadsheets etc; it is important to keep the uniformity in the product. Otherwise the amount of learning required with the deviations and the effort to shift between these differing interfaces will be an overhead. It is not only one product, sometimes we have a suite of products. In our case, we have a Data Quality tool to support the ETL functionality. We feel that it is an advantage that both have similar GUI so that a user used to one product in the suite need not take any time to get used to the GUI of another product in the suite.

    So to summarize, it is not only from the cosmetic point of view, but more from a user productivity point of view , it is important to keep the UI in line with the existing design.

    I look forward to other thoughts in the forum.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: