VR Design Process – Google I/O 2016

afternoon, Google I/O! AUDIENCE: Woo! ROB JAGNOW: Woo! I did not expect that
a talk on process would fill a room
with a capacity of 300 with a line of people
waiting outside. I am Rob. I hope you’ve been enjoying
the VR sessions at Google I/O. Together with
Michael and Anshuman, we’re going to be talking
about VR design process. I know it sounds
so exciting, right? We hope that this
is a talk with a lot of practical advice for
turning dreams into reality. So the talk is broken into
three different sections, each focusing on a different
set of practical advice that we hope will be useful for
anyone who is doing VR design. Within the Daydream
team, we use two separate but complementary
design processes. Each one takes a
different approach but helps us serve
different needs. And the first one that
I’ll be talking about is our rapid
prototyping process. It helps us explore
terrain quickly, finding promising use cases,
and testing a lot of ideas without wasting too much time
on a highly structured process. We refer to the projects
that fall into this category as Daydream Labs. After that, Michael’s
going to come to the stage, and he’s going to be talking
about our second process, a robust iterative
design flow that we use for building mature apps. He’ll walk through
the specific process that his team used in building
our Daydream Home world. And to conclude
the talk, Anshuman is going to come up and talk
about an even more fundamental challenge that
you’re going to face when making VR app’s, which
is building your design team. So to give you an idea of
where I’m going today– oh, oh, before I talk
about rapid prototyping, I want to take a
little bit of a step back to consider
where VR is today and why we chose to
put this talk together in the first place. So to give you an idea of
where VR design is today, let’s talk about
platforms that most of us are more familiar
with, mobile and web. In terms of things
like hardware design patterns in the computational
power that’s available to us, virtual reality
feels a little bit like designing for
the web in the ’90s. So to target the
mid-range hardware, we had to design web pages
for monitors that had no more than 800 pixels across. Design patterns
were just emerging. So we used things
like the table element to outline everything
on our page. Because it was really
all that we had. And keep load time
short, we had to worry about really simple
things like image sizes. Like even something
like a transparent PNG could just totally
waste your download times. So with VR in its
nascent stage, we’re again having to pay very
close attention to these three aspects. But unlike web or mobile,
which took decades to mature, we really do believe that VR
is set to mature much faster. For one thing, VR is
a very open platform. And basically from day one it’s
open to third-party developers. Also, it already has this
huge generous community. And, in fact, I
recognize some faces in this audience from
community members who have already been
very generous with VR. And also, the underlying
technology and workloads are rapidly maturing. I think that this conference
is an example of that. We’re doing several talks
on VR design process. So this is really
promising as a designer. But there are still going
to be a lot of challenges for VR design. Basically it’s like
everything is new. So first of all, UI
standards and design patterns are just starting to take shape. And like I said, this
is one of several talks we’re going to be sharing
our best practices. And without the help of these
established design patterns, we need a lot more explorations
to find ideas worth pursuing. And once we’ve
isolated a good idea, we need a lot more iteration
to turn that idea, that gem, into a finished product. So due both to the
number of iterations required and the number
of disciplines and tools involved, we take more
time and more iterations to create a great VR
experience, compared with other digital media. So number two, head
mounted displays, or HMDs, these have their own
unique design concerns that we’ve never really
had to deal with before. So for one thing,
VR devices they obviously occlude the
real world from us. And this forces us
to pay attention to things like user safety
as well as physical comfort and also psychological
comfort of the space that we’ve created for you. Next, we have to consider
totally new methods of interacting with
our digital worlds. Now even with the
early stages of VR, we’ve seen a lot
of different ways to use controllers
to track your hands, or to use something like
vision to track our hands, to make our worlds interactive. So with all of
this put together, the new hardware
and design patterns mean that anyone
working in VR is going to need to become familiar
with a whole new set of skills, a whole new set of tools, a
whole new set of workflows. For instance, game design
engines, or game engines, have become an invaluable
part of our toolkit. Right? Who would have guessed this? And later in the talk,
Micheal and Anshuman are going to dig into the
specifics of the skills that are used for VR design. Now since we’re working with
all these new tools, and skills, and workflows,
sometimes this means we need to build a new team. Sometimes the skills
that we’re looking for aren’t satisfied by the
people on our current team. So we need all these
members who can fill the multitude of niches
used to create a successful VR product. So all of this combined forced
us to develop a new design process that allows
us to move quickly to develop magical
experiences for users and keep them safe
and comfortable. So now that you have a better
feel for the challenges that we face as designers,
let’s kind of launch into our first big topic. So this is the rapid
prototyping framework that we’re using
for Daydream Labs. This was talked a little
bit about more this morning. There was a 10:00
talk this morning about the findings
in Daydream Labs. So for decades,
science fiction has fed us these ideas
about what might be possible in a future in VR. Some of these ideas
hold real promise. But others, as it turns
out, when we actually code them up and
experience them, either they’re a little
underwhelming or the hardware just isn’t there yet. So the nice thing is that
with rapid prototyping we can cover a huge amount
of unexplored territory in a very short time, finding
unexpected gems, and just as importantly, taking
these ideas that just aren’t compelling or where the
hardware isn’t ready, and setting those
aside for later. So the process that I’m
going to talk about today has been refined by
a small team that’s built more than 60 VR prototypes
in less than a year’s time. We work in teams of two. And we generally aim to release
about one prototype per week. That’s the goal. The teams are, broadly speaking,
composed of one designer and one programmer. Although we’re
really generalists with quite a broad array of
kind of light skill sets. And Anshuman is
going to be talking about more of that in his
section about building a team. The projects that we choose span
a huge breadth of categories. Some are really small
and self-contained like figuring out what makes
for a comfortable reading experience. What size of text
you should have. How bright should
the background be? How much contrast do you need? Others are bigger
and more futureful, like creating a system
for authoring and editing layered animations
on a timeline. So to help describe this
rapid prototyping process that we’re using within
the Daydream team, I’m going to break it down into
these five different steps, brainstorming ideas,
ranking those ideas, implementing them,
sharing the results, and documenting the findings. So let’s start with
our first step, brainstorming these ideas. So let’s say you
and your team have decided you want to make
a gajillion VR prototypes. Where do you even
go for those ideas? Good news here,
everyone has an opinion on what would be awesome in VR. Go to that relative
of yours who is like super bad with computers. They have an opinion on
what they want to see in VR. I promise you. Getting input from a diverse
team is a really huge help. If you have a team with
a breadth of interests and a breadth of
experiences, that’s going to yield a breadth of
interesting concepts for you to work on. So as you’re thinking
of these ideas, here are some creative
exercises to go through. When possible, don’t
be incremental. There’s no need to do that
for these kinds of prototypes. Throw away all the assumptions
and start from the ground up. The best new VR experiences
aren’t going to be derivatives. They’re not going
to be something that you’ve seen in another
media platform just transferred over to VR. They’re going to rethink
everything and be cognizant of the strengths and weaknesses
of VR in its current form. Next it’s really
easy to be literal. People love playing
with kittens. Let’s make a VR space where
you play with kittens. Like this is virtual
reality, people. We don’t need to be
constrained by the familiar. So let’s make a world where
you use your trebuchet to launch giant stuffed animals
that are fetched by your t-Rex. Right? Prototypes are a really
great place to crank it to 11 and just see what happens. You don’t know how far you can
go until you’ve gone too far. Next, constraints are good. Now this is a really weird one. And I want to dig into
this a little bit. You don’t want to over
specify the implementation details for a team that’s
working on a project. But you do want to work with
challenging constraints. So I think this quote
from Russian composer Igor Stravinsky is useful. He said, the more
constraints one imposes, the more one frees oneself. And the arbitrariness
of the constraint serves only to obtain
precision of execution. So this seems really strange. To kind of frame
this, let me give you an example of a bad constraint
vs. A good constraint. A bad constraint
might be something like, you have a
team of 50 designers, and you put this task
out to them and you say. create a classic
board game in VR that feels exactly
like the original. The problem with this is
that it doesn’t leave room for creative interpretation. So if you give this
task to 50 designers, you end up with 50
versions of checkers in VR. So let’s turn this
into a good constraint. Let’s say you understand
the strength of VR. You want a game for
two players that really leverages those strengths. So let’s say, the players
have to face each other. That it shouldn’t just
be a tabletop game. That you want the
playing space to exist between the players
in such a way that both players can
interact with that space. And finally, it
should be a game space that would be impossible
to create in real life. Now these are constraints
where there’s an enormous room for creative interpretation. And I promise you that if
you give this task to 50 different developers,
you’re going to get 50 different totally
awesome and unique games. Step two is ranking those ideas. So just because you’re
pursuing a lot of ideas doesn’t mean you can just skip
the process of filtering them. And to give you an
example of this, even though my team has created
more than 60 prototypes, we’ve got way more than 100 in
the queue waiting to be done. And at this point,
in fact, ideas are coming in to
us from other teams faster than we can process them. So you need some
way of choosing what the most promising ideas are. To do this, we pick
a set of criteria that helps us evaluate and
stack rank all of those ideas. Now your team might have
a totally different set of criteria. But these are some
examples of ones that we found have been useful for us. First of all, try to think of
ideas that are better or maybe even only possible
in virtual reality, ideally something that’s
never been done before, something that has potential
for real wow factor, something that’s a
good fit for your team. And what’s a good
fit for your team isn’t necessarily a good
fit for every other team. What are you passionate about? What are your skills
that you can leverage to make a great VR experience? Pick something you can
scope for a one week sprint. And if the idea seems too
big, think really strongly about what’s your hypothesis
that you want to test? How can you pare that big
idea down into something a little bit more atomic? Finally, this isn’t going
to be for everybody. But for us, we’re
looking at ideas that are more than just
pure entertainment. We know– for those of you
who are in the game industry, you guys are going to
make awesome stuff. We know that for sure. But we are kind of interested
in education and productivity. We think that there are
a lot of areas in VR that are just not
even touched yet, lots of room for opportunity. So this takes us to step
three, implementation. This is kind of the meat
of the product here. And as I mentioned before
aim is for each team of two to finish a prototype in a week. But those prototypes
aren’t going to be useful if we don’t go on
to steps four and five, which are sharing in documentation. And that takes time too. So realistically we’ve got
like three to four days at most to spend on implementation. And we’re doing this
week after week. So we hear this a lot and I am
going to be perfectly honest. I was the guy who is really
pushing for these one week turnaround things partly
because I love game jams. But I was worried. I knew that this was
going to be a problem. So let’s put this
in perspective. Who here has ever attended a
game jam or a hackathon before? That is a really good
number, more than I expected. So an on site game jam
usually last 48 hours. And if you’re not familiar
with them, if you haven’t been, they are a totally
amazing experience. They let you take a break
from your regular work and create a playable,
complete game in a weekend. And this is super empowering. It’s like a total
palate cleanser. So I have attended
about a dozen game jams. And I’m often teamed up
with people who have never made games before, of
varying levels of experience, and I have always had a working
game at the end of two days. So for prototyping,
you need to think about targeting the same scope
that you would think about for a game jam, something
that you could do in two days. When you take that scope
and you stretch it out over five days, all of a sudden
it doesn’t feel so daunting anymore. It seems a little
bit more realistic. Now the other thing is
that, in the old days, like three five years ago,
we didn’t have amazing game engines that are super
accessible, and easy to use, and cheap. So it was really hard
to get your hands on something that would let
you get a good head start. So when I would go to game
jams, I had to make games from scratch like from C++ or C#. We had a scope much smaller. So today, we have these
amazing game engines that accelerate the development. We can do a lot more
in a lot less time. Also, each of these game
engines has an asset store, which is an amazing place
for quick placeholder art. And some of the
stuff is really good. So like, let’s say I
need my dinosaur model for my trebuchet
stuffed animal fetching game, boom, like $2,
five-starred, modeled, textured, skinned,
animated, everything. You still have to be careful. Knowing that you have all
these things at your hands doesn’t mean that you
can get overly ambitious. You still need to keep it small. Think about what the absolute
minimum is that you need to do to test your hypothesis. So some of you, especially who
are from around Silicon Valley, are thinking, OK I got it. MVP, minimum viable product,
I know what I need to create. Smaller, like way smaller, than
your minimum viable product, you want an experience
that’s just enough that you can walk another user through
them while you’re escorting them and say, don’t
press that button because it’s going
to break everything. That’s OK. It’s enough to test
your hypothesis. So another thing to be
wary of is nerd sniping. I borrowed this term, nerd
sniping from an xkcd comic. If you don’t know it, I
recommend you look it up. It’s what happens when you’re
presented with a problem that’s just too fun and interesting
for your brain to say no. On one hand, your desire
to tackle these problems is what makes you a great
designer or engineer. On the other hand,
the problem comes when these fun interesting
sub-problems that aren’t really essential pull you
away from your core objective. So if you’ve already
been completely distracted by this slide up
here, then congratulations. You’ve been nerds sniped. And if you’re thinking about
how you might design a framework to solve general problems
of this category, Google.com/careers. So let me give you a realistic
example of nerd sniping. Let’s say you’re filling
a world with a huge number of random objects. And so what you’re doing is
you’re randomly coloring them just by picking like a
random red, a random green, a random blue. Got your RGB color. And then you think, you know,
this is kind of ugly actually. And by applying just a
little bit of color theory, I can make colors that
are visually distinct, but that look good in
a palette together. You know, how much time
could that possibly take? And the answer is,
it doesn’t matter. This is just distraction from
your core objective, which is testing some other
hypothesis that has nothing to do with color theory. When you graduate that idea
from your one-week prototype into a full fledged
product, then you can talk about those
sorts of features. And Michael’s going to talk
about that process a little bit later. And if you’re still wondering
about this nerd sniping, and you’ve been obsessing
over this the whole time. The answer is 14 seconds. So the next step is sharing. There is no sense in
building prototypes that nobody else
is going to see, which is why we’re
so excited to finally be sharing so many of
these prototypes with you here at Google I/O.
And what you need to do is have sharing
built into your schedule. So what we do is have what we
call a demo party every Monday afternoon, where we invite
our team members to come by and check out what we’ve done. We also invite everyone
who attends these demo parties to leave at
least one sticky note that says something they
hate, something they love, some feature that this makes
them think of that they would like to see in the future. Doesn’t really matter
as long as they give some piece of feedback. Also, these live
demos have really helped validate the whole
prototyping process. Having these small prototypes
doesn’t just ease development. These little
bite-size prototypes also seem to get the most
useful feedback, which has been interesting. So this is a quote from one
of the members of my team. He said, you build the
tip of the iceberg, and people will come to
you and describe the rest. And here’s what we’re finding
is that, if you show users a polished product, the
feedback on that product focuses on things
like subtleties of an animation or the color
palette that you’ve used. They focus on the polish
of the product itself. Whereas, when you give them
something that’s clearly a prototype, a work in
progress, or a vertical slice, users tend to give
high level feedback. They talk to you about features. It seems like something that’s
more malleable in their minds. And so they give
feedback related to that. You can also think
of these prototypes from the perspective
of diminishing returns. Maybe in a week you
can create something that feels like it’s
maybe like 80% complete. If you spent another
week on that thing, it might feel more
like 90% complete. And we find that having twice
as many 80% complete prototypes gives us a lot more
information than those 90% complete prototypes. All right, documentation–
I know it’s not a fun word to see on a slide. But it’s a really important
step in the process. Because if you don’t
document what you’ve learned, again, it’s really hard
for you to have an impact with these prototypes. Now, you don’t want to get
bogged down with documentation at the very start
of the process, like with a heavy
handed design document. But if you’re not
documenting at the end, all these things are just
going into the ether. You need for these projects
to have impact and results. So for each prototype, we
capture a 30 second video. We make a short animated GIF. We summarize our
findings that came to us on all these sticky notes. We send that out on email. And some of these prototypes
are more fruitful than others. But we have never
had a prototype where we didn’t learn anything. In fact, sometimes
our findings are completely unrelated
to the thing that we thought we were testing. So I’ve got to admit it. I lied a little bit. I gave you this really nice
clean five step process that you can follow,
which looks nothing like the reality of what we do. What we do is way messier. So while we do, in fact, try to
have a demo party every Monday. There’s no real clear boundary
from where one process ends and the next process begins. At any given time we’re wrapping
up ideas on a previous project. We’re working on a next project. And we’re thinking about
ideas for future projects. So I want to give you a
little bit more realistic peek into what the process
actually looks like. So this is a week in
the life of the Daydream team making Daydream Labs. So we start on Monday. For the previous week’s party,
or previous weeks project, we’re having our demo party to
show off the prototype of what we’ve made. We’re capturing
the video of that, maybe with some users
interacting with it, zipping up the project
for sharing the code or sharing the build. For the current
week’s project then, we’re selecting a new idea. We’re restricting its scope. We’re looking at our various
tech options, implementation options, what hardware
we’re going to implement on. For the three days in
the middle of our work week, we are still
summarizing and sharing the findings from
the previous project. For this week’s project we get
our first prototype working. And then we rethink. Like maybe we’re going
about it the wrong way. Maybe we’re testing
the wrong thing. Maybe we need to be asking
different questions. So we recalibrate. We rescope. We look at our
different features. We iterate on our core design. We’re also spending this
time during the middle of the week reaching out to
members from other teams. Because that’s where a lot
of our ideas are coming from. Friday we’re wrapping up the
project for the current week, applying as much polish
as we have time for, and narrowing down our list of
ideas for the following week. So with this schedule,
that basically looks and feels like
a permanent game jam, which I think is awesome. But you really have to think,
how do you prevent burnout with this constantly jamming? The first thing I’ve already
said, scope for two days and stretch that out to five. Remember that you’re
not just implementing. You Also need to save time
for sharing, documenting, and preparing for
future prototypes. But burnout can be caused by
other things like bureaucracy, or fighting an uphill battle,
or having too many meetings. As much as possible, try
to structure your process so that these just
don’t get in the way. And I’m not going to
pretend that this is easy. It will help if you can
block time in your calendar, thinking about
each of those five distinct steps of the process. Some tips for
management, if you’re managing a team that’s doing
this kind of prototyping, there’s a place for passion. And if your team is
really passionate about a particular idea, even
if it seems like that idea might not be the perfect fit for
the agenda that your after, let them go with it. Passion can go a long way. Now there are other
dimensions of burnout, like creative drought. We were really
worried about this. We thought we’d pick
all the low hanging fruit in the first
month, and we’d be done. This totally hasn’t
happened as it turns out. There are so many
ideas to pursue in VR. There is so much
unexplored territory. We started with a
lot of our own ideas. But like I mentioned,
other teams keep coming to us with
new ideas all the time. And if this does
become a problem, revisit those creative
exercises that I listed earlier. Ask other people for ideas. Try to constrain yourself
to think up ideas, particularly in
unexplored spaces in VR. OK, so wow, 60 prototypes,
you probably want to know when are you going to
see all these prototypes? I’m not going to tell you,
but only because there was a talk earlier this morning
that showed the findings from these prototypes. I’ve been told it’s
already on YouTube. So go and search for that. The topic is called
“Daydream Labs, Lessons Learned from VR Prototyping.” And hopefully, just
looking through those will really help
spark some big ideas. But for now, rather than
talking about findings, were going to go back and
focus on the design process. I’d like to introduce
Michael to the stage. He’s going to talk about
a completely different but parallel design process. So while my team is looking
at finding these gems and seeing what’s
interesting in VR, it’s up to Michael’s
team to take these ideas and polish them into a robust,
beautiful, safe products. Michael. [APPLAUSE] MICHAEL ISHIGAKI:
Thank you, Rob. Hi, I’m Michael. I’m a designer and prototyper
on the Daydream team. As you might have learned in
earlier talks, designing for VR is unlike designing
for any other platform. For starters, user
behavior is very different. For example, your smartphone
is largely an auxiliary device. It’s best for short,
frequent user sessions. But for VR, we have been
observing session lengths of more than 30 minutes,
with users spending even more time in higher quality content. Furthermore, since
VR is immersive, use cases are very different. Snackable experiences are
much less attractive in VR. Premium experiences are king. The process Rob shared is
a great way of exploring the strengths of
VR as a platform and will give you insights
into the users for whom you’re designing and the use
cases you’re fulfilling. Using the gems and insights
gained from the Daydream Labs process, how do we move forward
with designing a product from sketches to launch? I’ll be giving
you an inside look at how this process
worked for us as we designed Daydream Home. Part of what makes designing
for VR so difficult is that there are a multitude
of new job functions. And within each function,
there are many new skills. There are also a ton of
new design considerations. With all of these
factors and unknowns, how do we progress forward
without getting stuck? While we were working
on Daydream Home, we quickly realized
that the process we were accustomed to following
simply wouldn’t work for us. And like many others,
we first started out trying to use the tools that
were familiar to us, Photoshop, Sketch. However, when we finally
got our designs into VR, we realized that they
simply didn’t work. They were flat. The scale was off. And the whole thing was a
little bit underwhelming. The new VR specific
design considerations were much more impactful than
we had previously thought. And so we developed this
new process with a focus on getting into VR as
quickly as possible. This new process
helped us design VR first 3D user interfaces that
felt native for the platform. They were immediately more
inspiring than the UIs that we are designing
with our past approach. And by getting into VR
sooner during the process, we were able to avoid
false positives. Issues with scale,
abstraction, and comfort were easily avoided. For example, we
briefly considered the idea of annotating
virtual objects with captions. If you mock this out in
2D, it works perfectly. But the second you
get it into VR, the whole idea
completely falls apart. So what do we mean by getting
into VR as quickly as possible? Since VR project needs will
differ greatly from project to project, I’ll be sharing how
the process worked for our team as we designed Daydream Home. Here’s a rough diagram of the
Daydream Home design flow. This is in no way prescriptive. This process
unraveled organically as needs changed from one
iteration to the next. And as you can see,
the process was flowing from interaction design. When I say interaction
design, I include prototyping. The two are inseparable in VR. For other apps it
might not be the case that interaction design
leads the design process. For example, some games
might be entirely driven by environment design. But for us, the
different project needs branched out
from the progress that the interaction
design team was making. The process helped
us also develop a really healthy,
positive feedback loop. Before we started jumping into
VR as quickly as possible, we often found ourselves
stuck in meeting rooms arguing about what is the
best design solution. We quickly found that you
cannot validate a design one way or the other without
first prototyping it. So let’s begin with the first
iteration of interaction design. Knowing what users
we were designing for and what use cases
we were targeting, we began our design
process much as we would on web or mobile, with
information architecture design. This gave us a
framework on which to build, ensuring that our
work would meet product goals and enable the end-to-end
flows that our users would hope to accomplish. Next, we dive into the
lowest fidelity of our design process, hand sketching. Hand sketching is the only 2D
stage of our UI design process. We first tried creating
mock ups with applications like Photoshop. But we found it simply wasn’t
worth the time and effort. Hand sketching is the easiest
way to draw out your 3D ideas. It’s also the easiest way
to share with your teammates what’s in your imagination
and to add on and build off of each other sketches. Our next stage is what we
call volumetric layouting. In this stage we pull
up our game engine, and we start placing and scaling
primitive objects like cubes to roughly match our
favorite hand sketches. While we do this,
we repeatedly check to see what it looks like in VR. During this stage,
we get a sense of how our design
plays out spatially. We can score, validate, and
build off of our sketches with a better sense of scale,
eye travel, head movement and more. We instantly start
getting more ideas about how we can design in more
exciting ways that are only possible in VR. With a very rough layout, we
start adding in UI objects like text, images, and
interactive elements. We’re careful to keep
viewing our work in VR so that we can properly
validate our design. For example, this image
is just a flat render of the volumetric layout. In VR the layout has a
very nice looking depth. But VR also has a
much smaller field of view and
significant distortion. It looks something a
little bit more like this. In this case, we find that we
have overestimated the screen capabilities of the device. These discovery posters
don’t afford enough space for legible text. If we designed this
in 2D, we would have never caught these issues. Attempting to solve
this, we experiment more with positioning in zSpace. Orienting the contents of
the UI around a cylinder help keep text legible,
reduce distortion, and add interest to the design. While this wasn’t enough
to fix our text issues, it’s a great example of how
a VR-first design process can be a valuable asset. So in our next iteration
of volumetric layouting, we increased legibility
and decreased the size of the UI significantly. Large UIs in VR can feel
uncomfortably claustrophobic. And if a UI takes up too
much of your field of view, your eyes and head have
to travel too much to see the various components of it. These are all issues
that can only be caught when seeing your UI in VR. Volumetric layouting is a
quick way of catching these. And as we progress through
our design process, we begin adding in higher
fidelity filler content. Things look good to
us at this point, but we have questions
that can only be answered with user testing. Meanwhile, our
environment designer begins his work in parallel
while we do user studies. Will users understand what
the discovery windows are? Will they understand
what the app icons are? Do they expect to be able
to scroll either of these? And if so, how do
they think they can scroll with the controller? We do a user study to
answer these questions. The first round of
research goes positively. Users understand what
discovery posters are and what app icons are. But there is a little bit of
confusion about scrolling. We’ve validated our layout. And we’ve become more aware
of the design challenges that we have ahead of us. Our environment designer
then gives us a first draft of the environment. We incorporate this draft into
our UI as quickly as possible. This way we can be
intentional when designing our UI within the environment. Our team feels comfortable
moving forward. Now that we know the
dimensions that we’d like for our discovery
posters and icons, we deep dive into them. In parallel, we start
engaging with 3D modeling. Now that the basics
are locked down, we begin looking for
moments of user delight. One of these moments is
the discovery posters. What if these posters
were less like posters and more like Windows
into different worlds? It could be a magical way of
discovering new VR content. To dive into this
area we branch it off and we prototype it using what’s
called a stencil shader, which is like a revealing mask in an
omnidirectional stereo image. An omnidirectional stereo
image, or ODS for short, is a stereo panorama that’s
mapped onto a sphere. It is one of a
few different ways of representing a 360
degree three photo in VR. Now it’s very important to
carry all of your design ideas through to the prototyping
stage for accurate validation. When we prototyped this
idea, we were underwhelmed. The stereo was actually very
hard to detect in the ODS through the discovery window. And worst of all, it used up
a tremendous amount of memory. Viewing the windows
side by side also gave the strange effect
of three deep tunnels into three different worlds. And to add onto all
of that, these images are a significant investment
for developers to create. So we took another
look at this idea. This time designing with
performance as a primary design goal and adding in the
additional requirement of elegantly flattening the
world within the window when the window wasn’t in use. We then investigated ways
of achieving this design goal without an ODS. We decided to prototype a system
of layers of flat textures that could easily be created
by developers in Photoshop. These layers were
much more performant than the huge ODS images
we were using before. And the depth effect could both
be exaggerated and completely flattened when not in use. After we prototyped this
idea we really liked it. We improved the prototype by
conservatively exaggerating the parallax effect. Parallax is one of the
cues that the brain uses to perceive depth. The result is a truly magical
experience to see in VR. We found a great solution
that people seem to love. If we didn’t consider
prototyping a first class tool in our toolkit,
this feature would have never
been made a reality. Along the way we’ve continued
to make improvements in our environment, transitions,
interactivity, and 3D models. At this point in the
process, we begin supporting the engineering
team with assets and working with them to
find the minimum texture sizes we can use while still
retaining a good looking UI. We begin engaging
our motion designer, as we start iterating
on our animations. Working collaboratively
with the desire to tie our UI to
our environment, we develop a wind
metaphor for motion that touches our UI environment
and animation together with a common theme. By working in parallel, we’re
able to improve collaboration across different
skill categories. And as we continue to polish,
we progress through our UI, doing deep dives in
these various elements. We push ourselves to
utilize the benefits of having a rich 3D UI
and a rich 3D system with lighting and materials. This is especially apparent
as we design the hover effect for icons. And as the motion design and
interactivity come to life, sound design begins in parallel. And while we can’t
emphasize enough how important sound
design is for VR, it began toward the
end of our process so that our sound designer
could have accurate timings for our animations. To learn more about sound in VR,
check out the talk on spatial audio tomorrow at 9:00 AM. And surely enough, we come
toward our refined design. This VR firs process enabled
us to progress quickly. The process was
very collaborative and used every single skill
set that we mentioned earlier along the way. By making progress across
multiple fronts per iteration, we were able to march
toward refinement without getting stuck. We understand our
specific workflow won’t be applicable to all apps. But we hope you find
the process we’ve shared serves as a powerful
tool to design in this new field
of many unknowns. I hope that the two processes
that Rob and I shared will be useful for your team. But a more fundamental
challenge still remains. How do you build that team? To talk more about that,
I’d like to invite Anshuman to the stage. Anshuman. ANSHUMAN KUMAR:
Thank you, Michael. [APPLAUSE] You know, designing the Daydream
Home experience with Michael and several other really
talented designers was an intense
collaborative effort. And I’m really happy that
we could share our design process with you. And you could see how
different designers came together and
worked together to create that experience. Now as you start building
your own VR experiences from your rough ideas
to finished products, one thing you will need for
sure is a strong design team. My name is Anshuman Kumar,
and I’m a design lead on the Daydream team. And I’m going to be talking
about building VR design teams. And for the designers
in the audience and those watching
it online, if you want to start designing for VR,
towards the end of my session, I’m going to be
sharing some tips that will help you get started. So with that, let’s get rolling. Building a team is not very
different from building a product. You have to start with
a thoughtful intention. What kind of team do I want? What do I want my
team to achieve? And when it comes to
building VR design teams, we often struggle with these
basic fundamental questions. Partially, because a
lot of us are new to VR. But primarily because
designing for VR is significantly different from
designing for other mediums. Unlike web or mobile, where
we used to spend a lot of time designing flat
UIs, for VR we have to design a world with
environments, lights, and sound, shadows, and motion. UI is just one a
component of that world. Designing this world
requires new design skills, different tools. It needs more time. And then we have to adapt
our processes and workflows as a technology rapidly evolves. All the factors combined
demand a VR design team that’s different and unique, Well successful VR design teams
have three unique attributes. Number one, designers
wear multiple hats. No one in such teams is just
an interaction designer or just a 3D artist. Instead you will find
an interaction designer who is also good at
3D, or a prototyper but who has a keen
eye for motion. Personally as a
designer, even though it might sound intimidating,
wearing multiple hats is what makes designing
for VR so much fun. Then VR design teams a
highly collaborative. Every advancement
in VR technology is opening doors to
endless possibilities of new interactions
and experiences. And the only way to explore
them at speed and scale is to work together, by sharing
and learning from each other. And as Rob mentioned
earlier, his team explored new ideas every
week by working together in small teams,
focusing on the problem, and then sharing their learnings
with the rest of the team in their demo parties. And finally, successful
VR design teams, even though they celebrate
diversity amongst their team members, they somehow
don’t let the roles get in the way of
getting things done. It’s very rare to hear
that, I don’t this. This is someone else’s job. Designers are very willing to
get out of their comfort zone and take on new challenges. But what are these skills
that I’m talking about? What kind of skills are actually
needed in a VR design team? A VR design team
requires diverse skills. And depending on the product
that you are building, these skills might
change a little bit. But typically a
design team, which is building VR interfaces,
require these skills. Now a word of caution,
some of these skills might look very familiar,
but the applications are quite different. For example, while
designing interactions, one has to additionally
consider spatial organization and hierarchy and
use game engines to create volumetric layouts. For visual design, the
concepts of grid and typography completely change as things are
layered in different z-depths. Now I do understand
that, if you’re starting to build
a new team, this might seem like a lot
of skills to find. So in that case, I would
suggest you to start with at least two designers. This will help them collaborate,
bounce ideas off of each other, providing each other feedback
and solve problem faster when one of them gets stuck. Between these designers,
you should have at least these three skills. If you recall the process
diagram that Michael shared, 3D design prototyping
and interaction design were the fundamental skills. And frankly, you
can’t accomplish much without these
fundamental skills. Other skills can be included at
different phases of the project as the need arises. Now you might be
wondering where are these are designers who
have multiple skills and could juggle
with different hats. Well, they’re around you. There’s a good chance that you
might find a designer who’s already designing VR experiences
and has these multiple skills. If that happens, that’s awesome. But if it doesn’t, then
you have to branch out and look our and scout
other design industries. We have noticed that
designers building games have great previous skills. They also have the experience
of finding creative solutions to the strict performance
requirements of VR. VFX designers are awesome
at making things feel larger than life. If they have experience
with realtime graphics and some exposure
to VR, they can be of great value for your team. For designers from
web and mobile, designing information
and creating fine and meaningful interaction
is their bread and butter. If they additionally have
3D skills or VR prototyping skills, they can be great
assets for your team. And don’t forget,
there are a lot of students who are working on
VR projects and design programs across the world. A thorough VR project
done at school can give a student
enough domain experience to start working
on a real product. So if you can guide
them, they can be a great addition to your team. But these are all industries. Where do you actually go
to find these designers? Well, I would say start with
maker events like game jams and VR jams. There is nothing better
than seeing the designers in their element. And if you get a chance
to jam with them, work with them on an idea. You can think of it like
speed dating in certain ways. In this process, you
will learn a lot more about these designers
than you will ever learn through regular
formal interviews. There is also a good chance
that you can find such talent at conferences like this one
and other tech events that happen all around the globe. The fact that you’re
here, all of you, means that you share a common
passion and common interest. And who knows, someone sitting
under this geodesic dome could be a future colleague. And lastly, social media can
be surprisingly effective. But you need to go beyond
the obvious mediums. Imagine watching someone on
YouTube who is passionately presenting their VR demos. Or Twitch, a lot
of designers have started using Twitch
to live broadcast their creative process. Watching a designer walk
you through their process of creating beautiful
VR environments, it will not only inform
you about the subject, but will also help you find a
great designer for your team. And of course,
following people’s work and honest opinions
on Reddit and Twitter can definitely reveal a lot
about their passion and domain knowledge. So for those of you who
are building design teams, here are some tips of
finding promising candidates. And those of you
who are designers who want to join this team,
this is a good example of what these design leaders
would be looking for. So as a design
leader, you would come across stunning portfolios,
beautiful renderings, and impressive language. And all that is important. But you will additionally need
to look for a few other things. One, has the person
made anything in VR? And I’m not talking about
a major project or years of industry experience. I’m talking about are
they tinkering in VR? Are making fun little small
demos in their free time after their day job? This is very important. Because if the answer is
no, then for a designer, learning new tools and
working with new technology can be very stressful. And even as the team leader, it
will become difficult for you to be helpful in transitioning
this designer as a VR designer. And then diverse skill
sets, we have already talked about the importance of
having multiple design skills, as a designer can wear multiple
hats when the need arises. And it requires true
passion to continue learning new things every
day and taking initiatives to explore new possibilities
that are created. Now, if you find a
designer with these skills, I’ll say act fast
and be flexible. And in a few days from now, if
you forget everything I said, just remember these four things. Build a culture where skills
are valued more than roles. Build a culture which
encourages teams to share and learn from each other. Keep an open mind
for fresh talent, and you will be
pleasantly surprised. And cast a wide net so
that you can get new talent and build a more diverse team. And then, for some
reason, if you don’t want to build
a full blown team, then consider involving
a design studio. There are several design
studios across the world who are making great VR content. And if you want to
know more about this you can find me after this talk. And I really hope that
this information helps you answer the question that we
started with, what kind of team do I want to build? I also hope that this
information helps you build that strong design team. Now this brings me to the
last part of my presentation where I promise to share some
advice for designers who are interested in designing for VR. So I have two tips
and won advice. Tip number one, learn
from your own experiences. If you are new to
VR, get a cardboard, throw your phone in, try out
as many VR apps as you can. Keep a journal of
your observations. Gradually you’ll start
developing an eye for the nuances of VR. You’ll start identifying what
works, what doesn’t work. And if you start feeling
that urge to make things, then follow the second tip,
which is learn the tools. As a VR designer you might
need to learn these three categories of tools. And if you’re a designer, you
only already know one of these. You need to focus on
the remaining two. I would recommend you to
start with a gaming engine. Both Unity and Unreal are free. And they are tons
of online material that can help you get started. You know, it’s very
important to get comfortable with these tools,
because this will let you focus your mind space
on what to create and not on how to create. And lastly I’ll be honest. You know the learning
curve is steep. You will need to be really
passionate about VR are and persistent to get
over this learning. curve. One thing that helps is being
part of the VR community. It can give you enough
support and inspiration to help you keep climbing
up this learning curve. And, hey, it might look
like a tough climb. But the rewards come
very early and they are very satisfying and fulfilling. So don’t give up. With this, I’d like to
conclude this session where we talked about process and team. And everyone, I
feel, in this room is going to be a pioneer
in VR as we start working and continue contributing
to this domain. And we are really glad that you
have joined us on this journey. Thank you so much. [APPLAUSE] [MUSIC PLAYING]

Add a Comment

Your email address will not be published. Required fields are marked *