Feature vs. Function
When it comes to the design of what people use there are many variables that must be considered. If you were to ask some one what they thought were some of the most important things to consider you would get answers like ‘the ability to do this,’ or ‘capable of such-and-such,’ or ‘I want to be able to…’Often times these are referred to as the “functionality” of the product. However, this is an erroneous label as these are actually “capability features”. One may consider the difference between the two to be purely a matter of semantics but it is much more. The difference between what is a function and what is a feature can even be considered a philosophical debate.
Let’s forego the philosophical aspect at this time and simply consider a couple of scenarios. First, let’s look at the automobile. Specifically, let’s look at an automobiles ability to stop. This feature (the ability to stop) is agreeably important, thus, all automobiles must have this feature or we would all be living in Bedrock stopping our cars like the Flintstones. Now, if we analyze how the braking feature functions this is a completely different set of considerations. Brakes are activated via a pedal. Why? Because, requiring the driving to say, open the glove compartment and depress a red button to stop the car, isn’t that usable. In fact, it’s a liability. A pedal simply makes sense because based on how a driver operates (uses) a car activating the braking mechanism via a pedal requires the least amount of effort (and thought) while providing the greatest amount of functionality (usability).
The second scenario to consider is how a house in constructed. Houses built properly utilize a team of experts. From architects, designers, general contractors, construction workers, plumbers, electricians, painters, landscapers, etc. Why? Because we have evolved into a society of experts and by using a team of experts the sum of their collective knowledge results in a final product that meets all requirements, user desires, legal requirements/regulations, etc. and ultimately exceeds all expectations.
Imagine what would happen if a plumber attempted to perform the work that the electrician should be performing or an architect drew up plans for a construction worker that didn’t meet OSHA standards. The final product would be deficient. Not only would it not meet legal requirements, it would not meet the home owner’s needs and would therefore be unusable.
Features are a product’s capabilities and must meet user requirements, resource limitations and business objectives. Functionality on the other hand, is how these features are actually implemented.
The Web has evolved to a point of maturity where not only are there industry standards (adopted by manufacturers and followed by designers and developers), but there are also specialists – experts in the various areas of web design and development. The presence of specialized roles isn’t really something that resulted from the big bang (and bust) of the web. It isn’t something new. It has been adopted from software engineering.
There is a distinct difference between a designer and a developer as it applies to human-computer interfaces. The developer is the person who codes, they are the programmers. Then there are the designers, the people who make things look pretty. There is also a third role – the information architect. This is the person who must understand end-user behavior patterns and things like usability and accessibility. This is the person who must ensure that a site’s (web application or web-based service) features are as easy to use (function) as possible.
It should not be up to the developer to decide how to implement a feature. This should be defined by the information architect and then built to spec by the developer. It is very easy to see the various sites that run the vast spectrum from designer-built to developer-built. Sites built by a designer tend to be extremely aesthetically pleasing, but lacking in overall features (or the features implemented are not based on direct end-user needs). Sites built by a developer tend to be rich in features, but difficult to use for end-users. Sites built from either end of the continuum are deficient and ultimately unusable.
In comes the information architect. The information architect will take the UI from the designer and review it to ensure that the proper visual hierarchy is obtained, that the design can be implemented (and where modifications need to be made), and that usability and accessibility concerns are addressed. This same person will then work with the developers to spec out how the features will be implemented so that they afford the most functionality.
The design and development process for web-based user interfaces has matured but it is also cyclic in nature. The goal of the initial launch of a web-based service or site is to maximize the amount of time between go-live and the next version. In order to do so all things must be properly considered and industry niche experts properly utilized. By doing so usability and accessibility concerns will be minimized and functionality maximized thereby minimizing the necessity of working on “fixes.”
When decisions need to be made proper time and due diligence should be given to what is in the end-users best interest. Trade-offs in the interest of budgets or resources should never be made at the expense of the end-user. The bottom-line is that if the product doesn’t meet the end-users needs and work in way the end-user expects, it is a failed product. The number of features a product has is ultimately a moot point if the end-user doesn’t, won’t, or can’t use them.
Additionally, if for all intent and purposes said product (that is deficient in usability) is the only one available for users the result will be in elevated costs across the board for the institution. These avoidable costs will come in the way of customer service and support (ie. helpdesk) and in the need to redevelop shortly after launch to address usability issues and product deficiencies. Unfortunately, all too often people don’t take the time to do things properly the first time. In essence it appears that they don’t have the time (resources) to do things right the first time; yet, they always seem to find both when things have to be done a second time.
There are two things that greatly increase the chance of having a successful web-based product to launch. The first is the use of user-profiles. A fictitious (and well-thought out) user profile should be created for each identified end-user segment. These user-profiles will enable the team to ask how said user would use the system rather than asking the team to attempt to conceptualize how they think a user would use it.
Second and probably more important is usability testing. This is not the same as beta testing. Usability testing involves users from the various identified end-user segments and who are not involved with the project. Usability testing should occur at various points during the product development process to ensure that things are being built properly to meet end-user needs. Studies have shown that a single usability test with as few as three users can identify 80% of usability issues.
Frankly, quite often the way that results in the most effort and time from the development and design team will be the solution that works best for the user. In some ways this is simple logic. The more time taken to properly develop and implement functionality the less effort that will be required on the part of the end-user when they actually use the system.
posted by Paul N. @ 12:28 PM
102 comments
