Designerly ways of working in UX

If IBM and Apple had a baby today, it would be called UX.

Interaction Conference

Founded in 2008, the Interaction Design Association Conference brings together practitioners interested in all things around interaction design. Interaction 12 took place in Dublin, Ireland on 1–4 2012. Interactions 13 is set to take place in February 2013 in Toronto.

See all posts

If IBM and Apple had a baby today, it would be called UX.

Not very likely, perhaps, but you see the point: UX has a mixed heritage, drawing from engineering traditions as well as big-D design traditions. I would like to characterize briefly what I have come across as typical values in professional UX practices. Then talk about what I see as “designerly” ways of working within interaction design. And then finally put the two together in order to highlight some opportunities for designerly ways of working in UX.

A short history

For UX, the engineering tradition largely means the academic field of human-computer interaction (HCI). This field was founded in a time when computers were used only for instrumental purposes in work settings, and thus the focus was squarely placed on usability, efficiency, reducing user errors and fitting the users’ tasks. In the 1990s, the practical application of HCI knowledge to product development was even called Usability Engineering.

And then computers moved out of the offices and into our pockets, cars, headphones, living rooms and all other aspects of everyday (Western) life. Internet became part of the infrastructure, and huge digital consumer-product markets emerged in the entertainment and leisure sectors. Most computers today are used for pleasure rather than for business; the use is discretionary rather than mandatory; the designers’ focus is on experience and sociality rather than on usability and computer-supported collaborative work.

During that move, HCI crossed paths with Design (via consumer products) and Media (via social and communicative uses). Lots of new methods and concepts were introduced, and today there seems to be consensus that the professional discipline of shaping digital things with a focus on users should be called User Experience, or UX.

Blending engineering and big-D design traditions

Apologies for the brevity of this historical sketch; what I want to illustrate is simply that UX is at a point where engineering and big-D design traditions start to blend. Or, rather, they should be starting to blend, given the tasks that UX professionals are facing. I am not sure they are, though.

I have spent quite a few years as a university-based designer working together with UX professionals, mainly in the ICT and telecom industries. What I tend to find is that professional UX practice is quite heavily influenced by the engineering/HCI tradition. This shows in observations like the following.

  • There is a strong preference for fieldwork: To study intended users in their settings to learn about them and perhaps find problems and opportunities for improvement in their current practices;
  • Work should generally proceed in stages: First observing and analyzing (for instance through fieldwork), then deciding what to design, and then designing and testing;
  • The results of observation, analysis, design and testing are documented and communicated in reports;
  • In general, UX is seen as a profession that concentrates on users and their needs and capabilities. It works together with engineering, marketing and design/communication as needed.

The designerly ways of working

Given this state of affairs as I see it, I should now move on to addressing designerly ways of working in UX (as promised in the title). But what does that really mean? What are designerly ways of working?

My sense is that there is a design tradition of working (“big-D design”) that is strongly related to design-school training and the creative industries, and that generally involves four characteristics:

  • Design is about exploring possible futures, examining what things might be like, how people could work and play in new ways. It may be based on fieldwork (studying users and settings), or just as well on creating a structure of participation, where there are no “users” to study but rather participants contributing their expertise in a particular field of practice through a co-design process. Exploration in design may also be guided by technical possibilities, i.e., exploring the potentials of the design material at hand;
  • Design addresses multiple aspects of quality in parallel. From a design point of view, the instrumental and the technical are inseparable from the aesthetic, symbolic and ethical realms. When designing a way-finding mobile app, for instance, its usability cannot be assessed without considering its performative qualities. In plain English: If you look silly when using it, you will not use it in public, no matter how well the interface performs in the usability lab;
  • The understanding of the “problem” grows in parallel with attempts to create “solutions”. Design often starts with partial and unfounded solution ideas, and lots of them. Those ideas in turn stimulate a growing understanding of what the “problem” entails, and new solution ideas emerge. The resulting trail is mapping out a space of possibilities, a design space;
  • Design entails thinking through sketching and other forms of tangible representation. Design happens in the moment of drawing a sketch, or building a model, or enacting a future use scenario. It is not about thinking first, and then capturing the thought. The body and the mind, the pencil and the eye, think together. This is one reason why it makes sense to talk about design as experimentation.

Mapping engineering and designerly ways

Even though the design tradition grew up in a more artsy neighborhood, my experience is that blending it with engineering/HCI style UX practice is a worthwhile effort. In order to get a sense of what this blending might entail, let’s start by putting the engineering and the designerly characteristics together in a grid.

Mapping engineering and designerly ways

We can see that there are a few areas of potential friction between engineering and designerly ways of working – for instance, the “fieldwork” preference of studying representative users in typical settings seems to be at odds with the designerly practice of “exploring possible futures.”

Introducing designerly thinking in UX practice

To address the frictions in introducing designerly thinking to HCI-tradition UX practice, I have tried quite a few strategies. Five of them in particular seem to yield good results in various professional UX settings. I have placed them in the grid to indicate which specific friction they address, and next I will discuss each of them in turn.

Diverging in upstream phases: This is probably the most important part of instilling designerly thinking in UX practice. What it means is simply to frame the start of a new design process for yourself or your team as a learning adventure, where the aim is to investigate as many possible directions, ideas, questions and problem framings as you can – while you can still do it at a very low cost. Sketching ten product ideas in pencil thumbnails takes ten minutes and provides you with a whole catalog of different ways to envision the project-to-follow and another catalog of different ways to frame the “problem.” If you spend an hour, you will have fifty ideas or ten very different ideas. This, in turn, might guide you in planning fieldwork and help you steer away from the most obvious incremental-fixes-for-observable-problems framings – assuming that your incentives include innovation, which is quite common these days.
Fieldwork can be geared towards divergence by means of seeking unusual settings, extreme personas and future envisionments, which in turn suggests paths towards other parts of the design spaces. All the while seeking to maximize learning through divergence before having to commit to one direction. Examining ten different design directions rapidly to identify the most promising one provides much better validation than locking onto one without examining the alternatives, no matter how much you iterate on the chosen direction further down the road.

A broad inventory of concepts, trends and ideas that was developed quickly as the foundation for designing a tribal-navigation video service. It provided the basis for five distinct design concepts that were elaborated and then synthesized together with the client into one project direction.

Related to fieldwork, there is the notion of turning users from objects of study to participants in the explorative adventure. There is no room here for details on participatory design or its contemporary cousin, the living lab, but there are proven ways to team up with users in exploring parts of the design space far away from the users’ current practices (which is all you learn about if you study users using conventional fieldwork techniques). Again, early phases may provide room for divergent approaches – which adds a comfortable sense of faith in the chosen direction once it is time to start converging.

Staff members at an Intensive Care Unit during a participatory design process aimed at supporting informal on-the-job learning and knowledge sharing. (image credits: Erling Björgvinsson and Per-Anders Hillgren, by permission)

The big picture is also related to divergence. What it means is broadly that even when you dive into the details of a particular design direction, try to keep a third eye on the overall direction of the work and on what your detailed decisions mean for the product and the use situation as a whole. This can be difficult at times, which is why it is generally a good idea to have systematic big-picture reviews when the team is required to step back and rehearse the overall situation. Good questions might be, for example, “What does that really mean for the user? How does it fit with her everyday media streams and practices? What would she make of it in relation to these other ten things that she likes to do? Are there other groups of stakeholders who might come across this design and what would they make of it?” Asking this kind of questions might sound strange; after all, we have decisions on how to proceed overall, surely we don’t need to spend valuable time revisiting them? I would argue that you do need to, simply because detailing the design changes your understanding of the overall situation, and it is much better to spot big-picture problems at the stage of design detailing than to learn about them the hard way after product launch.

Another aspect of the big picture has to do with organizational silos. The big picture spans the different functions of the organization in a way that seems disconcerting to some UX teams specializing in studying users in their current settings and wireframing interaction flows: If we were to look at the overall situation, we would be overstepping our mandate to interfere with business development, engineering, visual design, et cetera. This is true, and that is why I note that multidisciplinary (“crossfunctional”) teams have much better chances of keeping the big picture alive throughout the work. Moreover, my strong sense is that multidisciplinary teams actually save money in terms of reducing interdepartmental confusion, communication breakdowns and redundant duplicate work – as opposed to costing money by having people spending hours in activities that are not 100% devoted to their respective fields of expertise.

The final item – using expressive forms that are close to use – follows mainly from a mode of working that promotes sketching. Basically, if interaction sketches such as storyboards, video scenarios and function mockups are the best ways of exploring ideas of future use and learning about the design space, it seems reasonable to use them also for communicating those insights. After all, what UX does is essentially validated visions of future use. Communicating UX results in use-oriented representations (i.e., interaction sketches) not only increases precision by speaking the native language of the topic addressed, but it also saves money by not having to convert use-oriented representations to standard report forms.

The actual design documents (“specifications”) from the concept development phase of a collaborative platform for product information.

To conclude

I need to make the obvious apology that addressing this big a topic in a short piece of text leaves generalization holes large enough to drive a full-scale pervasive game prototype through. I have neither been able to include concrete examples or specific stories, nor to substantiate my claims with academic evidence or sustained reasoning. Still, I hope you find some food for thought on why you work the way you do, and how you could play around with working in other ways.

Interaction 12

Jonas Löwgren will be one of the keynote speakers at Interaction 12. It is the fifth annual conference hosted by the Interaction Design Association (IxDA). Each year, IxDA aims to gather the interaction design community to connect, educate, and inspire each other. This year it is held in Dublin, Ireland.

Jonas Löwgren

Jonas Löwgren (b. 1964) is professor of interaction design and co-founder at the School of Arts and Communication (K3), Malmö University, Sweden. He specializes in cross-media products, interactive visualization and the design theory of the digital materials. Jonas has taught interaction design in university courses and in companies since the early 1990’s and initiated the influential two-year master’s program in interaction design at Malmö University in 1998.

3 comments on this article

  1. Pingback: » Designerly ways of working in UX Johnny Holland – It’s all about interaction » Blog Archive |

  2. Thanks Jonas for a insightful piece. I had never thought of UX being composed of two ‘schools of thought/practice’.

    Now that I think about it, I am definitely from the design tradition, but I learned many of my UX/usability skills from people who had a HCI background.

    I am indebted to these people … and yet … I always felt they had a blind spot, not just for design aesthetics, but even for other things that come naturally to designers.

    For example, usability engineers talk about ‘heuristic’ reviews and I, too, have come to use this phrase. But it is not natural to me — because it is not the customer’s language. And, as a writer/designer by instinct, I don’t like to use jargon. I think engineers are drawn to jargon.

    But don’t get me started on the foibles of designers…

  3. Pingback: Exploring, sketching and other designerly ways of working (keynote from Interaction ´12)