This post was originally posted on the Adaptive Path blog.

I have the good fortune of having a number of industrial designers as friends. As is the case with most people in the creative field, we have spent a considerable amount of time discussing our work. Throughout our conversations, there have been two tracks of thinking that impressed me. The first was a commitment to craft and an understanding of its importance to the final product's quality. The second was a sense of pragmatism and, for lack of a better word, accountability for how the design would impact the final product. I loved to hear designers take execution into account during the creative process due to the fact that I was someone who was often responsible for creating the final product. What struck me the most during our conversations was the deep familiarity my industrial design colleagues had with the materials used in the design. One friend in particular explained the necessity of understanding the materials, because without that knowledge, it would prove challenging to understand if the materials were appropriate to use in the first place. Strangely, that consideration for materials has traditionally been absent from design in the digital world. In my experience, designers have often expressed the sentiment that getting mired down in the details of technology would only limit the creative process. Unfortunately, the lack of understanding in craft would often lead to irreparable problems with the final product. Designers of digital products need to have that same dedication to craft as those in other design disciplines. That dedication to craft begins with an understanding of the methods and materials used in their trade.

We are all aware of how vital quality materials and manufacturing are to the feel of a product. During my years of building digital products, I have seen less and less distinction between the materials we use to create physical products and the materials we use to create digital products. Digital products have their own materials that share many of the same conceptual constraints and opportunities of their physical counterparts. Crafted objects of any nature (whether they are cars, paperclips, websites or mobile applications) which are designed with an understanding and appreciation for the materials used in their construction separate the good experiences from the great.

Leica is a perfect example of design with a dedication to their craft and the materials used. Leica's rangefinder camera line is considered one of the most timeless and "perfect" designs in the camera industry. It is hard to understand the pull of a Leica until you actually hold one. You do not need to be a camera aficionado to immediately grasp the level of quality in their design and construction. The camera is light, yet nearly indestructible. The body is almost literally seamless.

The interesting point is that while most professional-level cameras are made of metal, few, if any, have the feel of a Leica. Additionally, many camera manufacturers have tried to emulate the look and feel of Leica's rangefinder. While many of the basic design elements could be replicated at a surface-level, no camera ever could quite match it. It goes without saying that each of the elements in a Leica is rigorously designed and is as functional as beautiful. The aspect that both reinforces their excellence in design and separates them from other camera makers is their attention to craft and the manner in which materials are utilized.

In my work, I have focused on four main criteria when determining the appropriate digital materials for a project. Rarely is there a right or a wrong choice, and it often comes down to trying to maximize the upsides of each of the four while minimizing their downsides. Below is a quick description of each factor.

Cost of Materials/Manufacturing

Luckily in today's digital landscape, there are plenty of high quality, free and open-source technologies to build from. This may be one significant difference from the physical world as quality of material and cost are rarely directly correlated. However, even if we put costs such as software/framework licensing aside, there still are costs associated with the technology choices we make to build a product. While PHP, Python and Ruby may all be free to use, the cost of hiring developers with experience in each language to develop software can vary dramatically. Additionally, the production time can vary greatly depending on what technology you decide to use and how you decide to use it. There is a reason why we do not see highly refined and precise parts made out of most plastics. This does not negate the usefulness of such a material, but it has its specific uses. Similarly, certain technologies are more suited to precision crafting but often times have greater costs associated with them. A perfect example is developing for the mobile platform. A native iOS app will allow for much greater refinement in performance, motion and visual treatment, but there will likely be greater build costs compared to an HTML5 mobile app. Conversely, HTML5 will allow much greater flexibility in deployment and distribution. Both technologies have their place in mobile, we just need to know when plastic is more appropriate than stainless steel.

Manufacturing Feasibility

The more complex and difficult the product is to manufacture, the higher chance for significant increases in time, cost and likelihood of unreliable output. We should not constrain our ideas due to a lack of creativity, but sometimes pulling back from fun, yet perhaps questionably important attributes can result in a more timely, affordable and reliable product. A well-crafted plastic cup is still going to look and feel better than its poorly-crafted glass counterpart. This analogy translates quite well in the digital world where technically-challenging feats can require tremendous development resources and can often impact the product's performance and/ or stability. These attributes exude a sense of digital fragility or flimsiness that is frequently immediately noticeable.

Durability

Just like with physical products, people can quickly tell if the software they are using is prone to breaking. Breaking can mean many different things when it comes to software, such as downtime, crashes and unexpected errors. If we feel a product could break at any time, we place less emphasis on it in our life. As with physical products, durability has as much to do with how something is crafted as it does with the materials used. That said, there are some materials that are just inherently more fragile than others. This can often times be the case with technologies as well. When Ruby on Rails first came out, there were significant performance issues with the framework. Nonetheless, it was still a tremendous tool for developing and prototype applications at a wondrous pace. In many regards, early Rails development was akin to building with prototyping foam—it allowed rapid realization of a concept, but it probably was not the best material to build your production model with.

Feel

Feel is perhaps the hardest to define, but we all know it when we experience it. It is that "perfect" weight/texture/fit when holding an object in your hands and, conversely, that sense of "cheapness" we get when interacting with a product made of lightweight plastic or a poorly milled alloy. The quality of craft and attention to detail can create a sense of quality and confidence that is as intangible as it is immeasurable. Well crafted products can even garner a sense of trust from their users. A fellow colleague Ix keenly remarked:

It's a well known, well studied bias (and also pretty obvious, really), but those little details influence the 'perception of quality'. When a product is perceived as being high quality, the users are more likely to attribute problems to user error, while problems in a product with a low perceived quality make it 'a shitty product'

In a perfect world, all the choices we make should ultimately be guided to provide the optimal feel when the product is in the "hands" of a user. That said, often times our choice will rather have to be the best possible feel balanced with cost and time. This makes our focus on execution all the more important. If we cannot spend unlimited resources on buildout, we need to maximize the quality of craft. In my experience, the feel of a digital product is often heavily influenced by the small things we may take for granted—whether a transition was 300 or 500 milliseconds in duration, minor performance improvements, 1/2-second load time decreases, etc. A digital product that is visually beautiful but lacks that feel of quality can exude a sense of falsity—as if its value is only as deep as its veneer coating.

At some point, the products we design will need to be built. If we wish to ensure that our designs meet their intended vision, we need to not only understand that the materials in digital products are important, we need to take the time to be familiar with and appreciative of them. When we do, people will undoubtedly notice, whether consciously or subconsciously.

Acknowledgments

This post is especially notable for myself. Four months ago, I wrote about the need to share our ideas in a more transparent and collaborative manner. I used this post in particular as a test case for that concept. The experiment was limited in nature yet still absolutely invaluable both as a feedback mechanism and as validation that this process (in its most basic nature) is not hard to do. I plan to write all major posts, both personally and professionally, in this manner moving forward. For this experiment, I used Crocodoc to drive feedback. It is really fun to look at the progress made from the first draft, second draft, third draft to the final version. It should be clear that this post is not truly mine, but a collection of ideas and insight from many smart and talented individuals. I feel this model reflects the reality of how ideas are formed and shared much more than attributing something like this to a single author.

I want whole-heartedly thank all those who took the time to help form this post. Thank you Dane Petersen, Dave Johnson, Ix, Mike @uxforall, Peter Boersma and my wife (who I suspect wishes to stay anonymous). I consider you all co-authors.