Immersive Experience in Augmented Reality and Virtual Reality
Case from my portfolio: How to work with screens where everything can be a screen?
Of course, over time we were reframing the problem: How to interact when everything can be interactive.
Context
Working with R&D is extremely adaptive, with a lot of abstraction and few irrefutable hypotheses. In part, in the tactical, what we have of internal expertise to narrate a reasonable improvement hypothesis. In the abstract, it is how to make it happen tactilely and efficiently.
There were initiatives all over the place and eventually, one would meet the other, expand the knowledge base, and adopt or not the findings of each research.
On the other hand, the research documentation process was adopted for all initiatives, that is, a process that for me started backward — it started with the documentation, POCs were carried out from the documentation and then the experience errors were observed after POC. This happened because it worked in a classic product format within a very demanding and unproductive documentation culture for the desired purposes, which were exploration and not documentation.
It is almost like starting a design system without purpose, pure aesthetics without function.
It is counterintuitive to think that an exploration squad will be almost entirely occupied in documentation, to have it as a deliverable for the development team, and then return to documentation.
For me, and I hit on this key a few times, to make our initiatives relevant, we would need to remodel the process that would necessarily be in pairs, one tech leader and one designer, both exploring for some time: the Tech leader straining to the limits of technology and the designer with straining for possible use cases scenarios, to then share the results of the explorations, converge in a group, and then document the findings to scale into production. But necessarily the model was that because of other issues that were outside our agency area.
How would I do it?
In abstract contexts, I would provoke behavioral usage scenarios that are inherent to modern human nature: routines, productivity, learning, leisure (etc).
With this in place, I would list the use cases that would best fit the context of an experience amplifier. Nothing assures me but nothing prevents the fact that the technology from 3–5 years from now will be so miniaturized to the point of no longer being a headset and instead a type of glasses, or, almost does not matter.
What matters is the premise: amplify or extend interactions to the real world. With that, we already leave current problems aside and go to experience, which can be prototyped before technology.
I would displace squads for each usage scenario: with one tech leader and one UX specialist in each squad to serve as support; and weekly collective iteration of insights and findings. The TL of each squad would be in charge of researching emerging technology for the scenario as well as the UX Specialist.
Small functional prototypes for proof of concept, either in the AR/VR headset environment or in the use case.
I would prioritize the most functional POCs with the current technology for design -> development -> documentation in parallel with Research.
Then we would have a lifecycle of a functional POC, medium-long-term insights, and deliverables for HQ of high performance.
Learnings
- Looking 3–5 years ahead of current technology and feeling out usage scenarios, contexts, etc. is very fascinating and challenging. It is indeed an exercise in futurology.
- Processes are made to be adequate to your reality — Your problem is mandatory, not your process. And this vision has to be shared at scale, otherwise, it will not work.
- I don’t know how to work without a goal: there were several moments of gaps between projects where we had to hunt for what to do, even if it was to raise abstract problems and engage two or three people around it. I failed miserably at this. I felt the transition from a manager who sought excellence to another who sought security, and in this transition, I lost space and excitement for what we did.
- Even compliance processes can be adapted to not be constrained but to ensure processes.
- A team that is too self-confident can over time become a fiefdom of knowledge, and only of self-confidence at random, making the culture more segregating than aggregating — which is also counterintuitive in an R&D environment.
- I strengthened myself in some convictions of design culture: transparency, radical sharing, and clear lights on the points that are long-term objectives.
Conclusion
Processes are made to be adapted, not to be a cult to be followed blindly. Sometimes, by moving just one or two pieces around, you will have much more efficient results. Nothing prevents me from being wrong, but the main provocation is to not get comfortable with processes and to keep testing processes with clear and factual objectives.
