What I do as an Experience Designer*
*clue, it’s not designing screens.

Victor Johansson
A View from Above
Published in
9 min readDec 1, 2020

Intro

I design experiences for physical products.

Hmm, ok, so what the hell is a physical product experience?

Well, “product” used to be associated with an object that you can touch and see, something tangible. That’s still the case only now there’s so much more to it than that.

Pick up any technological product and observe. There are aspects that you can see and feel such as the shape, the materials, the colours, the graphics, the buttons, and so on. The role that design plays here is clearly comprehensible. But what about all the aspects, or experiences in this case, that we cannot directly see? For example, how the product behaves when you press a button? How does it react when the battery runs out? And how does it interact with other products and systems around it?

All these aspects that are not tangible are still very much key parts of a product. These are the experiences that I spend most of my time on.

Interested in how these experiences are designed? Then keep reading.

How I ended up here

I started out studying traditional product design for my BA where I quickly discovered that I wasn’t that interested in designing chairs or perfume bottles. Instead, I wanted to push further into and explore user behaviors, technologies, and what experiences these could enable. Fast forward to my MA in industrial design at the Central Saint Martins MAID course, I found a very broad and open approach to the term Industrial Design. So I spent most of my years in London designing the systems that products fit into and what experiences they could deliver.

After graduation, I watched quite a few of my friends in industrial design start their careers within digital and UX design. Even though the work that they did was inspiring I still found myself more drawn to designing the experiences that took place within the physical realm. This was, however, a profession that seemingly did not exist. So I started slowly carving out some space for myself while freelancing. My career began as an Industrial Design Intern at the digital agency Clearleft and after that I continued to work with BBC R&D software teams on designing hardware for their digital experiences. It was a great learning experience starting out my career working not alongside other industrial designers but digital designers and software engineers instead.

When I moved back to Malmö, Sweden I came across Above (which was then called HOWL and employed around 10 people). I sat down with the Creative Director with my portfolio, now filled with prototype wires, hacked electronics, and videos trying my best (at the time) to communicate what really excited me about design. Even though the response was very positive there was some clear hesitation around whether there would be enough work for the flavor of design that I was showing. Luckily, I snuck in a few traditional Industrial design projects in the back of my portfolio that most probably sold me to the agency!

Over the coming years, HOWL merged with a tech agency called FRANKLY and continued to grow into the full stack innovation agency that Above is today. This turned out to be the perfect place to dig deeper and specialize in Experience design with a focus on technological products and strategic experiences. Having a diverse team also allowed me to learn so much from adjacent fields as Above’s designers work side by side with software and hardware engineers.

During the last few years what I do has transitioned slowly but steadily from traditional Industrial design to more and more Experience design, where I bring value to the customer, client, and the planet.

Experience Design — How?

When designing product experiences, there are three different levels that experiences can be broken down into; System, Behavior, and Product. All three can be worked on individually or as a whole. But like most problems, it’s better to attack it from all angles.

Products don’t exist in a vacuum, this is especially true for connected products.

Systems

Early on in the process it’s important to zoom out. Much like my counterparts in digital UX design I work on a wireframe level, for the most part, where I examine the products themselves as nodes in a larger system. I look at the bigger picture where products are placeholders and focus on how they behave and interact with the user and other parts of the system — because there is always a system.

Designing products that are part of complex systems (no matter if the systems already exist or have to be designed at the same time) often requires the overall experience to be designed before the products. This is a task that clients come to us for more and more these days. So we design and prototype entire systems of products with the fidelity that allows us to run user tests that will help us evaluate the experiences and define the roles of the different products in the system.

This, of course, poses interesting challenges where we are indeed required to design the physical products themselves without actually designing them; trying to balance on a knife’s edge where the design on the one hand is refined enough to support the intended experience, but on the other, is neutral enough to not elicit response from the test that stems from the individual products.

By designing the experience before the product, it makes it easier to define the proposition of all consecutive products as the interdependencies and individual roles of the components are clearer from the start.

Behavior

As mentioned earlier there is the intangible side of a product, the signals in which it communicates to other products, the sensors that detect light, sound, distance, orientation and magnetic fields. Next to this is also how the product reacts to the passing of time, auto-off timers, time zones, circadian rhythms and even on much longer perspectives how the product can change functionality and behaviour over time with firmware and software updates.

When all of this comes together products can almost appear magical for the user.

Which brings me to one of my favorite quotes:

“Any sufficiently advanced technology is indistinguishable from magic” — Artur C. Clarke.

It can be very aspirational to think that the experience you design can be perceived as magical by its users. I am often left in awe by other designers when I myself undergo magical experiences as a user.

A common ingredient to make an experience feel magical is to make something that makes users ponder: how did that happen? Or, how did it know that? This is great as long as the experiences keep doing what the users want and intend.

But when the experience breaks and users are left with a product that doesn’t work the way they imagined it would, what then?

This is why a big portion of my job is both designing the behavior AND making sure that we can communicate said behavior to the users. This means that whatever conceptual model (the model we use to design the system) has to match or at least be compatible with the users’ mental model (the model users use to create an understanding of how they think the system works). The larger the dissonance between the two, the larger the risk for errors. So it’s often a good idea to continuously check with users what their mental model looks like no matter how well resolved the design is.

It also means that sticking to paradigms that exist and are well established is often a good idea. Or at least being very clear about how and why you are going against the established paradigms. We are often challenged with designing completely novel products, behaviors, and systems that might not have any real predecessors or references in the market. Then we have to design our own paradigms that are often rooted in some analogous products or experiences. It is then really crucial to choose the right metaphors and make sure that we can communicate to the users what that metaphor is. You don’t want to design a paradigm that is based on a TV and in the user’s mind they relate it to a toaster.

As a little thought experiment, think about designing an entry system for a house that both locks and turns on the alarm as you activate it. Then try to choose the color codes for the interface. If you go with the on/off metaphor then it’s easy right? On is green and Off is red. But if you go with a locked/unlocked metaphor, then red means locked and green means unlocked. So the act of arming and locking have underlying paradigms that are contradicting. Which one do you think is the better option?

On/off or lock/unlock? What’s the best paradigm for a door-lock that activates the alarm?

Product

As projects progress beyond the early phases where the task at hand is more defined I eventually zoom in (if only for a while). On a product scale I spend most of my time working with the interfaces that connect the user to whatever technological breakthrough happens on the inside of the case (or in some server-hall halfway around the world). This part of the work tends to be a lot about: If we place this type of button on the product with this functionality, in what context will this be used? What state is the user in? What senses can we rely on?

And very quickly we zoom out again since every detail on the product interface itself has to be considered within the larger context.

As mentioned before there is always a system, even on a product level. A button on the product can link to the controls on other devices. There used to be a time when a button on a product did just one thing, and that was it. The play button on a walkman started playback and that was that. Today that same function can be initiated from several other devices across space and time. There might be several functions nested in that same button based on context and how the user presses the button. And all this can change with the next software release.

When done correctly, this leads to products that can stay relevant much longer to minimise environmental impact.

As you can see, there are no hard boundaries between artificially constructed categories (System, Behavior, Product). They are instead more of a gradient from micro- to macro-scale. Nevertheless, it simplifies the design process and communication to think of them as three distinct levels.

So… that’s what I do as an experience designer and how I ended up where I am today. It’s been a long and winding road with a lot of learnings along the way. My two most important ones are probably:

Build it!
Experiences aren’t defined in slides. They need to be prototyped, tested and validated. Together with the rest of the team at Above I spend a lot of my time building UX prototypes, video prototypes, and working with user-research (My colleagues wrote about video prototyping extensively here and included a UI toolkit for anyone to try it out). This includes everything from five minute sketch prototypes to high fidelity prototypes that emulate real products.

Collaborate!
Experiences aren’t designed in a vacuum and every aspect of the experience is bound to affect many disciplines. I have counterparts within the Digital design and Tech teams to make sure that all facets of the experience fit together and work really well. And beyond that, as I have hoped to show in this article, experience design needs to be tightly knit to all disciplines from mechanical engineering, software and electronics to industrial design.

Would you like to work with product experiences as well? We are looking for interns, apply at above.se

--

--