User Experience Themes, Part I: Craft and Engineering

This past weekend I was asked to speak to a group of graphic designers and art directors about user experience in general, and my work in particular. This opportunity for reflection brought up four recurring themes in my work, themes that pose more questions than offer answers.

Of late, the theme most on my mind is Reconciling Craft and Engineering. A bit back, on a mailing list for information architects, Jesse wrote, “We are artisans, too often trying to get by with the methods of engineers.”

In my experience, we have to be both, and finding the appropriate balance is among the most challenging aspects of our practice. I suppose this is a classic left-brain/right-brain conflict.

My own gut tendency is toward engineering. (Had I not had a miserable experience in learning multi-variable calculus in 12th grade, I could have very possibly become some form of physicist.) I’m most comfortable solving problems through rigorous data gathering and analysis. I seek to understand how people process information so that I can tailor systems to satisfy them. I figure that if I get all the details right, order and meaning will emerge. I’m hesitant to consider any design as “final” that hasn’t been tested with potential users.

In the field of user experience the products we develop must, above all else, *work*. What I mean is that they must function in order to support their users. Before it looks good, before it conveys the latest business direction, before it satisfies the designer’s artisanal desires, the product must enable users to support their tasks at hand. Such a functional approach, by necessity, requires an engineering approach.

When dealing with web user experience, another factor to consider is that no product is ‘finished.’ Unlike other design disciplines where you create a final finished artifact (package, magazine ad, television commercial, industrial design product, etc.), web sites live on, and, so, must be maintained. Maintenance requires an explicit detailing of how the product works, why certain design decisions were made, and tools for keeping it running. This, too, favors an engineering approach.

In fact, I’ve worked at design companies that took an artisanal approach to web site design, where the designers crafted a beautiful solution derived from intuition and their incomparable ability to execute on it. Clients would receive this work, not know quite what to do with it (since they didn’t share or understand the artisanal vision), and would often alter it beyond recognition. In this instance, no one is happy–the agency can no longer point to the work as an exemplar, and the clients feel they spent a lot of money on something that didn’t work for them.

So, for the sake of playing it safe, we assume engineering methods, either from the field of usability engineering (in order to ensure our products will work), from library and information science (relying on accepted practice in the organization of information), and computer science (from database design to human-computer interaction).

Unfortunately those methods lead to overly reductive approaches, wherein you attempt to address every little problem in the system. We aim for solutions the success of which can be easily measured, and this doesn’t take into account the reality of the messineess of the systems we’re creating. We provide a false sense of structure and order on top of what is chaos.

Perhaps most damaging, and what I suspect Jesse was getting at in his statement, is that such reduction limits our ability for insight. For seeing the Big Picture. For making the intuitive leap that will push the design to the ‘next level.’

The logical extreme of this precedence of the engineering approach is that every site looks and operates similarly, because the reductive methods will result in the same solutions. And you’re seeing that emerge across the web, in travel sites, financial services sites, much of e-commerce.

And while it’s been important for sites to achieve that baseline of functionality and usability, we’re reaching a point where it’s imperative that we move beyond that. It’s time to utilize insight to provide a unique engagement for our visitors. Not that we ought to abandon engineering methods. Far from it — we need to figure out ways to merge craft and engineering to provide the greatest satisfaction.

12 thoughts on “User Experience Themes, Part I: Craft and Engineering

  1. “And while it’s been important for sites to achieve that baseline of functionality and usability, we’re reaching a point where it’s imperative that we move beyond that. It’s time to utilize insight to provide a unique engagement for our visitors.”

    1. I mostly agree with you, Peter. However, I’m concerned that most web sites aren’t even close to baseline usability. Also, as a side point, what is usability exactly? That’s far from decided. The idea of “baseline usability” is hard for me to objectively grasp, although I can certainly grok it.

    2. Not that I’m always a big fan of marketing, but it seems like you’ve left them out of the mix here. You almost make the discussion sound polar in that craft and engineering sound like opposites. I don’t think that was intentional, but that is how I read your posting. You could easily throw in marketing to the mix for example, and then you can talk about art, engineering, and business.

  2. Your comments on maintainability raise the question: Maintainable by whom? You lay the blame for the post-launch failure of some sites on the craft-oriented approach of the agencies; I am inclined to fault the clients, who always saw their role in site development as nothing more than taking delivery of a finished product. During my agency time, we always implored our clients to build in-house competencies — but they preferred a P.O. line item over adding headcount. Is it any wonder, then, that we turned over the jet plane and they flew it straight into a mountain?

    The craft approach to user experience does not require the turnover of a finished product — it just requires that maintenance be performed by someone qualified to do so. Companies now cling to an engineering-style process as their latest defense against having to develop user experience expertise. Insight, as you rightly put it, comes from sufficiently skilled practitioners, not from a sufficiently rigorous process.

    I know this isn’t what you’re advocating, but I object to the notion that any particular methodology can guarantee quality results. What matters is the skill of the practitioner, not the method employed. Instead of investing our energy in engineering the perfect process, we should be crafting a means by which those skills can be developed.

  3. Ironically, the thought leaders within the programming community are arguing for a move away from engineering and towards a crafts approach.

    This is largely due to the dismal failure of good software engineering methodologies, such as Software Engineering Institute’s maturity model, on actual IT projects.

    A good critique of these (and some interesting thoughts applicable to our situation) can be found in “Software Craftsmanship: The New Imperative” by Pete McBreen.

    The main problem with the SEI-type approaches is that they’re too cumbersome. In essence, you’re trying to build a small office building with techniques developed to build skyscapers. They do work, but take far too much time and money for the average project — and not surprisingly people mostly end up giving lip service to them.

    On the other hand, as you’ve noted, intuive approaches like traditional graphic design methodologies don’t scale well — especially since much of the craft was lost in the last few years as the traditional apprentice system broke down.

    (BTW, it’s not really true that graphic designers don’t worry about maintability. For example, when I learned to do corporate identity systems, or to do publication redesigns, documenting them so the client could maintain them was part of the what you were expected to do. The problem was often on the clients’ end, as JJG has described, even in my days in print.)

    The trick is finding the appropriate balance between rigor and flexibility, between thoroughness and vision. It’s not an easy task.

    The other thing, as I’ve argued elsewhere, is I think we’ve perhaps taken “user-centered design” a bit too literally and forgotten about that vision thing — the ability to come up that solves needs and desires not yet expressed.

    David Crow came up with what I thought was an extremely useful hierarchy of UX needs:

    Accessibility
    Fuctionality
    Usability
    Desireability

    Different techniques are more appropriate at different stages. An engineering approach may be best for ensuring functionality, but an intuive leap is probably better at achieving desireability. This doesn’t mean one’s “better” than the other, just more appropriate.

  4. Research without intuition is like a bar without beer. I think we are contrasting a bunch of things here that aren’t opposites:

    Research
    Intuition
    Art
    Crafts
    Engineering

    They are not opposites: research creates intuition (where it doesn’t you loose), engineering is large scale crafts – where it isn’t you loose. Art is one of the most misunderstood words around so I’m not going to talk about that.

  5. You can see that design and development methods that incorporate aspects of the master-apprentice are returning. One example is eXtreme Programming.

    Engineering methods have evolved to help manage the risk involved with building new complex systems. These errors are traditionally a development or engineering problem, i.e., the system doesn’t do what it is supposed to (for example the Soyuz crash.

    User-centered design has evolved out of the need to manage the risk associated with exposing functionality to end users and customers. User-centered design is also a way to do change management, it involves the users in the process of design/redesign. The user experience for someone like Amazon is absolutely critical to their business success.

    It is up to us, as user experience professionals, to develop and select the methods that best match the needs of specific projects. We need to develop coaching/mentoring/apprentice programs to continue to develop the user experience community. It seems that there is a growing shift that the value isn’t in the methodology (the engineering) but in the decisions and experience (the craft).

  6. We have got to open our eyes.
    We should learn from other comparable media. Realize that development of websites and services is both engineering and craft, both art and science.

    Learn from history: from the construction of Cathedrals, from the history of the film industry, and from theatre, circus and show.
    Contrary to what most of us like to think, not much is new in this industry.
    Focus on the experience of the user is as old as Aristotle – or older.

    Our projects are not bigger than ever before. Our users are not more mysterious than ever before. Our clients are not more demanding than ever before.

    In theatre the product changes every night and both the director and the actors know this. It is a performing art. In some ways websites are analogous to this – the users expectations change over time, and from one visit to another.

    In architecture the buildings change over time despite the architect who has been tought only to build for eternity (read Stewart Brands excellent book “How buildings learn”). Web sites are definetely like that – they need to accomodate new content, new functionality and thus must be able to change over time. In my experience this is often what goes wrong when a “bureau” like company hands over their “work of art” website to a client. The clients needs change over time, and the site cannot accommodate the content – because the “artists” who crafted the site did not foresee this.

    In the film industry the first films were mostly of technical interest. The big question being answered was: CAN WE DO IT? and the answer was YES WE CAN! So in web development. The first websites were amazing – just because we could.

    Then came the “artistically inclined” and changed the agenda: CAN WE MAKE IT BEAUTIFUL? and the answer was: YES! This phase is reflected in the “HTML and a little CSS and Flash” era of the web. When advertising agencies were ruling the web, the web was one big – more or less static – visual show off. Is it beautiful? Was the question. That’s why there was so much need for a Jakob Nielsen at the time.

    In the film industry in the beginning of the 20th century – slowly – over a few decades – the film language came into existence in the form of some conventions, which made it possible for filmmakers to express themselves in a form which could be understood by the spectators. Cutting, close ups, flash backs – and other narrative devices were invented in order to be able to use the medium as a communicative and expressive medium.

    I believe this is where we are now. We need to work WITH the conventions and FOR the conventions, to give the user the experience. User experience need not be some aesthetic tour de force by the artists on the developer team. We all know that. If we do not converge towards some conventions, we will delay the emergence of new expressive forms – precisely because people will not be able to appreciate totally new and innovative interfaces and so on.

    There’s another lesson to be learned from the film industry. Making movies is demanding and takes people with all kinds of skills to work together as a team. This is not something that you just do. Web teams can learn a lot from the way a film crew works. I’m not primarily talking about the overbloated Hollywood style, but independent filmmaking and perhaps filmmaking in other countries than USA.
    First of all production and art has been separated. You do not have one person who decides both “how” and “how much”. Money and time is the work of the leader of the production. Art and user experience (lets just call it by that name) is managed by the director. But the director does not do everything himself. There’s the director of photography and the editor, the make up artist and so on. These people know a certain craft or technology and they know how to make their knowledge work in the interest of the common goal – as set by the director.

    I have been on web projects that worked like this, but all too often have I seen projects and teams which did not work like this – and it almost never fails: When a project team does not deliver, it has to do with blurring of the boundary between the project, time and money management on the one side, and the craft, art and genius on the other side.

    Sorry my comment grew so much. I think I’ll post it and maybe expand on it, on my own site.

  7. Richard Dalton

    jjg wrote: “What matters is the skill of the practitioner, not the method employed. Instead of investing our energy in engineering the perfect process, we should be crafting a means by which those skills can be developed.”

    Why can’t we do both? To be sucessful we need skilled practitioners using effective processes.

    – Richard Dalton

  8. I think people are misunderstanding ‘engineering’. Engineering, at its core, is about taking one or more sciences, which is really just a body of knowledge, facts and statements, and “making some of it real” through one or more specific processes, usually to garner greater effectiveness and usually in repeatable and measurable ways.

    First, engineering says nothing about having to be effective, necessarily, but hopefully that is the outcome.

    These processes can be burdensome or lightweight. I don’t see XP or other agile methods as a “return to craft” as David Crow states, but simply engineering software through lighter processes that take mainly from computational science and sociological science.

    Secondly, what is “craft”? To say something is a craft, is simply to say it needs skilled action to be executed properly. It usually implies manual dexterity, but in modern times, the usage has expanded to mean simply something inherently difficult to execute that takes time to master.

    Engineering should be juxtaposed to art. The juxtaposition usually hinges on measurement. As stated earlier, engineering processes are usually measurable and repeatable to varying degrees. Art is usually unanalyzable, unmeasurable and unrepeatable. The way you get to an art end-product is usually unique, whereas in engineering, it shouldn’t be.

    So, peterme might be a little off. Is it engineering and craft, *and* art?

    PS: If anyone wants to reply, feel free to drop the numbers off my email and send away… (I hate spam and email addresses on blogs are often free to be harvested.)

  9. peterme.com: User Experience Themes, Part I: Craft and Engineering

    This applies to software development too.

  10. I just read this quote today and I think it’s awesome:

    It is by universal misunderstanding that all agree. For if, by ill luck, people understood each other, they would never agree.

    Charles Baudelaire

    Just thought I’d share.

    Mike

  11. I just read this quote today and I think it’s awesome:

    It is by universal misunderstanding that all agree. For if, by ill luck, people understood each other, they would never agree.

    Charles Baudelaire

    Just thought I’d share.

    Mike

  12. I just read this quote today and I think it’s awesome:

    It is by universal misunderstanding that all agree. For if, by ill luck, people understood each other, they would never agree.

    Charles Baudelaire

    Just thought I’d share.

    Mike