Prototyping At Finnair

Marja Ojala at UXDX Community: Helsinki. Video: https://www.youtube.com/watch?v=ZBsAt_kQyws

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

What prototyping means to me

[00:00:09] I'm Marja Ojala from Finnair. I'm the lead designer for our mobile app and in-flight entertainment, which is the seatback screens and our onboard Wi-Fi portal, along with the crew app that we use to control the seatback IFE. The theme now is the perfect wedding dinner. I wanted to dig a bit into the word prototyping, so a bit of semantics. This is the wordbook definition of prototyping: the activity of making basic models or designs for a machine or other industrial process.

[00:00:43] I asked around the design team what for them prototyping means, and there was quite a range of answers. I think sometimes the word prototype and prototyping as an activity are mixed. Personally I don't think prototyping necessarily needs to lead to a certain type of prototype. I especially like this one here: prototyping makes me a better designer. That's actually exactly what I think as well.

[00:01:14] For me prototyping is almost like a state of mind. It's about doing design, not about talking about it. I don't know if any of you have seen this Frontiers of Design film, or documentary, which is available online now for free to watch as well. There's this statement that we've been spending a lot of time in recent years just talking about design but not actually doing design, or the craftsmanship of design. Maybe part of it is the design thinking trend or something similar. But in my mind prototyping is exactly that: we're doing design, we're testing what is out there.

[00:02:02] Also, one of the important things is being ready to be proven wrong. This for me, especially when I was a young designer, was extremely difficult: actually starting to do the prototypes and realizing that I'm not right, that I have it all wrong, and then having to scrap that idea and redo the whole thing, or redo parts of it. It maybe took some time until you realize that it's not personal. It's your work, it's your job to be proven wrong and then trying to be as accurate as you can.

[00:02:46] Prototyping, I also think it's a craft for all designers regardless of what your field is, service design, UI design, but also not only for designers. So we have a few examples here where we have developers working closely with our designers doing prototypes.

The teams at Finnair and how their prototyping differs

[00:03:06] What we have at Finnair: we have a range of teams. We have the in-flight team, which I'm part of, the mobile app team, also in the same area or the same range. We have Aurinkomatkat. Aurinkomatkat is this package holiday company that is like a sub-branch, or not, we are like a sister company to Finnair. But the designers are actually working in our design team, or they're working in their own team but we have a kind of design team, it's a mixed situation.

[00:03:46] Then Finnair.com, our website. At the moment we have two versions of that. We have the current Finnair.com, and we're now rebuilding our Finnair.com website to match the expectations of the current day. Then the mobile app. I don't know how many of you use our mobile app? Yeah. That's my team as well, and we actually have one mobile developer here, our iOS developer.

[00:04:25] Then we have payments, like a separate team itself. It lives among all of these, but it's a really defined, really detailed, one action or one task to be completed type of team. They focus on really super details, whereas for instance in in-flight we have no control most of the time. Every flight is different. We work in situations where our devices might be offline, even the crew devices might be offline, there might be crashes on the seatback IFEs during the flight. We have no control. So that's also one reason why we don't go into that level of detail and depth that for instance the payment team can go. For us, not going into the details actually allows us to be maybe a bit better, because we are more flexible.

[00:05:22] Finnair.com, of course, they have it all. They have the booking engine, managing my booking, they have destination information and so on, everything. So they have both the details of the booking engine and the [?] content at the same time, and tasks like the user or customer tasks to be completed.

[00:05:53] One thing actually, from the beginning, we did this slide: too much focus on features and not enough on user research and solution validation. This has been of course a problem for us as well, I ticked that box. Finnair, as an older company, a legacy company, we have a lot of good things but also a lot of bad things that come, or things that maybe are not current time anymore. But that's exactly why we do prototyping, so we have evidence on what should be done, and we have tests that we can test and we can communicate, and use that information then to do business decisions, so that we can make whatever decisions are needed. Of course some things still fall through the cracks, but that's something that we cannot always escape.

[00:06:56] And also a bit of a spoiler: we haven't reinvented prototyping or prototypes to that extent. What I'm going to show you is just how we do prototyping at Finnair.

Paper prototyping

[00:07:13] My favorite, paper prototyping, the basic of the basics. I use it for myself, for my own purposes, basically on a daily basis. Nowadays, maybe using it in a shared context or in the context of a team, I think that's not that relevant anymore, well, in most of the cases, which I'll come to a bit later. But for instance this year, this paper prototype of a mobile app economy seed[?], which we're actually launching pretty soon for iOS, was during a design review where we could easily communicate the idea of how we want to do this transition or animation. I made it a bit fancier, but the original prototype was just a Post-it, like this. Even doing these kinds of animations or transitions with paper, it's extremely efficient.

[00:08:20] Then there was this onboarding passengers' devices. This is the constant problem that we face: due to technical limitations we cannot use for instance a captive portal or some other means of onboarding. So we've been exploring different ways to inform people that we have Wi-Fi on board and how can they get on the Wi-Fi. Here is the testing of a QR code: do our customers understand it? These are just Blu-Tacked onto the seats.

[00:08:56] But maybe it's an interesting detail that we do this on our planes. This plane in particular, I can't remember if it was in the hangar or at the gate, ready for departure for the next flight, but we do have access to our planes when needed. This is still kind of ongoing and we use these prototypes also to talk with our technicians: what can even be made, what are the safety regulations, they're super tight regulations of course on board, what can we do, what shape can we do, and all of these. Although this is not a digital prototype, it's still somewhere in between.

[00:09:42] Then, well, I couldn't add it here, and actually I couldn't add any prototype for Aurinkomatkat since all of them are more or less confidential, but for instance we have this paper prototype of our pricing and bundling model made by our designers and developers in collaboration, where if you select one thing, then what happens, what are your options from there. It has a huge influence on the UI or the UX and even the development that can be done.

Basic digital prototypes

[00:10:13] Then basic prototyping. This is basically how we replaced paper prototypes, this kind of super fast prototyping style. Especially, we have a design library in use, more or less using a design library, in for instance Sketch. Sketch may be the fastest one at the moment with the design library. For instance this prototype took me three minutes to make. That prototype, I did ten versions in one day and all of them were kind of ready for user testing. So also not going into super complex prototypes, just enough to do the basic ABC flow.

[00:11:13] Of course the strength or the pro point for a basic flow in Sketch or InVision, not sure if you do it there, is that you can easily spread it out for testing, you can easily spread it out to stakeholders, which is not possible with paper prototypes, which we have also done but only in the context of design sprints where it's a more controlled group of people. So here, audiobooks payments, as audiobooks are also coming during this spring.

Complex prototypes, and the tab nobody could find

[00:11:51] But then, complex prototypes. We are using Axure for most, and both of these are from Aurinkomatkat. Those guys basically set the bar for us when it comes to prototyping, and they also prefer working with these extremely wide and complex prototypes. Of course they do have their whole customer journey: you've searched your flights, you do your dates, you search your hotels, you pick your ancillaries, so extra services.

[00:12:31] Here, actually, this was an interesting story. This prototype was done for qualitative user testing. They tested people at the airport and they wanted to see how people are finding this City Breaks tab on the front page. Sadly we didn't get the original prototype, we obviously have a problem in our version control, but we got the enhanced prototype, so the first prototype that they did. We were trying to find this [?] here. The first prototype they did: 0 out of 15 participants found that tab, although our assumption, or the assumption of all of the designers, the developers, everyone, was that of course that's a usual pattern, people should be able to find it. No one did.

[00:13:32] Because, well, they were searching for London, and London is not a sun destination but it is a city destination. So what they did then, based on their findings, was that if you type in London into the first search field, then there's a tip that moves you to City Breaks. And from there the zero went to 100%. This actually increased our Aurinkomatkat sales by 300%, just this one tweak. And that basically would have been a trick that would have gone unnoticed unless they'd done this prototype, and actually the previous one and then this one.

[00:14:22] To check it on the right side, there's a bit of an example of a prototype. It's a nice prototype, but it's a complex one, and the purpose that it was built for, it doesn't really serve the purpose. Of course it's good to have it for communication within the team, also with the stakeholders, so what's there. This is being launched next week. I'm not sure if it was Monday or Tuesday, but during next week, called Oma Auma[?], so that you can manage your holiday in the web browser. It's a bit similar to the Aurinkomatkat app as well.

[00:15:13] But they did this prototype where you can configure different states: what happens if it's before the holiday, during the holiday, after the holiday, what type of ancillary or extra services or events you have on your timeline. This was meant as a tool for developers to check what type of configurations are possible. In the end developers came up with their own tool which was faster and more convenient for their own purposes. But it was an exercise, and of course we can use this for our user testing, and we will use this for our user testing, but for the original purposes for which it was made it wasn't that successful. So of course when it comes to these complex prototypes, the reasoning behind what to do is always a bit of a, sometimes it works, sometimes it doesn't, but it's always a learning experience.

Prototyping a payment form, and a proof of concept for onboard Wi-Fi

[00:16:23] Other complex prototypes. Let's maybe start with the one on the right again. This was made with Axure again, and I wanted to take this as an example from our payment team. They are basically working with the tiniest details, and here they did this. It took two designers and a quarter to do this prototype. And again, we realized that, yeah, a developer could have done this easier and faster just by using JavaScript, but it was also a learning experience for our developers that they had to use our prototyping tools, Axure, and see what's possible there, for instance that you can do JavaScript in Axure.

[00:17:14] But basically we had to communicate what we want out of a payment form, or an expiry date form, from our external stakeholder who is then doing that form. Due to some legal requirements we have to run our credit card form through an external party and we cannot do it ourselves anymore, so they have to do it. But we wanted to be super, super precise about what we want out of that form. So this needed to be done. Maybe the way of doing it might need re-evaluation in the future, but yeah, worth doing, because now I think we got the type of form that we wanted.

[00:18:17] On the left here, this is actually what I would say is a cosmetic prototype. One playing here, this getting from your mobile app to our onboard Wi-Fi portal. But this actual prototype, this I did just for this presentation. The actual prototype was a POC that we did, a technical POC, because I could have done this but it didn't tell us anything that we needed to know. Because we're dealing with, when you go on board, when you switch to flight mode, when does the Wi-Fi turn on, and all of the corner cases that we just didn't know. We knew it was possible but we didn't know exactly how it was possible. So in order to prototype that, we did a POC, and now actually that POC is maturing into an actual feature and is also going to be released during this spring.

[00:19:21] But also this was a great exercise in this kind of approach in between teams, the mobile app team and the in-flight entertainment team. Of course that's one thing that we aim for as well: when we can do this type of between-team communication, that's something that we, and I guess in many big companies people, are lacking from time to time. The same I would say goes for the payment prototype that we showed you previously. We have used that to communicate with the payment team and our app team: what do we want, what is possible with you.

Tools, props and scenario scripts

[00:20:04] So, to wrap it up in a way, the prototyping tools that we use: mainly Axure, Sketch, paper and pen. Those are the top three definitely. Then others, we have this kind of rule or allowance that if you find a tool that works for you, use it. Many of us have just been introduced towards Axure. Principle was one of the ones bubbling under.

[00:20:47] Then upcoming, we are doing these scenario scripts and then props. What I mean by props, for instance, is that we are setting up this mock-up of our cabins, so for instance business class, and then we announced last fall that we were going to have a premium economy and an economy class. So it's a kind of set up for a prototype, to test prototypes in, so that we can test for instance the distance between screens, and what surroundings are you working our products in when on board.

[00:21:34] And then the scenario scripts for our crew. Like I said before, every flight is different, and we need to just see what are the situations, how can those be handled, what different ways are out there. So basically this means role playing, acting, and then doing a kind of reenactment prototype out of those, if you wish.

How the design team grew

[00:22:02] Then maybe setting the context now, at the end. Our design team at Finnair turns two years old tomorrow. I joined Finnair on the 27th of March two years ago, as did many of our designers and so did many of our in-house developers. We've been growing our in-house team during these two years consistently, and that also means that the prototyping process, or the work that we've been doing, all the processes have been, well, I started during that time. Before that Finnair had been mainly using externals or subcontractors, and prototypes have not exactly been part of the deal, in the sense that it's been more of this "I say you do this and you do this."

[00:23:03] We're now trying to train our business owners and stakeholders to do the kind of, that we need to evaluate, validate, and we can do it this way using these types of things. Actually you had design sprints on your list of methods, and that's a method that with few adaptations we've taken into use quite successfully, which is also where we produce a lot of prototypes during that time. This was actually from our first design team meeting ever. Nowadays we're 13 designers and growing. [?] And then, yeah, that's about it. Thank you.

Q&A

[00:23:56] Host: Thank you so much, Marja, really cool talk. Are there any questions? Right here. Thanks.

[00:24:05] Audience: One obvious prototyping tool for a designer would be to write code, front-end code. What are your views on that, and what are the biggest barriers maybe?

[00:24:16] Marja: Yeah, we do have a few designers who prefer to write code. I myself haven't trained that that much, I can do basic HTML stuff. But again, if you find a tool that works for you, then use it, and some of our designers are using it.

[00:24:33] Audience: Would that maybe sort of bridge the gap between design artifacts and actual development work?

[00:24:43] Marja: Yeah, might be. Of course there might be varied opinions, but I have felt that in Finnair, or in our teams, developers and designers are working pretty closely together. Well, Dan[?] might disagree. But basically, I don't feel that we have that big of a gap between designers and developers, and the prototypes are mainly used as communication tools in any case. Usually, for instance that prototype I showed you, I will modify them on the fly when we talk with the developer, so it kind of takes an equal amount of time, more or less, even sometimes, to get to that common understanding of what's possible.

[00:25:38] Audience: I was quite surprised, because I feel like an airline is pretty much a service business where you have so many interactions with your customers, so I was a bit surprised that you don't have like a service prototype where you prototype different types of service face to face. The reason for that is I just read a book called The Power of Moments and they mention the example of Southwest Airlines, who showed that there was a study according to which the safety announcement always being done in a very funny way had a huge impact on retention of customers, now people get back to Southwest Airlines. So have you tried out new things in the way you are servicing your customers?

[00:26:22] Marja: Yeah, that's a, we constantly are of course trying to get towards that point, and it's been actually mainly due to lack of resources, just manpower in that sense. But now at the beginning of this year we actually got a designer joining Finnair who is specifically oriented to this kind of service design, like scenarios and this kind of internal communication. So I hope that, and that was actually one of the reasons why I put the scenario and scripts there as well, this kind of maybe see what's out there to reenact and see. But yeah, none to this date that I know of.

[00:27:03] Host: Any other questions? We had something.

[00:27:15] Audience: Thanks for the presentation. Those Axure prototypes, how long did the process take to make, so a complex prototype?

[00:27:22] Marja: The Aurinkomatkat prototypes, I guess it's somewhere between, well, the one guy who was doing those is super, super, super efficient, so maybe for him it was like one day, but I know at least one of those was three days.

[00:27:45] Audience: Related to web components, based on web components, because in some cases Axure can be, it's a tool which can eat a lot of stuff. Comparing, if you have a good design system based on components, whatever, it could be faster than waiting on it.

[00:28:13] Marja: Yeah, I actually think Aurinkomatkat have the most mature design system of all of our teams, and I think they are actually now using those components in Axure, at least partly. So yeah, that's one of the reasons why they've chosen to continue with that.