An Unexpected Approach to Design: Uncovering Hidden Parallels With Writing Story Tales

Raphaël Vonthron at UXDX EMEA. Video: https://youtu.be/-Sm125jA27c

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.

Two long journeys

[00:00:00] Hello, everyone. It's great to be here. I would like first to thank Katherine and Rory for inviting me here. It's really an honor to be speaking in front of you. I'd also like to thank my team in Montpellier [?] at SLB for being online, and everyone online listening. My name is Raphaël. As he said, I'm coming from Montpellier [?], in the south of France, and I lead the research and design studio of a technology center inside the digital organization of SLB. SLB, for those who don't know what this company is, is about 100,000 people worldwide. We are working in the energy industry. We are a technology company, and we are driving innovation in the energy industry.

[00:00:51] The reason why I'm here today is because I wanted to share the outcome of two very long stories: a professional journey and a very personal journey. Something that took me 20 years to understand, to reveal a message and an insight that I wanted to share with you. The two projects that I'm going to refer to during this presentation are, first, a professional journey working on a product called Wellbore, which is a geoscience complex system in the energy industry, and a personal one: writing, composing, directing and producing a musical called Time City. What is the link between designing a complex system and writing a musical tale? Well, that's what you're going to find out.

What I mean by a complex system

[00:01:45] First, let me clarify what I mean by system. This is just my way of seeing systems, to simplify a little bit what they are. You have websites, which to me are very simple, in the sense that it's just pure information that you consume. You navigate as a user inside it, but the interactions are fairly limited. Then you have simple systems. These can be mobile applications, for instance, where you start having a bit more complex interactions. You can interact with somebody else, for instance. Then you have advanced systems, which are, for instance, PowerPoint or Word or Mural, these kinds of systems that are fairly simple to apprehend. They don't require advanced skills, and they help you generate data and generate content.

[00:02:32] Then you have complex systems, which are of a little different nature, because you don't just generate data, you also consume complex data, and they fall into the realm of professional domains. It can be the military, the energy industry, the music industry, the medical industry. I'm talking about this type of system that is made for professionals and requires advanced domain knowledge. An example, and actually an example that I started working with back in 2015 when I joined the Montpellier [?] Technology Center, is a product called Techlog that was built by the team over years and that still serves the energy industry. When I'm talking about a complex system, I'm talking about this kind of data: interpreting data.

[00:03:25] Beyond the complex system, there are platforms, which are a collection of systems, whatever their complexity, that live together and constitute, for instance, the Adobe suite or the Office suite. And the last level of complexity is, to me, what is called the ecosystem, where systems are working together and there is meaning associated with each one of them, where you want to serve something greater than just a collection of applications, because, for instance, data will be flowing from one application to another, and it's going to serve a greater journey.

[00:04:08] I showed you Techlog. Techlog is a complex system, and the journey that I'm going to reflect back on, on the professional side of things, is moving from Techlog to a product called Wellbore, which is a complex system that's not a desktop application, if you want. It's something on the web, using machine learning, artificial intelligence algorithms, etc., and of course completely changing the interface and the user's experience of it, and making it live in coexistence with other complex systems, with data flowing in and flowing out of the system and serving people in other domains.

Wellbore: from guidelines to personas and jobs

[00:04:50] That being said, how did I start? I started, when I joined the center, working as a user experience architect on guidelines. That was the quickest approach, I thought, or the best approach to take, given the knowledge, or the absence of knowledge, that I had around the domain. I took some user experience guiding principles and crafted them, went further, tried to understand the domain as well, and built up these very conceptual elements. And there was a problem. The problem is that it was difficult to sell these highly conceptual, user-experience-driven principles to the system and domain owners, people who were driving products and who had constraints, and who, I have to say, were also discovering the user experience journey, and design and research.

[00:05:53] What I did afterwards is I started digging much more to understand the vocabulary of these domain people, to go away from the conceptual world and dig into something more pragmatic. And this meant diving into the persona, of course. The step that I took after the persona was to dig into the job. You've probably heard of Clay Christensen and his famous video about jobs. It's a video that I watched a couple of years ago, and it really changed the paradigm of how I was approaching this entire big problem.

[00:06:37] Then I started diving into the jobs of the people I was supposed to be designing the experience for: the geoscientist. Geoscientist is a big word, a big name for a persona, but in reality a geoscientist is many, many different people. It can be a petrophysicist, a geologist, a drilling engineer, a fluid modeler, a geomechanicist. It's all about the subsurface, geoscience and subsurface interpretation: when we pull data from the subsurface of the earth, what sense can we make of it? And then I started digging into the jobs: why these people were doing these jobs and what the things were that they wanted to achieve, the little pieces of the puzzle that they had to complete so that their job was done.

[00:07:33] And what I discovered, what I unveiled, let's say, is their needs, their hidden needs. And it's not the needs that they were stating, "I need this," or the things that the domain owners would tell me. It's more needs that were analyzed and digested in a designed manner, let's say: things that could then be consumed by me as a designer to start crafting the system. And the needs, of course, are the jobs that are meant to be done. That's the first insight about that step in the journey: the essence of the persona lies in the clarity of the needs and the clarity of the job that they have to do.

Time City: from a dull story to its characters

[00:08:19] Now, that being said, I wanted to make a parallel with the process of writing Time City, because something very, very similar happened, and it's by reflecting back that I understood that it was extremely similar. First, just a few words about Time City, to understand what it's about and how it came about. It came in a different manner than Wellbore. With Wellbore, there was a business vision to reduce the time to achieve things by 20 times, and then it took me a few years to start crafting the vision of the system. With Time City, the vision was very quick. I was on a train, daydreaming, and I saw that scene in my head of statues awakening in front of a mansion. They would come down and start dancing an infernal ball. This image stayed, and then I used it and started writing.

[00:09:22] I actually took a picture of the very first version of the notes that I took to write the first version of the script, back in 2005 or 2006. As you can see, you have the beginning of a plan and you have elements of a universe, and it helped me start putting in place some concepts about the play, about the tale.

[00:09:47] And then there was a problem, a very similar problem to the one I faced with Wellbore. The problem was that the story was dull. The storyline seemed a bit forced, and it seemed a bit fake, in a sense. Things were happening, events after events, but meaning was not really there. It took me eight years of writing multiple versions of that script until I reached the point where I submitted the script to be read by other people, including a stage director, who told me, "I read it, and the first scene, I thought, yeah, that's what I want to produce. And then I kept on reading, and then something was wrong, and I couldn't really tell you why. But you know what, you should buy this book and read it." He told me about this book, which means dramaturgy [?], and then, exactly like for Wellbore, I started digging much more into the domain, the domain of writing.

[00:10:54] And then I discovered the narrative structure and what it means. What I first started working on, after I had dived into this, was the characters. The problem with my story initially was the fact that the characters were dull, and I did not understand them clearly enough. I started working on the archetypes, digging into the psychology. This is a picture of some files that I started working on afterwards, to craft my characters more deeply. You can see there: what's the desire, what's the archetype, what's the fascinating characteristic, what are the elements of the character that inherently make meaning and that the audience will be able to attach themselves to?

[00:11:53] And from there comes the parallel with Wellbore and the persona, which is that the essence of stories lies in internal and external conflict for the character. That's extremely important to understand, because when you have that triptych, where you build the character, and you work on the objectives of the character and their limits, then you start working on drama. That's when people start connecting with the story, and that's when meaning starts to happen, magically speaking.

[00:12:27] As a summary, and that's the initial touching point between Wellbore and Time City: it's critical to work on the archetypes first. When I worked on Wellbore, on the persona, it's something that many of you, I'm sure, have been doing because you were told to do so, and I had been doing that without really understanding why. But if you don't work on the archetype, if you don't nail the needs, the hidden needs, and you don't really, deeply understand them, there's no point in defining an experience, because you will not be able to understand the meaning that you want to create. Work on the archetype. Define their needs. Picture the initial situation, the present situation that they're in as the persona, or as the character at the beginning of the play. And then identify the problem that they have to overcome, the reason to build the product. Then you have the first elements to build something meaningful.

Getting stuck on the dashboard and on the scenes

[00:13:32] Now, once the archetype is nailed, once you've worked on that, for Wellbore what we started doing is design, and design starts with a storyboard or a user journey. This is an example of a user journey for Wellbore, where you can see steps, tasks and even screens that we were thinking about building to make sense of that journey. From the user journey, we started working, and as an architect I was also working on defining the information architecture that could then serve as the basis for building the navigation system of the application. The information architecture is very simple, and it's an old one. It evolved, it got simplified a bit, but still it's very simple. You have a list of projects. You enter inside a project, you have a dashboard, and then from the dashboard you explore the data, the information, and then you dive into the task that you want to do, into more complex elements, and then you complete the jobs that you want to do as a user.

[00:14:37] But there was a problem again, and this problem is the exact same problem that I faced with writing Time City. As we were working with the team to build the experience, working on the dashboard, on the list, etc., and trying to identify the elements of information that made sense, we were a bit stuck at some point. We didn't know how to prioritize or choose what type of information to put there. We could of course ask the users, "Hey, what do you need? What do you think of that? What would you like to have?" But I could see that in a way we were stuck, and we couldn't really progress up to the end.

[00:15:21] Now, the parallel with Time City. I have to explain a little bit about the purpose of the story so you understand why it changes everything. The story of Time City is a very complex story in its nature, because it's a cyclical story: at the end of the story, at the end of the show, you go back to the beginning, a little bit like in some movies. That's one constraint, an artistic constraint that I wanted to put in. But there's another one, which is much more complex. It's the story of one couple, two couples, three couples, four couples. One are the heroes, one are the antagonists, one are the challengers and one are the secondary characters, and they are all living the exact same story at different moments in time. The tale that is presented to the audience is just a quarter of the archetypal story, if you want. By the end of the story, each character has taken the next seat of the other one, and you have to have the aha moment at the end, so that it's the revelation. And these were huge constraints for writing the entire story.

[00:16:33] The reason why this is so important is because when I started trying to take these constraints into consideration and write the story, what I did is define the main steps of the story, dividing it into Acts 1, 2 and 3: what would be the scenes, what would be happening in the scenes. And there was a problem, exactly like I had with Wellbore. As I was writing the nth version of the script, I was stuck on some scenes, because despite the work I had done on the archetypes and the characters, there were scenes where the meaning that I wanted to weave through to the end was not really there.

Working backwards

[00:17:19] I changed my perspective and I did something, and that's the reason I wanted to give this talk in the first place: I started working backwards. What that means, for Wellbore, is that I worked with a colleague, Shen hi [?], and we worked together on a big whiteboard and then a Mural, and we went further inside the information architecture, staying at a high level, not diving too much into the details, but at least trying to understand exactly what the people using the system were supposed to do at the end of the information architecture. And from there I started designing backwards. I took the end of the information architecture and I started designing higher-fidelity elements.

[00:18:21] I'm going to take just one quick example of what it means in terms of information. If we take the last step, the furthest inside the information architecture, and we dive into it and design it, then we can have something like this, where there are information and data elements the user needs to do the QC, the quality check of the data. As an example, the thing highlighted here, the bad hole points, is a piece of data that the user needs to have so that they understand what they're working on. But it's something that is not only synthesizing information inside the rest of the screen; it's also information that makes sense to be elevated, redesigned just a little bit, to be included one step before in the information architecture. And then, as you dive, you aggregate other elements of the end complexity and build them up, aggregate them, to build meaning at a higher level in the information architecture.

[00:19:33] And guess what? Writing Time City, something very similar happened. This document is something that I was working on a few years ago, and I found it just two weeks ago or so. It's called Structure of the Scenes, and there's a nice parallel between structuring the screens and structuring the scenes. This document is kind of empty, besides the end and the beginning and a few elements in the middle. And I remember, when I worked on this document, I first worked on the end, the one that I highlighted at the bottom. What is interesting here is that I worked on the objective of the scene, the last one. I worked on the final situation, what's supposed to happen at the end, and on the initial situation of the scene. This means: what's the output, the job to be done? What's the input that enables the job to be done at that stage? And then I did the same for the beginning, because, due to the nature of Time City, the final situation was the beginning situation, and that's what I was trying to reach.

[00:20:47] What happened afterwards? Well, I worked backwards, scene before scene before scene, working on the output and the input of each scene and sewing together the meaning of each single character, each single story, making sure that from the beginning to the end, or from the end to the beginning, it made sense for each individual persona or character. And then the story was there. That's how it emerged. The parallel is: you roll backwards writing, you roll backwards designing the screens. And the message is: when you work on the structure, to ensure coherence and meaning, start with the end of the complexity, and then work backwards to the beginning of the experience.

[00:21:41] As a final word: work on the archetype, reveal the hidden needs, and then, when you work on the complexity, split it. Dive into one element of it, nail it, understand it, understand what makes sense and what needs to be aggregated and elevated. Assemble these elements to build the step in the journey before, and work backwards.

[00:22:15] There's a very simple image. When you enter your house, you enter the door, the entry door, and then you navigate the corridors, etc. The beginning of the experience is entering through the door. Well, when you build the house, you don't build the door first. There are other elements that you build before. It's this analogy, if you want.

[00:22:46] Both Wellbore and Time City helped me understand with clarity this very simple idea. I told you it took me 20 years to make this idea extremely clear in my head, and now I can use that concept to drive and guide the design of other complex systems. But at the core of it is defining the needs of your archetypes, the job to be done, and then the backward approach towards the beginning of the user's experience. And that's it. Oops. Thank you.

Q&A

[00:23:34] Host: Raphaël, just on storytelling: if people want to get into storytelling, what's the first step they should take?

[00:23:40] Raphaël: Sorry, can you say that again?

[00:23:42] Host: When people are looking to get into storytelling, what's the first step they should take? What do you think is the initial step if you want to start looking at that, if you want to start telling a story or writing a story?

[00:23:53] Raphaël: Writing a story, let's say. To write a story, you have to have an idea. You have to have an idea about something that you want to write about, something that motivates you. All authors, when they write something, reveal something about themselves somehow in the writing. That would be it.

[00:24:16] Host: Because I was thinking, what's the best piece of advice you'd give to people on how to reflect on their passion and then put that into their work? If they're really into a particular thing, how would they start bringing that into their work?

[00:24:37] Raphaël: Well, it depends on whether the passion is their job or not. The advice I would give is that it's probably better not to... Well, there are two schools. Some people will tell you to follow your passion and make your job out of your passion, and others will say keep your passion for another side of your life, so that you can feed your family and keep the passion for something that is not paid, so you don't get frustrated and you don't ruin your passion over time. I'm more in favor of the second one. And in this case, what was great is how the two passions, the one that I have for design and the one for writing, just came along together in that manner.

[00:25:26] Host: And let's say you're writing and putting together stories, etc. Do you find any particular tools useful? I'm always interested in what people use as a writing tool. Obviously you don't use Grammarly or something, there's no need for that at this point. But you were talking about your colleague, and you got together and started putting things together on the whiteboard. Is there a particular methodology that works for you?

[00:25:46] Raphaël: A methodology to write versus design, you mean? I used Word a lot. I used paper, actually. I think I used the same kind of general systems. It was a lot of paper: drawing, sketching. I took I don't know how many notes. I have many notebooks with drawings and notes, throughout all the versions. And it's the same in my job: how many screens I have designed and architected. I would first recommend doing that: putting what's in your head on paper first.

[00:26:24] Host: Paper, okay, cool. We'll take some of the questions from the audience. What did you use to design your fabulous slide deck? There we go, we're into tools again.

[00:26:32] Raphaël: Guess what? PowerPoint. It's all made with PowerPoint.

[00:26:45] Host: Okay, don't encourage him, don't encourage him.

[00:26:48] Raphaël: I don't know how to use Illustrator, but I know how to use PowerPoint. You can do vectorized images, and you can do rough things, but it's...

[00:26:58] Host: Okay, this is back to those tips again. How would you inspire stakeholders to work backwards?

[00:27:05] Raphaël: Well, first, what do you mean by stakeholders? Do you mean decision makers, or designers that I work with? Because these are two different people. Decision makers don't work backwards. They don't have to, because they guide. They set directions. But doing the work is more the role of the people who are crafting the experience. What I do today is work with the designers and the product owners, and I establish trust with them. It's the privilege of working with people who are beginning their journey in UX: they listen. It's easy to convey advice and to suggest how to start.

[00:27:59] Raphaël: When we design complex systems, and I'm thinking of a team working on geothermal, for instance, we have a really nice product that is being built by the team in Montpellier [?], where... it's another parallel that I didn't put here. The way we are designing the system is that we have a scene, and then the physical elements, such as panels, or navigating in the scene. We worked as if it were a physical environment, exactly like I designed Time City, staging the scenes as if the camera were going from one place to another, and having a physical coherence in things.

[00:28:39] Raphaël: And working with the designers, we know they have wonderful ideas, and putting all that together helps them. It helped me say, "Well, start with the end. Now you have all the information. You know exactly what to do on that screen at that stage, and then we can define what is really meaningful at that stage. And we can use that, and the same information at the other stages at the end of the information architecture, aggregate them, build the dashboard or the intermediate dashboard, and build the experience." And it's that confidence that is really useful, in the sense that I know it's fine not to know what's happening at the beginning of the experience. You can dive in and forget for a moment that the experience is not complete, but as you're nailing and understanding what needs to be done, you grow your confidence at the heart of it.

[00:29:32] Host: Okay, cool.

[00:29:34] Raphaël: It's a little bit like a tree. The way a tree grows, it doesn't grow from the leaves to the roots. It starts hidden, and then it expands little by little.

[00:29:46] Host: Okay. Where can we see Time City?

[00:29:50] Raphaël: Well, it will have to be produced again. But you can have a look: there is a trailer on YouTube. There are not many views, just a few hundred, probably the people who watched the show. But if you type "Time City musical" into YouTube, you'll see a two-minute trailer, so you'll have images of what we produced.

[00:30:16] Host: Okay, here's a really good one. How do you ensure that your end result isn't a biased result, a version which you prefer?

[00:30:24] Raphaël: Which product are you talking about, the tale or the system?

[00:30:32] Host: You just pick one. Go for it. They're not talking, they're too... sorry.

[00:30:37] Raphaël: And what do you mean by biased result? Who wrote the question?

[00:30:51] Host: Oh, you're not going to hear from them. No, it's fine.

[00:30:53] Raphaël: I just want to understand what you mean by bias here, biased results.

[00:31:00] Host: No, no, we'll move on to the next one. That's good. Okay: can you explain how you prioritize persona needs?

[00:31:12] Raphaël: Well, what I've learned, and I don't know if it's the complete truth or not, is that when we design a system there's a primary persona. Sometimes there are others, there are secondary personas, but there's always a primary persona who you design the system for. The way you prioritize the needs is that you do research, you do a collection of interviews, then you aggregate the results, you identify your insights, and that's how you prioritize things. You understand from their job that there are things that are emerging much more than others. For instance, with the petrophysicists, what I understood is that they first need to have their input cleaned, the gamma ray, the resistivity, some basic input, and that they need to generate outputs. This emerged and was clear. The other things in their needs were secondary, exporting or collaborating or these kinds of things. It doesn't mean they're not important, but they come afterwards in importance, in how I can decide what makes sense to craft the system.

[00:32:27] Host: Okay, and that's where I think we're going to have to call it. We've run out of time. Raphaël, really appreciate it. Put your hands together for Raphaël, and we thank you.