Knob Twiddling and Product Design

This post was written by Brian Despain on March 18, 2010
Posted Under: Product Development

As the product manager here at Deep Web Technologies, I oversee product feature development. I spend my time working with software developers, our application engineers, marketing folks, our customers and our partners to help design our next-generation SAAS (Software as a Service) product as well as refine our current products. As we go through our design process, I have been spending time thinking about challenges in administrative user interface (UI) design. It’s an interesting design challenge – How to expose the underlying administrative functionality that the software developers have spent time on without overwhelming the user with options? Building an application that can be configured in myriad ways means that you need to provide users with easy to use tools to configure the application the way they want.

Software engineers very often want to give users the maximum degree of control over the software they have built. I like to call them “knobs and twiddles”. This is an admirable impulse and it’s often shared by the sales team (and let’s face it – it’s one of the rare times those two teams agree!). That can lead, though, to feature over-build. Each UI administrative setting represents a feature that a user might touch and use. Statistically, 45% of features on software applications are never used and only 20% are always used. But overloading the application with configuration settings and giving users plenty of knobs to twiddle carries with it the danger that users will be overwhelmed with choices and will lack the information to properly configure the application to it’s optimal settings. Or perhaps users will spend time twiddling the knobs without understanding the nuances of interaction, then get frustrated when knob A doesn’t have the expected effect on feature Y.

Federated search applications can be quite complex (collections, proxy servers, ILS’s etc.) and require orchestrating all of this together with a number of outside providers. This leads to a great number of parameters that can be tweaked to change performance, emphasize results form different vendors, change the layout, change the number results, etc. Clearly there is a benefit in offering users the ability to configure the application to their hearts content with the recognition that most users aren’t going to take full advantage of the configuration features. Software UI complexity is a common problem with any number of applications.  The approach we have taken to address the issue is with preset defaults based on their market and thus their business needs. For example, a search application for a library in an academic setting is different than a corporate research library. We have different templates for different markets and then let users know we have tested and configured their template based on their markets needs. Thus when a partner or customer administrator sets up their federated search, they select the profile that best matches their industry and needs. If they then chose to configure the application further, they will be starting from a point where the application is already configured to what is common in the industry.

Good UI design stems from understanding the ultimate question about your application – What are users trying to achieve by using the application? What business need are they trying to serve? Many software developers fail to understand the business needs for their application. By configuring the most common settings based on the customer’s needs you can speed adaption of your product and please your users by giving them an easy-to-administer application. Give the power users the tools they need but focus on the needs of the average users.

More Reading

Add a Comment

required, use real name
required, will not be published
optional, your blog address

Next Post:
Previose Post: