mmyles2007+mds@gmail.com

Becoming a Designer

I've been interested in computers for as long as I can remember. I initially focused on hardware - pursuing a degree in electrical engineering - but fairly quickly shifted to software. I came to design through my involvement in technical support, training, and quality assurance of software applications.

In my interactions with customers and vendors on the front lines of support and training I found most problems users experienced were a direct result of bad design. The people implementing the products usually didn't have a clear vision of what to build, or who they were building for. Software engineers created products that functioned within parameters outlined by often rudimentary requirements list, so they felt they had done their job. But customers found the products confusing, falling far short of expectations. What I saw was a chasm between the needs of the customer, and the goals of the developer, that could not be crossed without outside help. Both sides needed 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. It's a profession that essentially found me.

I soon became aware of existing work in interaction and UX design by such pioneers as Alan Cooper, Jef Raskin, Donald Norman, Deborah Mayhew, Jakob Nielsen, Edward Tufte, Larry Constantine 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 a forever interesting, and a never ending challenge. It's valuable and rewarding work I love doing.

What is Design? ...IMHO

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 and ergonomics. For many products, design is the primary point of market differentiation.

One of the best and most common 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.

Why Design?

The goal of the designer is to provide a positive user experience. So, 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 the 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 and the web are well past infancy, and 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. Because 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, 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 product.

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.

When to Design?

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, a.k.a. "putting lipstick on the pig." If a product has any major underlying flaws in its design, it 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 lifecycle. 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 flesh out any 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.

Design Approach

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.

To start, when I call myself a Designer I more specifically mean an Interaction or User Experience (UX) Designer - one that designs the interaction experience between human & computer. I have experience in user research, information architecture and visual design, but I'm not a specialist in those areas. My expertise is in designing and prototyping solutions based on the information and resources available for a project.

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 - innovation is 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.

I believe 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.

I believe there is an essential component of human insight and instinct required to develop elegant and effective design 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.

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 lifecycle, 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.

Professional Portfolio

Download MS Word version of my professional portfolio 

Autodesk (2007 to Present)

As a Senior UX Designer on the User Experience (UX) team within the AEC (Architecture, Engineering & Construction) division at Autodesk I initially focused on design for the AutoCAD based AEC verticals (AutoCAD MEP & AutoCAD Architecture), before moving to design solutions for the Revit platform products in 2009.

Beginning in early 2010 I took on the role of Corporate UX Design Lead on Autodesk's new WikiHelp site, a collaborative learning space implemented on the MindTouch platform.

WikiHelp is the cornerstone of Autodesk's ambitious community learning initiative. It is the first major step toward creating a fully personalized, open source, collaborative learning environment at Autodesk - one that will revolutionize how the users and creators of Autodesk products share knowledge.

With easy to use contribution tools, extensive video content, comprehensive rating & tagging systems, and purpose built search capabilities; WikiHelp provides unprecedented opportunities for sharing knowledge.

I was a major contributor to the complete UI rework of the AutoCAD Architecture & MEP 2010 releases, where the ribbon, application menu, and other components similar to those found in Microsoft Office 2007 were integrated into Autodesk products as part of a corporate wide AirMAX initiative to have greater consistency across all its applications.

AirMAX strives to unite UX across a broad portfolio of acquired and in-house built CAD applications through the use of common design patterns, guidelines, and core components.

I continued to be a primary design contributor and collaborator on AIRMax projects, up until my transition to the WikiHelp and Community Learning project.

Unica (2005 to 2007)

While at Unica software I worked on several of the products in their Affinium Marketing line.

All the Affinium products were built on a 100% browser based user interface - a transition they made just prior to my joining the company. Because of this the development team had limited web UI expertise at the time, so I did extensive prototyping and implementation of the front ends for the products I worked on.

The Affinium suite of products made extensive use of advanced JavaScript and CSS layout. Unica was constantly pushing the envelope of web application UI. The projects I worked on were quite interesting and technically challenging.

Chordiant (2002 to 2005)

Chordiant is a leader in CRM (Customer Relations Management) software, and my focus within their product line was to optimize usability for their new browser based call center product (CCABE 5.6). Though similar in scope to some existing Chordiant products, as a call center product this application needed to be geared towards a much higher volume user than their previous Advisor and Branch product lines. To this end a ground up redesign was needed for most components of the application.

Additionally, major new features such as telephony integration needed to be incorporated into on holistic design, where maximum productivity was the top criteria for success. Design efforts to solve the unique issues posed by this project resulted in many novel solutions.

My design efforts resulted in a patent for the Process/Viewer Interface, which was the cornerstone of Chordiant's flagship CCABE 5.6 product. (US Patent Number 7,178,109)

Bowstreet (1999 to 2005)

In my three years with Bowstreet I worked on a wide variety of projects and initiatives, most notably on their flagship Designer application. Having begun our first serious design effort on version 2.0 of the Designer, I worked closely with a small team of product managers and engineers guiding all design and usability efforts up through version 5.

Bowstreet Designer 5 ran in the IBM Eclipse environment. Though originally implemented as a fully browser based application, the designer migrated into the Java based IDE space over time. With Designer 5 the transition was complete with all components incorporated into a standard Java IDE.

A major part of Bowstreet Designer 5 was the Builder Editors. Builders are the core component of Bowstreet's parametric development technologies, and the Builder Editors are dynamic form based interfaces that allow for quick and easy configuration of Builder parameters. Each builder editor UI is generated on the fly from metadata, allowing for simple customization of builder editors. Additionally, the builder editors may incorporate dynamic fields and dependency logic, thus allowing the forms to update and transform themselves based on user selections.

I left my full time position with Bowstreet in 2002, but continued to contribute in a consulting role on the design of Bowstreet applications up until their buyout by IBM in 2005.

Presentations & Publications

Work History

Employers

I've been employed on a full time basis by the following software companies over the last dozen+ years. Full details are available in my resume, which can be downloaded from the link below.

Download a MS Word version of my resume 

Here are links to my online work related profiles.

Professional Organizations

I'm a member of the following organizations,