Purposeful Prototyping

Oscar Nilsson at UXDX Community: Stockholm. Video: https://youtu.be/ueanfQXFtLo

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.

Prototyping at Minecraft

[00:00:09] Yes, my name is Oscar, and I work at Minecraft, as mentioned. Today I'm going to talk about prototyping, and especially being mindful about the effort that you put into prototyping. I'm also going to wrap it in a little bit of a team and organizational context: how can you be more collaborative, smooth out the kinks of building really cool prototypes, and make cool design happen because of that?

[00:00:41] Okay, so Minecraft, as mentioned, is a super popular game, and quite recently we started up a UX initiative, a team that solely focuses on the user interfaces, the UIs that let the user accomplish all of the things in the Minecraft world. One of the biggest challenges, just to give you some context, is that Minecraft is on basically every platform you can imagine. It's on PCs, obviously, but it's on basically all consoles, it's in VR, any kind of touch platform you can think of, Apple TV. I could go on. We are a widespread game, and from an interaction design standpoint, there are lots of different input methods we're working with, and screen sizes of course.

[00:01:42] Also, the thesis was mentioned. I am actually doing research into prototyping methods, and this summer I will try to publish a set of cards, 25 strategies for scaling Perth [?]... I've been working in design things [?], so look out for that. Oh yeah, I should also mention I was going to near [?] before, but now I'm doing the same. Right, so prototyping. Why is this an activity that you might need to be mindful about doing?

[00:02:16] Let's actually start here. What's a prototype? When it comes to proper definitions, it's a bit rough, but it's something that comes before a final thing, in the most general sense. But in UX design, I think you can say that this is pretty much the definition: it's what goes after you've made a mockup. You've drawn the UI, but you still want to keep investing in the design artifacts to make a fuller articulation of your design.

[00:02:58] What I've observed with the situation is that more and more, we've started to put more weight into this prototyping part of our work, because it's turned out to be beneficial. To contextualize this a little bit more, I like to show this quote. It's from an American architect, and I think it's a really cool quote to go back to: you can use an eraser on the drafting table or a sledgehammer on the construction site.

Mixing up the drafting table and the construction site

[00:03:47] What I think is happening, when we are investing more and more into building really complex prototypes, is that we are starting to mix up what is the drafting table and what is the construction site. Oh, we've got some delays here with the thing. That's fine. You're just going to have to see these words again. Maybe I need to stand here. Right, we're mixing this up.

[00:04:29] If we go back, this is an activity that you are familiar with: wireframing, perhaps using Balsamiq mockups like this, or actually drawing UIs. But what I've seen is that this is getting less attention, and less of the overall design process is spent in this phase. Instead, we're starting to work these really complex prototyping apps into our workflows, like Origami, for example, something I use a lot, or Framer, where you actually write code to build prototypes.

[00:05:11] The things that you create with these apps are amazing. They're masterpieces of showing design. Just pulling some examples from the websites of these apps, you can build 360 viewers and amazing animations and transitions. For designers, this stuff is crack, basically. You're having a field day with these tools, because you're not spending that much effort, but you're getting really rich artifacts out of it.

[00:05:53] But what I want to dive into a little bit, through these three lenses, is how this affects the overall collaboration workflow in teams, and the flexibility of moving ideas until they actually ship to the end user. These are the lenses that I usually bring up when it comes to prototyping, but today, since it's UXDX, I can actually spend a little bit more time on these two.

Prototyping as a tool for collaboration

[00:06:28] Okay, so let's dive into collaboration: prototyping as a tool for collaboration. I guess most of you will agree that projects tend to move in this direction. You start out with some kind of user need, or some kind of thing that the design part of the team takes care of, to process and figure out the features that we actually need. Then it moves on to more of a technology side, where code actually gets coded and shipped to users.

[00:07:04] I like to map this on a graph. Sorry, I know it's late, but we're going to do some graph things here. On the y-axis, we're going to look at the fidelity of the things that are built, and then there's the project time here. What usually happens is that the design team looks into the requirements for the feature, and they start building their artifacts for representing the design. Then there's a handoff. This is a generalization, but generally projects, at least from my experience, move with this kind of trend. And then similarly, the engineering team starts building towards a similar fidelity of artifact.

[00:08:11] What tends to happen, again from my experience, is that some of the effort that was put into the design artifacts doesn't make it to the end users, because of scope and things like that. With this kind of graph, I think you can start looking for optimizations you can make to perhaps make your workflow a bit more efficient. Oh, I should actually explain before we move on: we have an engineering team that might not be able to start working until we have the specification completed.

[00:09:02] One thing that we started working with when it comes to designing Minecraft is to make, there we go, wireframe prototypes. We have one here. This is a prototype that captures all the navigation, the interactions and the flows, but it's completely lacking when it comes to visual fidelity. We've started to realize that these kinds of prototypes can work really well as an initial specification when it comes to communicating what we want to do to the more technical folks on our teams.

[00:10:01] What we get from these when it comes to specification is not the UI details, but the navigation, the data flows, the input and output methods, perhaps when we need to do requests, or complex transitions between screens, stuff like that. We can spec that out with this style of artifact, and that's actually a really good starting point for the front-end architecture if you want to build something like that. Yeah, and I'm just on a roll and accidentally skipped past it. Okay. It's just trying to capture as much interaction and flow as possible, the complexity of the structure, and strip away all the visual details. Then maybe something like this can happen: we can have an earlier handoff, and the engineering side of our team can start working earlier.

Designing with code

[00:11:02] Another thing that I want to look into is: what if designers could spend this effort up here, the effort that never actually ships, in a more efficient way that produces value for what's released? How should you spend your time better when it comes to that extra bit of polish that is at risk of not shipping? This is a problematic topic, I think, but: design with code. I'm fully in support of not becoming a software engineer as a designer; you have enough stuff to do. But when it comes to finding optimizations between teams, I think there are things to look at here that are really interesting.

[00:12:03] One thing could be, if you're using a front-end architecture on the web like React, that tools have started to pop up that pull parts of an app out of the overall workflow of the engineer and present them in tools that are more suitable for designers to tweak the design. We've got Compositor.io [?]. Another one is Storybook, which is actually pretty... it's a library of components in an isolated tool that lets you tweak design aspects, perhaps with more confidence, since it's not in the entire engineering workflow when it comes to shipping the code. So, tools like that.

[00:13:01] Also, implementation-considered prototyping. When you're working in these big prototyping tools, there are a couple of things to think about. This is rapid-fire. If you can work with a tool that supports state logic instead of timeline editing of things like animations, maybe that can be a bit closer to what's actually going to be implemented. I'm speaking a bit from experience here. Also, if you can use API data in your prototypes, maybe you can hit some of those constraints that you would have been hit by from engineers later in the process, if you can just give your prototyping tool the link to the API, which tools like Framer support.

[00:13:54] And also, if you invest some effort into building either symbols in Sketch or components in Origami, for example, I think that gets you in the mindset of building components that capture more of the constraints that are actually going to be there when you're implementing the designs. Things like these optimization tricks lead to handoffs that are easier for everyone, in my experience. And maybe we can end up with something more like this, where it's not separate processes but more like teams working together, and understanding what the challenges are right up until something is shipped to the end user.

Building vision with prototypes

[00:14:52] A couple more points about building vision with prototypes, because this is another topic that I think is really needed. You're not always defining things for an engineering team that should build something. Maybe you don't have any technology already, but you need to convince, perhaps, a venture capitalist. It could be roadmap planning, or you could have a client, or a customer that you want to sign up for your product. Maybe you just need to show something really engaging that looks really sweet, because you need to become friends with someone, basically. I think there's space for that too, stepping away from the technology aspects and just being visionary.

[00:15:48] I like to compare that a bit with this. Perhaps you know what this is from: a Trojan horse. What I want to bring up here is that there are two parts to a plan like this. You're presenting something really nice, and this needs to convince people, but that's not all of it. You need to have a second part of your plan, which is to ship it. You need to deliver something that also works. Having the awareness that these two parts come together is really important, I think. So despite taking on visionary prototypes, you need to know that you should follow through and ship something. Hopefully not an army of soldiers, but you get the point.

[00:16:52] Another thing I really like to advocate for is really thin slices when it comes to prototypes. Don't build the entire thing; just find the part that speaks most to what you're trying to solve. This is a really cool example from Apple's latest iPhone. This is just a video. It doesn't look like an app. There's no onboarding, there are no UI elements, but it really captures the value, the user value basically, and why this product should exist. That's something to keep in mind, I think, when building prototypes for that visionary purpose.

[00:17:44] A bit of a summary: prototype what makes sense for your specific purpose, and try to find what your purpose is. Is it to collaborate well with an engineering team? Is it to present a vision? Is it to do a user test? Try to identify that before you dive in and spend all this effort in these really cool tools that we've now got. And yeah.