Design without touching the surface

I am preparing two classes at the moment. One is an introduction to user experience design, the other to user interface design. I did not come up with this division, it was part of the assignment. I thought it was odd at first. I wasn’t sure where one discipline ends and the other begins. I still am not sure. But I made a pragmatic decision to have the UX class focus on the high level process of designing (software) products, and the UI class focus on the visual aspects of a product’s interface. The UI class deals with a product’s surface, form, and to some extent also its behaviour, but on a micro level. Whereas the UX class focuses on behaviour on the macro level. Simply speaking—the UX class is about behaviour across screens, the UI class is about behaviour within screens.

The solution is workable. But I am still not entirely comfortable with it. I am not comfortable with the idea of being able to practice UX without ‘touching the surface’, so to speak. And it seems my two classes are advocating this. Also, I am pretty sure this is everyday reality for many UX practitioners. Notice I say “practitioner”, because I am not sure ‘designer’ is the right term in these cases. To be honest I do not think you can practice design without doing sketching and prototyping of some sort. (See Bill Buxton’s ‘Sketching User Experiences’ for an expanded argument on why this is.) And when it comes to designing software products this means touching the surface, the form.

Again, the reality is, ‘UX designer’ and ‘UI designer’ are common terms now. Certainly here in Singapore people know they need both to make good products. Some practitioners say they do both, others one or the other. The latter appears to be the most common and expected case. (By the way, in Singapore no-one I’ve met talks about interaction design.)

My concern is that by encouraging the practice of doing UX design without touching the surface of a product, we get shitty designs. In a process where UX and UI are seen as separate things the risk is one comes before the other. The UX designer draws the wireframes, the UI designer gets to turn them into pretty pictures, with no back-and-forth between the two. An iterative process can mitigate some of the damage such an artificial division of labour produces, but I think we still start out on the wrong foot. I think a better practice might entail including visual considerations from the very beginning of the design process (as we are sketching).

Two things I came across as I was preparing these classes are somehow in support of this idea. Both resulted from a call I did for resources on user interface design. I asked for books about visual aspects, but I got a lot more.

  1. In ‘Magic Ink’ Bret Victor writes about how the design of information software is hugely indebted to graphic design and more specifically information design in the tradition of Tufte. (He also mentions industrial design as an equally big progenitor of interaction design, but for software that is mainly about manipulation, not information.) The article is big, but the start of it is actually a pretty good if unorthodox general introduction to interaction design. For software that is about learning through looking at information Victor says interaction should be a last resort. So that leaves us with a task that is 80% if not more visual design. Touching the surface. Which makes me think you might as well get to it as quickly as possible and start sketching and prototyping aimed not just at structure and behaviour but also form. (Hat tip to Pieter Diepenmaat for this one.)

  2. In ‘Jumping to the End’ Matt Jones rambles entertainingly about design fiction. He argues for paying attention to details and that a lot of the design he practices is about ‘signature moments’ aka micro-interactions. So yeah, again, I can’t imagine designing these effectively without doing sketching and prototyping of the sort that includes the visual. And in fact Matt mentions this more or less at one point, when he talks about the fact that his team’s deliverables at Google are almost all visual. They are high fidelity mockups, animations, videos, and so on. These then become the starting points for further development. (Hat tip to Alexander Zeh for this one.)

In summary, I think distinguishing UX design from UI design is nonsense. Because you cannot practice design without sketching and prototyping. And you cannot sketch and prototype a software product without touching its surface. In stead of taking visual design for granted, or talking about it like it is some innate talent, some kind of magical skill some people are born with and others aren’t, user experience practitioners should consider being less enamoured with acquiring more skills from business, marketing and engineering and in stead practice at the skills that define the fields user experience design is indebted to the most: graphic design and industrial design. In other words, you can’t do user experience design without touching the surface.

Published by

Kars Alfrink

Kars is an independent interaction and game designer who makes things with technology for play, learning and creativity.

  • This is a returning debate. Agree on the conclusion that you cannot think about designing an experience without thinking about the interface itself. That does not mean of course that you can have a specialisation in the detailing of the visual aspects of an interface and also on the other end detailing the systematic aspects of the design. Everyone is an UX designer, some have better skills for detailing the visual aspects, others for thinking on the functional working.

    The context of the product is of course rather defining. A short-term campaign has different challenges than a digital platform product.

    You mentioned you are a bit distinct from practicing this domain, but that should be very useful. I am very curious how you could embed the approach from game design into the UX design. The separation of wireframes and visual design should not be the practice. An UX designer that limits its thinking to the wireframe was never a good practice but is in the current context of systematic digital products a no go.

    So ideally UX and UI designers are both responsible for designing the experience on a fundamental level and take their responsibility to detail the UX and UI tasks and have to keep working together. This goes also for the developer by the way. Especially as they are all part of the scrum team creating the product.

  • UX design is certainly not a synonym of UI design. I agree that UX design is more high level – more abstract, but UI design is not just the visual surface and certainly not just turning wireframes in pretty pictures. Jesse James Garret published his model The Elements of User Experience back in the year 2000 (http://www.jjg.net/elements/pdf/elements.pdf). The model shows interface design as the second layer of a product’s design, building on three, more abstract, layers. This second layer is in turn the foundation for the visual design; pretty picture some may say, but I see it as the layer to communicate intent and meaning.

    Interface design is for one part visual (wireframing, putting rectangles in a logical and effective lay-out), but also includes understandable wording, microcopy, useful defaults and sort orders, (avoiding) error messages, support for keyboard, mouse, and touch input. All those details that lead to ‘ease of use’.

    User experience is much more than ‘ease of use’, ux adds usefulness and desirability to the equation. UX is so comprehensive that I don’t believe in one person having all the skills to design a great ux. I do believe in ux-teams, where specialist – not only designers – work together. A truly great ux starts with understanding ‘consumer’ needs and market opportunities, includes technical feasibility and continues after sales with customer service. UX not only concerns the one product in development, but takes the ecosystem in which the product will operate into account.

    The broadness of ux, and the depth of detail in interface design justifies two separate classes.

  • Jeroen Visser

    I agree with you, Kars, on that the distinction between UX design and UI design is unworkable. Some thoughts on this.

    One problem is, that ‘design’ as a label is often wrongfully understood as a noun (hence the subdivisions), rather than a verb (which does not allow for subdivisions). Design first and foremost is a problem-solving approach, using prototypes of increasing fidelity to both understand the problem and explore solutions at the same time. In this process, the interaction between problem, designer(s) and solution is key, iterating as many times as needed to fully understand the problem and to arrive at the best fitting solution.

    The problem you encounter springs, as I see it, from the way ‘UX’ and ‘UI’ are tied to fidelity levels in the process, thus putting deliverables central, instead of the iterative process.

    As a sidenote: Adding to the noise is the lack of a separate label for mere visual work in the English vocabulary. In Dutch and German there’s a clear distinction between the design I describe above (‘ontwerpen’ or ‘Entwerfen’) and the visual design (‘vormgeven’ or ‘Gestalten’). But here also, problems arise, as the scope of Bauhaus or the Hochschule für Gestaltung in Ulm would have been broader than mere visual design.

  • Pingback: Wednesday is Link Day Still Breathing - online home of Chris Taylor - web developer, musician, geek()

  • Good old fashioned blog comments! This is awesome…

    Let’s see, where to begin. Okay, JJG’s model is maybe a useful point of departure. I would say I have the top two planes in mind when talking about UI design, plus a part of the third plane. (Surface, Skeleton and Structure in the simplified version.)

    And of course UX design covers all of it. So yes the trouble is it is very comprehensive and when practices at a sufficiently large scale requires teams of specialists (and generalists, I would add) working together in a cross-functional manner.

    I am all about design as a practice characterised by a particular cognitive style. This is why I am such a huge fan of Buxton’s book in which he so eloquently shows sketching to be a defining aspect of any design practice, including user experience design and by extension also user interface design.

    Let me addd that I really don’t like the term user experience design because experiences can’t be designed directly in my view—they emerge from a person’s interaction with a product (or service, or system, or whatever). But I guess we are stuck with the label and might as well make the most of it.

    With regards to the time-honoured split between wireframes and mockups and the lie we often tell ourselves that “wireframes aren’t visual design” I’ll just say I think that is nonsense. You are making fundamental choices that find their way into the interface so you are practicing interface design and visual design because you’re dealing with stuff people will look at. If you’re going to do this, you might as well acquire a modicum of understanding of visual design or more precisely graphic design (as Victor argues in the paper I link to in the original post).

    Of course there are “non-visual” decisions a UI designer or a UX designer needs to make while sketching and prototyping and making wireframes. As Victor points out a lot of those choices benefit from knowledge from the field of industrial design and by extension interaction design.

    All of which brings me back to my original point. How can you practice UX without also dealing with UI? I don’t think you can. In the case of software products, what is the user experiencing if not the interface? I think you do yourself a disservice if you do not strive to be able to “jump to the end” as Jones calls it in the talk I link to in the original post. Assuming a process which relies on sketching (as per Buxton) there is interface design happening from the very beginning of a design process.

    I am only concerned with all of this because I am worried organisations make bad decisions about how to build UX teams if they think “user experience” and “user interface” are two separate concerns. (I would prefer to call them design teams by the way but whatever.) This leads to such bullshit as the ketchup bottle meme which has been doing the rounds on LinkedIn and is being used by many well-meaning but misinformed individuals to argue for the fact that UI is “how it looks” and UX is “how it works”.

    I really hate all these labels. They are not grounded in reality and are more prescriptive than they are descriptive. But I am not interested in redefining them. That’s a fools errand. I just want to try and get to some kind of useful place by starting from their current usage and reasoning to new usage which might actually reflect actual best practices.