At the 2018 Synapse Summit, there was much interest and discussion around the topic of Virtual Reality (VR) design and development methodologies, guidelines for success, and best practices that are delivering significant results in the Spatial Computing market space.
As an professional Business Systems Analyst/Developer and Spatial Computing enthusiast, I share an interest in AR/VR design and development.
That said, I've begun to research, document and explore VR application development concepts, ideas and methodologies in practical use today by leading VR application development teams.
My research into VR application development methodologies began by re-visiting a VR Design Process talk presented at the 2016 Google I/O Developer Conference. What follows is basically a key talking points transcript that I extracted, based on the first part of the presentation, led by Rob Jagnow, Software Engineering Manager at Google. Check back periodically as I’ll be adding more content based on my research and reader feedback.
I believe that viewing this talk and reflecting on the concepts, ideas, best practices and guidance shared by Rob Jagnow (captured in part, below) is a good starting point for those of you interested in learning more about current VR application development processes and practices.
In the coming weeks, I'll be diving deeper into current VR application development methodologies and best practices. I'll be freely publishing some of my research findings via my website. More in-depth research findings and takeaways, complete with references and resource listings, will be exclusively available via Patreon.
I welcome your comments, suggestions and ideas for upcoming research and resulting articles!
The VR Design Process Talk is divided into three presentation sections:
Google's VR design process framework has delivered 60+ VR prototypes via weekly sprints.
Challenges in VR Design
Attention to Safety
Anyone working in VR is going to have to become familiar with a whole new set of skills, tools and workflows. For example, Game Engines have become an invaluable part of the VR developer's toolkit.
Explore everything. Fail fast.
Daydream Labs projects focus on exploring terrain quickly, finding promising use cases, testing a lot of ideas without wasting a lot of time on supporting a more structured process.
It takes many more development iterations as compared to developing in other media, to create a great VR experience.
The current small Daydream development team has completed 60 prototypes in a years time. We work in teams of two (one designer, one programmer), with the goal of releasing one prototype per week.
Projects range in size from very small, including:
Other project themes are larger:
The Daydream Team Prototyping Process can be summarized as a five-step process:
Get opinions from friends, family, co-workers, etc. Everyone has ideas of what a great VR experience would be. Get ideas and opinions from diverse teams who have a breadth of perspective and experiences.
Creative Exercises When Considering Ideas for Implantation
Don't be incremental; the best VR experiences are not going to be derivative in nature. They will not be something you've seen in another media platform that is transferred over to VR. Rethink everything cognitive of the strengths and limitations of VR.
Let's be imaginative; create a world where you use your trebuchet to launch giant stuffed animals that are fetched by your pet T-Rex.
Constraints are Good
Constraints are good. You don't want to over-specify the details for a team that is working on a project. You do, however, want to have that team work with challenging constraints.
"The more constraints one imposes,
the more one frees one's self. And
the arbitrariness of the constraint
serves only to obtain precision of
~ Igor Stravinsky
A Bad Constraint vs a Good Constraint
For example, a bad constraint for a VR product development team would be the following: You have a team of 50 designers and you put this task to them: "Create a VR version of a classic board game that feels exactly like the original".
The problem with this constraint is it does not leave room for creative interpretation. So, what you end up with from your team of 50 designers is 50 versions of checkers in VR.
Let's instead, provide a good constraint to our VR team of 50 developers. "You want a game for two players, with the following constraints
These set of constraints provide an enormous amount of room for creative interpretation. Your team of 50 developers will now deliver 50 different, totally awesome and imaginative games.
When you get going with the brainstorming process, ideas will come in at a rate that requires filtering and ranking the ideas. What's needed is a way to choose the most promising of the ideas. The Daydream team has selected a criteria that enables them to filter and rank ideas.
We are interested in Education and productivity; VR game developers have the game development segment well covered. We want to focus on some of the potential areas for VR that have not yet been addressed.
A prototype in a week?! Is that sustainable? An onsite game jam or hackathon lasts 48 hours typically, to create a working game in two days. When you take a game jam approach and stretch it out to 5 days, it is a lot more manageable.
Start with an experience that is way smaller than an Agile MVP. You want an experience that needs you to walk a user through an experience and enough to test your hypothesis.
Stay focused on the core objective of developing a workable game in 48 hours.
There is no sense is building prototypes if there is going to be nobody able to seem them. Have a demo party scheduled every week to show you prototype and get feedback from those viewing.
"You build the tip of the
Iceberg and people will
Come to you and describe
~ Manuel Clement, Google Daydream Team Member
Users tend to provide features as feedback when a prototype is presented to them. If a near finished product, feedback tends to focus on subtleties of a feature, rather than features themselves.
You do not want to get bogged-down at the start of prototyping with a heavy-handed design document, If do want to document what you've learned as a result of your week-long sprint development effort, the benefits realized from the effort will largely evaporate into the ether. Your goal for your effort is to capture information from the effort so your work has impact and results.
The Daydream team typically documents week-long development efforts by:
Monday: Demo Party
Pick the next project; review the concept name, description, and project scope. Further restricting scope of selected idea; deciding what hardware to implement on, etc.
Tuesday, Wednesday and Thursday: Extract Findings & Design Iteration
Our Daydream teams are still extracting and summarizing findings from previous week's project.
Examining this week's project scope and Iterating on both the scope and design.
Iterating on Scope and Design
Get our first prototype working and examine our work product relative to the project scope and goal.
Reaching out to members other teams for feedback.
Friday: Wrapping-up the Week's Party
The team is wrapping-up the current weeks project, putting on enough polish on the project as time allows. Narrowing down our list of ideas for the start of next weeks project.
Best practices and guidelines include: