ROB JAGNOW: Good 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]