Design at a 98 year old airline: my learnings so far
A year ago (ok, a bit more actually) I started as service designer at KLM’s Digital Transformation program, where we try to experiment with new technologies and solutions to help all our 33.000 colleagues (e.g. pilots, ground agents, baggage handlers and office staff) in their day-to-day jobs. Coming in fresh from the Delft University of Technology I knew there was a lot more to discover about the role of design than what I already knew in from theory. What I didn’t expect before was that jumping straight into a big, corporate airline would teach me this much about the role of design. In this article I want to share seven of my biggest learnings with you.
Humans: 1 — Technology: 0
Since I work in something that calls itself Digital Transformation, we of course do many technology experiments with new technologies such as blockchain and artificial intelligence. We try to solve problems of today using the technology of the future. But I have to be honest: sorry technology, human stubbornness will always beat you. In practice, people will always find workarounds to your technology, exhibit unexpected behavior, and show resistance to new ideas. At KLM, we often give our staff new digital tools, which we ourselves think are awesome and will help them greatly in their work. But did we take into account everything? Or will they revert to their old habits and use the old system which they got so used to after so many years?
In order to reach full Digital Transformation you need find the right balance between technological innovation and human behavior. And that is where design comes in: find the underlying human need first, and determine where technology can help. Sometimes people just want to be heard and listened to instead of just another digital tool. So yes: human-centrered design is still very much relevant in this buzzing age of AI, blockchain, self-driving vehicles, nanoparticles, and whatever more may come.
Pancakes are great, who doesn’t like pancakes (or crêpes)? But the first one always fails, right? Well, over the past year I learned that in design, everything is a pancake. Or in normal words: everything is an experiment with a testable prototype. Not only your final design solution comes about through experimentation, also things around it: processes, ways of working, tools, templates, communication campaigns, etcetera.
So in practice, I learned to never go into or come out of a meeting or workshop without having produced a new iteration of something. Always try to your new pancake to meetings about your project: it will most likely trigger all kinds of reactions from stakeholders and users. These reactions will tell you if you’re on the right track or not. Any reaction on what they want will tell you way more than discussing something that isn’t tangible yet. No prototype means no progress. Your first pancake never succeeds, but bake a whole stack and you’ll have something in the end.
Theory vs. practice
Remember those nice models on the design process? How they are always iterative, but still pretty straightforward and split into clear, logical phases? Well, theory is nice, but practice is way more messy. To me, the best reflection is still the infamous design scribble. Why? Because it shows the inherent chaotic nature of design.
Of course I’m overstating it a bit: in practice, there the design process of course contains limited iterations, and there are kind of course kind of distinct phases. But in practice at KLM’s Digital Transformation design also has to align with Agile software development, value prioritization, and above all: the way of working of almost close to 200 colleagues. To make this a bit easier you need what Carlile calls a boundary object. An explicit version of your design, engineering and business process, that makes implicit knowledge explicit and tangible. Look at it as a prototype (or pancake): seeing you process will trigger discussions on how everyone perceives it.
Immersion into airline jobs
In the past year I got the chance to see many new things at KLM, such as towing aircraft, our catering department, maintenance hangars, crew training facilities, aircraft fueling, and many more. when I started I didn’t really think of all the things that are needed to get your plane in the air so you can have a happy holiday and a memorable experience. [Image: more aircraft?]
Being so close to our end users gives us the opportunity to immerse ourselves in the environment of our colleagues. Compared to working for a client as external agency, we often get to connect the dots by combining knowledge from multiple projects and see patterns across the company. Looking at everything that happens motivates me even more to give my colleagues the best tools, processes, and culture there is.
Problems over solutions
As designer I spend most of my time looking for the right problem instead of the right solution. Yes, this sounds old and boring, and it probably also is ;-) But in practice I’ve realized that a designer’s role puts more emphasis on finding problems over finding solutions. Therefore you need to find ways to resist other people’s habit of jumping to solutions. Because finding great problems is way harder than finding great solutions. Once you’ve found your problem, creating the right solution is way easier, because you’ve gained all the insight during your search for the problem. Gaining the right insights will help you in making decisions when creating your solution. As I wrote earlier, a great way to do this is baking pancakes. Both for your problem (every version of your problem definition is an experiment), but also for solutions (creating rough, cardboard solutions will help you narrow down the problem).
Finding great problems is way harder than finding great solutions
Kill your darlings
Learning from doing experiments: fail fast and early. Easier said than done, as stakeholders are often happy with your early prototype and have the tendency to get attached to it. So don’t fall too much in love with initial results and be willing to kill what doesn’t work early on. For example, a prototypes made during a design sprint are suitable for collecting learnings, bit not per se for putting into development straight away. A prototype is just a prototype until you’ve tested and improved it.
Title vs. mindset
There is a stark difference between a being a designer by title versus being designer as a mindset. The design industry is slowly overcoming its ‘make pretty things’ stigma and moving on to creating meaningful solutions. Exact labels like service designer, UX designer, product designer, digital designer or interaction designer are so fuzzy that they are not much use in practice. But as long as we agree on mindset and values, designers can be from all backgrounds and come with a range of titles. Of course there’s a difference in skills and roles in practice, but its mostly about mindset over title. It’s all about creativity, prototyping, loving users, and great deal of being unafraid of big ideas and challenges.
It’s all about creativity, prototyping, loving users, and great deal of being unafraid of big ideas and challenges.
Humans will mess up your idea, so test, fail and kill early on. The design process in itself is chaotic and messy, but that’s what makes it so valuable. Emphasize problems over solutions, and find partners in crime who agree on mindset and values, but not per se on name and title. By doing so design can shine by connecting the dots and finding balance between all aspects of a solution.
For me there’s much to do, learn and try. KLM still has a lot to gain by improving the experience of its employees, and design has to play a central role in that. I still have a lot to learn about that: part of design is continuous reflection and improvement on its own role. So expect more blogs on that in the near future. The only way to learn is to try, as design is ongoing experimentation at its core.