mmyles2007+mds@gmail.com

Becoming a Designer

I've had an interest in computers for as long as I can remember. I initially focused more on hardware by pursuing a degree in electrical engineering, but fairly quickly my focus shifted to software. I finally came to design through my involvement in technical support, training, and quality assurance of software.

In my interactions with customers and vendors while on the front lines of support and training I found that the vast majority of problems users experienced were a direct result of bad design. Those building the products usually didn't have a clear vision of what to build, or who they were building for. Software engineers built products that functioned within parameters outlined by an often rudimentary requirements list, so they felt they had done their job. But customers felt these products were confusing and fell far short of expectations. What I saw was a chasm between the needs of the customer and the goals of the application developer that could not be crossed without outside help. Both sides needed an intermediary that could 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, and one to which I'm well suited.

After coming to this realization I soon after became aware of existing work and thought around design and usability 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 software design practices, and incorporated them into my day to day work, eventually focusing all my energy on design.

Over the years I've been able to use my unique background and understanding of technology, cognitive psychology, and sense of aesthetic composition to develop effective solutions to a wide variety of design problems. For me design is always interesting and a never ending challenge. It's valuable and rewording work that 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's intuitive to use and 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 the experience.

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

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, 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. But 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 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 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 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 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 which results 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, an exercise commonly known in the industry as, "putting lipstick on the pig." (Yes, that saying pre-dates the 2008 presidential race).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'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. 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 formative testing is an important tool in 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 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 failure are very high. The visionary approach can tend to create solutions for problems that don't exist.

The optimal path lies between these two extremes, what I call Informed Design. This approach takes the user and domain knowledge from the user focused side, and the experience and tools from 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.

Portfolio

Here is a small sampling of some applications, websites, and graphics projects I've worked on.

Application Design

Autodesk

While at Autodesk I've worked on the AEC (Architecture, Engineering & Construction) product line, initially focusing on the AutoCAD based verticals (AutoCAD MEP & AutoCAD Architecture), before moving to design solutions for the Revit platform products.

I was a major contributor to the complete UI rework of the 2010 release, 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 initiative to have greater consistency across all its applications.

I continue to be a primary design force in the AIRMax initiative, which 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.

Unica

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.

Bowstreet

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 continued to contribute in a consulting role on the design of Bowstreet applications up until their buyout by IBM in 2005.

Chordiant

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 conerstone of Chordiant's flagship CCABE 5.6 product. (US Patent Number 10/639,735)

Web Design

Though I enjoy the design and development of public facing sites, the majority of my work has been on browser based enterprise applications. Most of the public facing sites I've worked on are fairly small informational sites, but they have presented a fun and interesting mix of challenges.

I work with the client to refine a design, and then implement the final version - occasionally working with a webmaster that will fill out and maintain the site's content.

I've worked on many more sites than I've shown here, but like everything else, things come and go, and many sites I built over the years are no longer hosted.

JackHolland.net

The late Jack Holland was a renowned Irish-American journalist and author. I worked closely with his surviving wife and daughter to build a site to honor his memory and promote his last posthumously published book,

"A Brief History of Misogyny: the World's Oldest Prejudice"

RickerDesign.com

This is a site I created for graphic artist Scott Ricker. It's a simple portfolio site that shows off some of Scott's extensive catalog of work. I worked closely with Scott to define the clean and elegant look of this site and streamlined interaction model.

PhantomPhenders.com

This site was built for the husband and wife team of Rick & Mindy, who have a thriving custom motorcycle business in New Hampshire.

Rick does the mechanical work, and Mindy does amazing one of a kind airbrush art on the bikes. They came to me for a site that would showcase their unique custom bikes and capture their style.

RaisingScarlet.com

Raising Scarlet is the band my wife Tammy and I formed in 2008. We both have performed music most of our lives, and knew we would continue to do so together. We write and record original music, and also play in area clubs performing a mix of cover songs and our original material.

Medaid International Foundation

MEDAID International Foundation, Inc. is a New York based non-profit organization established by prominent members of the Burmese community for the sole purpose of providing aid to those most in need in other parts of the world. I did a redesign of their site, but it has not yet gone live.

Graphic Design

Even though graphic design has never been a primary focus for me, I have created quite a few graphics for applications and websites in my career. A small sampling is shown below.

Icons

I've created many icons for products. Below are a some examples from the Bowstreet Web Factory products and the Ohia network products.

Logos

The following are some logos developed for companies and bands.

A Flash animation developed for The Code Factory website

Downloads

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,