Design is a profession that found me. During my interactions with customers while working in support, training, and QA roles, I realized the root cause of many user problems was bad design. People implementing products lacked a clear vision of what to build, and who to build it for. Software engineers felt they had done their job by created products that functioned within narrow parameters. But customers found products confusing; falling far short of expectations. I saw a chasm between customer needs, and developer goals, that could not be crossed without outside help. Both sides required an intermediary to straddle the two worlds of user needs and technical demands; someone comfortable in and understanding of both camps. Design was the solution.

I soon became aware of existing work in interaction and UX design by such pioneers as Alan Cooper, Jef Raskin, Donald Norman, Jakob Nielsen, Edward Tufte, and others. I immersed myself in understanding existing design practices and incorporated them into my day to day work.

Over the years I've been able to use my unique background and understanding of technology, cognitive psychology, and aesthetic sense to develop effective solutions for a wide variety of design problems. For me design is forever interesting, and a never-ending challenge. It's valuable and rewarding work I love doing.

User Experience (UX) Design is about humanizing technology. Most importantly, it defines the purpose and intent of a product or service. This is discovered and validated through user research. Purpose and intent drive subsequent design decisions around navigation, layout, and interaction; which in turn guide implementation.

While design includes appearance and aesthetics, those are not the core value of design. The look of a product should be in service of its purpose, appeal to its intended audience, and reinforce a consistent brand experience; rather than react to whims or trends in the digital pop-culture.

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 fulfills its task perfectly.

Most great design is transparent. It seems obvious... people will say, "Of course it's like that, how else would it be?" Great design is not self-serving - it serves user goals and experience.

Conversely, a poorly designed product is cumbersome, awkward, and frustrating to use. In truth, most poorly designed products aren't really designed at all, but simply built with design decisions made along the way based on cost and expedience. The most prevalent design methodology is entropy.

The design discipline exists in a similar form across a variety of industries. In building construction, the architect fulfills the role of designer. Every manufacturer of items from toasters to automobiles employs mechanical design. For many products, design is the primary market differentiator.

One of the best analogies to describe the role of design in software is 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 life cycle. 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.

Great User Experience is a powerful market differentiator, that results in more sellable products, enhanced customer loyalty, and reduced training costs. User centered design is the path to repeatedly achieving, and improving UX.

Exceptional products arise from a culture of design. Like quality, design is not a step in a process; it's a way of thinking that permeates all parts of an organization.

The goal of the designer is to provide a positive user experience. But what’s the importance of user experience? 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, marketing becomes the leading force in a product’s dominance. With a technology proven, companies must convince mainstream consumers that they can't live without their product. In maturity, user experience along with marketing determines product success. 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 general audience.

This evolution is clearly visible in any mature market. Automobile models 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 only work, but to be reliable and safe in all sorts of conditions for many years, and most of all, fulfill some image I have of myself - sporty, successful, powerful, environmentally conscious...

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. Now personal computers, the internet, and mobile devices are ubiquitous. The public expects them to deliver some real value and do so in a way that is easy to understand, even for 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 good products don't just happen by accident. It’s easy to build a solution that meets requirements, but in practice is not at all useful, since the act of construction is not primarily concerned with user experience - nor should it be. Since the measurement of success in design is positive user experience, 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 requirements, and 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's important to remember that as far as a user is concerned, an application’s user interface (UI) is the product, since it is the only component they directly interact with. Additionally, if a typical user can't figure out how to use a feature, all the resources that went into implementing it were wasted. Worse still, a misleading interface may not only obscure content, but cause general confusion, frustration, and dissatisfaction; resulting in an overall lack of confidence in a brand.

In the end the best reason to do design is it allows for the creation of more desirable products quicker, and with lower costs than the "build first - fix later" method. That's good for customers & good for business.

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 life cycle, 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, a.k.a. "putting lipstick on the pig." If a product has any major underlying flaws, they probably cannot be addressed at that late stage.

If you want the best return on your design investment dollar, it's 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 evaluate or usability test designs. Usability testing is valuable at most any stage in a product life cycle. The returns testing offers varies somewhat depending on what is tested and when. In 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 formative testing is an important tool for refining designs. It helps to identify major problems or misunderstandings in a design. Tests can be run on very simple paper prototypes, as well as more high-fidelity interactive mockups using HTML or other relatively inexpensive technologies. Complex projects may warrant several test cycles at different states of fidelity, but even the simplest projects benefit greatly from early design testing.

There are no shortage of books, websites, and conference talks dedicated to the subject of design and how it should integrate into the software development process. I don't plan to contribute to that by writing another tome on the subject here, but I will briefly discuss my approach to design.

Approach to design tends to fall in a range between user driven on one end, and visionary driven on the other. The first focuses heavily on requirements gathering, mapping requirements to features, and then designing those features. The strength of this approach is that users have input, but designs tend to be very incremental, and innovation unlikely.

The visionary approach relies on a small group of opinionated (some might say arrogant) design gurus. These visionaries may create innovative designs, but without a vision grounded in user and market knowledge, opportunities for major failure are very high. The visionary approach can tend to create solutions looking for a problem.

The optimal path lies between these two extremes, what I call Informed Design. This approach borrows aspects from the user focused side, and the visionary camp to come up with design solutions grounded in solid market understanding, as well as good design leadership. It's an approach that is guided by market realities, but still encourages innovation. There is an essential component of human insight and instinct required to develop elegant and effective solutions. Process, analysis, and testing play very important roles, but cannot lead to good designs on their own. In other words, good designs come from good designers, and that requires experience, more than anything else.

I'm a strong proponent for using Agile and Lean UX processes for implementing this approach. Lean UX is a collaborative software development practice that evolved from Agile and Lean Startup principles. It's about cross functional teams (e.g. scrum teams) collectively learning by doing. This is encapsulated by the cycle of Think > Make > Check. Teams should be constantly, and quickly creating minimum viable product (MVP) to test ideas. Every MVP should be a testable hypothesis.

Finally, I'm of the opinion that software designers should have a working knowledge of development tools and processes. Just as an architect should have some grounding in structural engineering, and an automotive designer should understand something about vehicle drivetrains and the demands of traffic flow, software designers should know what goes into building their designs. This means understanding the development life cycle and having a functional knowledge of the technologies used to implement designs. A designer doesn't need to have advanced programming skills, but it's important that we be able to speak in a language programmers understand, empathize with them, and truly collaborate on finding solutions.