Myles Design Studios: What, Why, & When of Design

Most people instinctively sense when a product is well designed. A properly thought out and tested product, be it a car, office building, cell phone, or software application just feels right. It's intuitive to use and fulfills its task perfectly. Conversely, a poorly designed product is cumbersome, awkward, and frustrating to use. In truth, most poorly designed products are not really designed at all, but simply built with design decisions made along the way based solely on cost and expedience.

The design discipline exists in a similar form across a variety of industries. In building construction the architect fulfills the role of designer. Nearly every manufacture of items from toasters to automobiles employs some degree of mechanical design and ergonomics. For many products, design is the primary point of market differentiation.

One of the best and most commonly used analogies used to describe the role of design in software is that of the building architect. This comparison was used compellingly by Mitchell Kapor in his 1990 Software Design Manifesto © 1990, All Rights Reserved. Here is an excerpt from Kapor's Case for Design section of that manifesto,

Architects, not construction engineers, are the professionals who have overall responsibility for creating buildings. Architecture and engineering are, as disciplines, peers to each other, but in the actual process of designing and implementing the building, the engineers take direction from the architects. The engineers play a vital and crucial role in the process, but they take their essential direction from the design of the building as established by the architect.

When you go to design a house you talk to an architect first, not an engineer. Why is this? Because the criteria for what makes a good building fall substantially outside the domain of what engineering deals with. You want the bedrooms where it will be quiet so people can sleep, and you want the dining room to be near the kitchen. The fact that the kitchen and dining room should be proximate to each other emerges from knowing first, that the purpose of the kitchen is to prepare food and the dining room to consume it, and second, that rooms with related purposes ought to be closely related in space. This is not a fact, nor a technical item of knowledge, but a piece of design wisdom.

Similarly, in computer programs, the selection of the various components and elements of the application must be driven by an appreciation of the overall conditions of use and user needs through a process of intelligent and conscious design. How is this to be done? By software designers.

Design disciplines are concerned with making artifacts for human use. Architects work in the medium of buildings, graphic designers work in paper and other print media, industrial designers on mass-produced manufactured goods, and software designers on software. The software designer should be the person with overall responsibility for the conception and realization of the program.

So design is an equivalent discipline to engineering, but design should occur ahead of and to some extent drive engineering in the software development lifecycle. In practice there is a continuous conversation that goes on between design and engineering, as well as between design and product management, marketing, sales, and the customer base; but the core consideration of the software designer is the end user's experience of a product. This is not the prime focus of any other group in a development team. As a result positive user experience and usability often falls through the cracks if design is not an integral part of the development process.

The goal of the designer is to provide a positive user experience and increase product usability. So, what’s the importance of usability? It depends to some extent on the maturity of a given technology. In the very early stages, raw technology is sometimes all that matters. Products can gain acceptance in a small early adopter sector by simply succeeding at implementing novel functionality. There is little concern with how easy the technology is to use. The fact that it works at all is enough at first. But, as new technology becomes more commonplace (something that is happening with increasing speed in our information driven society), marketing becomes the leading force in a product’s dominance. With the technology proven, companies must convince mainstream consumers that they can't live without their product. In maturity, usability, along with marketing determine market acceptance. At this stage the technology has been accepted and is taken for granted. Now the struggle is to present that technology in compelling and understandable terms to a more general audience.

This evolution is clearly visible in any mature market. Automobile models for example fail or thrive based on design and marketing choices resulting from exhaustive customer focus. A manufacture must know the exact demographic each model is aimed at if they expect to compete. The public has long since lost any sense of wonder that cars simply function. They are expected to not just work, but to be reliable and safe in all sorts of conditions for many years.

On the other hand, not so many years ago people were amazed that they could hook their personal computer up to a phone line and ‘surf’ a whole new virtual world. Most of these early pioneers of the web frontier did little more than surf, but that was enough in the beginning. Personal computers and the web are well past infancy, and the public expects them to deliver some real value now, and do so in a way that is easy to understand, even for the non computer geeks.

Tolerance for the ‘cool, but unreliable and difficult’ quickly fades once a product reaches acceptance. To win customers in a competitive market it’s essential to design reliable, usable solutions that leverage great technology. I say ‘design’ rather than ‘build’ because usable products don't just happen by accident. It’s quite simple to build a solution that meets requirements, but is not usable since the act of construction is not primarily concerned with user interactions, use cases, and usability, nor should it be. Because the measurement of success in design is usability, the designer is motivated towards solutions that may not be apparent to the engineer. I'll illustrate this fact by returning to the architecture analogy.

There are many examples of structures that are well put together, fully meeting code and requirements, that aren't the least bit inspiring, compelling, or even livable. Such structures are the result of construction driven design (i.e. not really designed or architected at all), where the cheap and expedient building choice is the rule. These buildings may be perfectly sound, but not at all desirable.

It is important to remember that as far as a user is concerned an application’s UI is the product, since it is the only component they directly experience and interact with. Additionally, if a target user can't figure out how to use a feature all the resources that went into implementing it were waisted. Worse still, a misleading interface may not only obscure content, but cause general confusion, frustration, and dissatisfaction that results in an overall lack of confidence in a product.

Some of the direct benefits of integrating design into the software development process include,

The short answer is Early, before any code is written, in the requirements analysis phase of a project. The earlier in the development process design is introduced, the greater its impact will be on the outcome. Though design has a valid role throughout the development lifecycle, bringing design in at the end of a project after the majority of the work is done can usually do little but slap some window dressing on a product, an exercise commonly known in the industry as, "putting lipstick on the pig." If a product has any major underlying flaws in its design they probably will not be able to be addressed at that late stage.

If you want the best return on your design investment dollar it is wise to include design right at the beginning. User profiles, requirements analysis, use case development, simple prototypes, and even paper or HTML based usability studies can all be done before any engineering resources are invested in a project. Such design processes help to scope and refine a project. This allows for better allocation of development resources. Additionally, these design steps require a fraction of the time and cost associated with equivalent work in code, or worse still, in cost required to go back and fix mistakes due to poor design decisions.

A somewhat different concern is when to usability test. Usability testing is valuable at most any stage in a product lifecycle. The returns testing offers varies somewhat depending on what is tested and when. I the case of an existing released product or deployed web site, there is value in testing to find weak points that should be considered for redesign in the next version. The results of such tests would flow into the requirements analysis and scoping phase of the next development cycle.

Earlier testing is an important indicator to gauge if a current project is on track with its usability requirements. On new projects it is generally a good idea to run some sort of usability tests on a proposed design before any implementation begins. This will help to flesh out any major problems or misunderstandings in the design. Tests can be run on very simple paper prototypes, as well as more high fidelity interactive mockups using HTML. Complex projects may warrant several test cycles at different states of fidelity, but even the simplest project would benefit greatly by at least one pre-implemtnatation usability test of its design. Depending on the complexity of a project, it may be wise to run additional usability tests on pre-release (alpha or beta) versions to further explore potential problem areas.

As a general rule, usability testing of a design before beginning development, and of an existing product before designing the next version are always a good investment. The value of additional testing is dependent on the complexity of the project. As a rule, more complexity calls for more testing.