From concept to app store in 8 weeks
So you want to know what it was like to conceive, design, develop and release REA’s first commercial virtual reality application in a little more than 8 weeks? You’ve come to the right place. We’ve been working toward this app for much longer than 8 weeks of course, but it was largely experimenting with emerging technology. Since then, we’ve learned a hell of a lot and there’s nothing like a looming first release to force a few hard lessons.
Before this, every member of the team hadn’t worked in a VR team before. And when you think about it, we’re a small handful of people in the world who have now done so at this scale. So, we feel it’s our duty to put what we’ve learned out there. Warts and all. It’s our responsibility to progress this industry that’s still in its embryonic stages. Fail fast, as they say, so everyone else can learn quickly. If the web has taught humanity anything, it’s that. So without further ado, ladies and gentleman, our lead characters of this tale.
I’ll start by being brutally honest. The team that came together to build this app knows their shit. It was composed of a very experienced set of software developers, designers and product managers. We’ve all done this software thing before, repeatedly. Across web and mobile platforms in many large and small companies. Because of this, we’ve made incredible progress to release a solid MVP in a brand new technology within what’s really boiled down to be a few weeks. I am personally incredibly proud of what exists. But, we know it’s not perfect, and nor should it be, right?
But what makes a good VR team?
The rules for assembling a team to create a VR app aren’t that different from your standard software team, yet.
You still need representatives from the business. The product people who are thinking about the app strategically every step of the way — even when the rest of the team are in the weeds of the build. For this project, we had two key characters. One played the very high-level strategic/go-to-market role, the other more of an iteration delivery lead role. There wasn’t a clear cut boundary here but what I’m trying to say is that both are absolutely necessary to produce quality software in VR.
You still need to engage with users through an iterative design process so obviously a designer is a must. But if you have designers collaborating, even better. We shared the roles and responsibilities of a designer across 2–3 people at any given time. This was a huge learning opportunity for everyone involved and it’s an absolute luxury to have multiple designers collaborating on a project like this. There’s a lot of creases to iron out around testing with users in VR, creating hi-fidelity designs for VR and sharing those outputs amongst designers so having experts in all these areas sharing their depth of knowledge and adapting on the fly to the limitations of the technology was a sight to behold. As one of the designers on the team, I can confidently shout from the rooftops that it’s been an incredible experience for everyone.
Last but definitely not least, no one is getting anything built and shipped without engineering. Having 4 developers of varying seniority and experience in gaming, web and mobile development meant we had a very balanced team who were ready and able to put on their hazmat suits and explore the ever changing landscape of VR. And yes, that landscape is changing a lot, even within 8 weeks.
The tenants of a good software team are still the same in VR as they are in web or mobile. Business, Technology and Customers all need a seat at the table in order to produce quality software that everyone is proud of and people will use.
But, having said that…
If money was no object, having a 3D modeller or digital environment designer on hand to produce content would have been a luxury. So too, a sound designer’s skills would have been a welcome addition. Whilst at the moment we’ve managed to get by through some great teamwork and innovative thinking, these skills are clearly going to become very sought-after if VR continues on the same trajectory of adoption it’s currently on. There’s a very strong link here between the design of VR experiences and the principles of game design and I wouldn’t be surprised to see this merging more as the industry matures. There will absolutely be specialty roles and new jobs spawning from this technology. What those are yet are still a little unclear and will be largely dependant on trial and error as we evolve along with the technology.
Progress through process, sort of
This deserves it’s own in-depth analysis but it’s fair to say that we haven’t nailed a solid process for how a team works on a VR app. Without going into too much detail, we loosely borrowed from Agile software development but a few things prevented us from getting into the usual team rhythm:
- Development in VR is time-consuming. And rightly so. It’s new, uncharted territory for the most part. Sure, there are certain underpinning principles that are ‘best practice’ but with standards, SDKs, and different versions of development environments like Unity coming out frequently, it’s incredibly hard to estimate. Like any short term project, there’s not enough time to understand a velocity which means it’s even harder to plan. When you can’t plan, it’s hard to hit a solid, repeatable cadence.
- Good, easy-to-use design tools don’t exist yet. Unless you’re a designer whose comfortable working in a 3D environment (and let’s face it, not many are), we currently don’t have the right tools available that help to facilitate a good workflow between developers and designers. What we do know is flat mock-ups don’t work for testing so forget Illustrator, Photoshop or Sketch. People experience VR in 3D and so designers need to design in 3D as quickly as possible. Whilst it’s possible to fiddle and work on your own, integrating any ‘designs’ you create in to master project is, well, to be honest, a bit shit at the moment.
- Designer/Developer pairing is difficult. VR isn’t really a shared experience at the moment. We don’t have a common language of patterns to communicate our intentions and outcomes. This of course will evolve over time but it’s definitely a barrier at the moment. I’ll write more on this later.
So, as you can probably tell, it’s safe to say we were winging it a bit. Stand ups are still useful and carded up stories were par for the course to help keep our progress visible, manageable and on-track. But these were the only 2 rituals we really had as team. We used a combination of Slack and face-to-face chats to work through problems and ideas together so collaboration in this way was incredibly important. But we haven’t got a magic bullet for a solid collaborative process in VR application design yet. When you don’t have these clarity and rythym as a team, confidence in a direction is hard to maintain. Confusion creeps in and it takes a lot more communication to make sure we’re all still aligned on hitting the goals we’re trying to achieve for a release 1.
I can only imagine that this will continue to evolve for many years as tools and techniques are discovered through trial and error, just like it has in the web and mobile worlds.
Where to now?
So, we have an app, in the world, being used by people. It’s incredibly exciting. We’re about to find out what it’s like to 20support an application like this, manage versions, and release updates. We want to understand how people are using VR so working out how to do analytics in a 3D world is starting to enter our thoughts. I mean, just think about that for a moment. We can track anything and get better at understanding this technology every day.
Despite what we’ve achieved so far, it still feels like we’re standing on a precipice. If we turn around, we can see how we got here, but we’re not really sure what’s going to happen when we take our next step off the cliff. I mean, I know we’ll swim instead of sink, but we’re not sure if that thing that looks like water at the bottom of this cliff behaves like water at all. And, well, that’s kind of exciting.