Whew — what a ride! When Magic Leap announced that our former hackathon project ‘SeeSignal’ had been selected for their Independent Creator’s Program grants, our team was elated! Given that we had lost the Magic Leap + AT&T hackathon at which the idea was originally created (lol), it was truly magical to learn of Magic Leap’s support for our vision of immersive signal data.
After going through a couple of intensive bootcamps and courses on Magic Leap development (as part of ICP), we dived right into development. What follows are the lessons learned during the process of developing for Magic Leap, and the insights we gathered while working on SeeSignal as a whole. These are high-level product design insights; if you’re interested in the nitty-gritty lessons learned by our engineering team, stay tuned. That post is coming soon (you can now read it here).
Alrighty — get ready, buckle up, and join us on our journey to the heart of data, creativity, innovation, and transformation!
Lesson One: Storyboarding Isn’t Just For Film
I’ve always been incredibly passionate about film. I’ve pursued screenwriting, directing, producing, and acting as hobbies for many years. I hate Hollywood movies immensely and I hate Hollywood as an industry (I’m one of those arthouse, indie film lovers), but as I live in LA, I’ve met and befriended many people from the film world. I’ve created my own short films (shout out to the North Hollywood Film Festival for screening my very amatuerish films lol) and played the evil sidekick in many tv shows.
During this process, I’ve learned some valuable skills. Many are soft skills, how to read and manage people. But one practice, in particular, turned out to be incredibly useful when developing SeeSignal: storyboarding.
For those not familiar, storyboarding is the practice of drawing out, shot by shot, a film. You visually sketch out what the viewer sees, then underneath, write what the viewer will hear. In the case of onscreen text, you also include what the viewer will read. It is a step by step way to break down a multi-sensory experience (film) into small, digestible pieces. The goal of storyboarding is to help the filmmaker communicate his or her vision to multiple teams of artists and creators, so that everyone can come together to tell the same story.
Similar to film, immersive experiences are multi-sensory. They are not linear or even branching 2D workflows. They require taking all the user’s senses into account while designing an immersive product. As such, designing immersive experiences are more akin to shooting a film than they are to designing 2D tech products. In the same way a film crew has a camera team, a lighting team, an audio team, a wardrobe team, etc — all of whom need to know what to do in each individual shot — an immersive development team must address the sound, the lighting, the interactions, and the text (should any appear on the screen).
One of the things I love most about designing immersive products is it’s similarity to film. I can do similar work to the film industry, but actually get paid for it (jk, maybe). As our team began to struggle with traditional written requirements, I immediately thought: “STORYBOARDS! Let’s storyboard this s**t!”
Lo and behold, storyboarding was immensely helpful, especially during more linear experiences like onboarding tutorials. It kept everyone on the same page across multiple different departments. Presenting all the information about each ‘scene’ within the product in one central location was highly effective in communicating my greater vision — and the user’s experience in the product — to my team.
In short: storyboard. Do it often and do it early. This film work hack worked wonders for SeeSignal! Here are some free storyboarding templates. You’re welcome.
Lesson Two: Why Use Tiltbrush When You Have Spatiate?
For product brainstorming sessions, our team was used to using Tiltbrush to mock up and sketch out ideas. This worked great when it was a VR product. However, developing a spatial computing product while brainstorming in VR didn’t work out so well. I guess this should have been obvious, but hey, in the battle between laziness vs obviousness, my laziness will win every time. I thought, eh, it can’t really be that important to brainstorm using spatial computing…
WRONG! With spatial computing, the environment is visible. In VR, it isn’t. As simple as this sounds, it changes a lot about the product design. Using a VR tool to design an spatial computing product will ensure that your team will miss every important detail. Things that look and feel great in VR turn out to really suck in spatial computing. Minor interactions in VR turn into incomplete flows in MR. You get the picture. The devil is in the details and we found out that the platform you design on matters greatly.
Enter Spatiate! Our savior in many, many situations. Magic Leap’s Spatiate app (developed by Across Realities) is like Tiltbrush for spatial computing, but better. It allowed our team to brainstorm and design our product using the hardware on which we planned to deploy. This allowed us to be aware of every single detail and to take all of them into account when making design and product decisions. This took our game up a whole other level!
Additionally, since the BadVR team is mostly remote, Spatiate allowed our team members to collaborate remotely, letting them skip the slog through 2.5hrs of LA’s worst traffic just to put on headsets and travel to yet another dimension. Our product manager, Stefanie, could easily put on a headset and instantly feel truly present with Brian, our senior developer. Using all the various design tools in Spatiate, they could work through roadblocks in a way that mimicked the actual product environment.
A huge shoutout and a big thank you to Across Realities for developing such a great product! SeeSignal benefitted in so many ways, thanks to Spatiate!
Lesson Three: Writing Audio is Hard
Another skill I stole from the film industry helped me a great deal when creating audio content for SeeSignal — screenwriting.
Given that this article will probably be read primarily by tech industry people, let me let you in on a little secret: it’s really difficult to write good dialogue. As someone who’s loved screenwriting forever, I know exactly how hard it is and I’ve put in my 10,000 hours learning how to write dialogue well. When working on tutorials or other content in SeeSignal, this skill of writing great dialogue came in very handy.
A quick story: Once upon a time, I was friends with a pretty accomplished screenwriter. He was a mentor of sorts. Although I never ended up doing anything professional with his insights and teachings (sorry), he did a great job teaching me how to write. He’d spend hours and hours reviewing my scripts, yelling “SHOW ME, DON’T TELL ME” ad nauseam until I finally learned to stop writing expositional drivel. He’d mark up my scripts with a red pen, circling all the instances where I needed to remove unnecessary words (always noting: ‘implied’ or ‘repetitive’). In some small way, his Harvard degree in creative writing and 25 years as a professional screenwriter were passed to me in the form of an intense hatred for any extemporaneous words or any verbose, expositional dialogue. To this day, I can see his imprint on my work, both in my personal writing and in the writing I did for the audio tracks of SeeSignal. Thank you, J. 🙏
During the process of figuring out how to best utilize audio in SeeSignal, our team took turns writing out scripts for the tracks. The student turned into the master as I sent Slack message after Slack message, imploring my team to “SHOW ME, DON’T TELL ME!” It was a constant battle to determine whether some instructive should be delivered via audio, visual, tactile sensations (like a controller vibration), or via written text. I tried my best to channel the core fundamentals my mentor had taught me: Simple is best, show me, don’t tell me, use as few words as possible to have the greatest impact.
With film, all dialogue is meant to either do one of two things: move the story forward, or to build and convey emotion. In our product, all audio either served to instruct the user or to provide feedback and confirmation of a behavior. Following this framework, we were able to (I believe anyways) elegantly design a product with a perfect mix of inputs, balanced in such a way that every single word, image, or sound conveys the maximum amount of meaning with minimal amount of workflow intrusion.
I will leave you with a quote by David Mamet, who’s book “On Directing Film” is the absolute best book to read about screenwriting. This quote encapsulates the lesson we learned with all app interactions, but most of all audio: less is more.
“How do we keep the audience’s attention? Certainly not by giving them more information but, on the contrary, by withholding information — by withholding all information except that information in the absence of which would make the progress of the story incomprehensible.”
Lesson Four: Pass The Dad Test
In previous, 2D products, I developed this thing called ‘the mom test.’ With any product I was designing, I’d constantly ask myself: “could my mom figure this out?” For the vast majority of my career, I designed products for non-technical users, and my mother, while the absolute best mom ever, is the epitome of a non-technical user. If my mom could figure out how to use a product I designed within 10–15 seconds, I could guarantee my users would too.
However, for SeeSignal, I created ‘the dad test’ for the following reasons:
- my dad is slightly more technical, a closer match to most Magic Leap users
- my dad is OBSESSED with Magic Leap
- my dad is also a huge RF signal geek
Given all of the above, it seemed appropriate to rename the test and use him as a representative for the typical SeeSignal user. If my dad could figure out how to use the app and not poke holes in it, then I knew I had a winner, lol.
My family lives in Kansas City so unfortunately I don’t see them that often. However, I gave my father a Magic Leap and I sent him builds for feedback. I also recently visited Kansas City for family reasons, and got to show my father a near final build of SeeSignal — or so I thought.
He put on the headset and immediately found 5 errors with the product, obvious and not-so-obvious things about our RF propagation algorithms. While disappointed in me as a daughter for my mistakes (lol, just kidding), he did me the biggest favor a father could ever do: told me everything I needed to fix in SeeSignal to make it a success! Thanks for the gift, Dad. Can’t wait to see mom’s sideways Facebook video of you tripping over animals, cursing, while troubleshooting the family wifi!
Lesson Five: Accessibility Is Important
Speaking of my father — he’s colorblind. Specifically, red-green colorblind. Most men in my family are. My cousin Sarah is a rare woman who’s red-green colorblind (that’s how strong the gene is in my family). Another gift from my father was the recommendation that SeeSignal be accessible to colorblind people like him. People who can’t easily determine the difference between red and green sticks!
I’m ashamed to admit that the thought would have never crossed my mind had my father not mentioned it. To me, it seemed obvious to make the good signals green and the bad signals red, much like a traffic light. I didn’t realize that using these specific colors would make it near impossible or at the least, very difficult, for red-green colorblind users to get any value out of our product.
To remedy this, we added a feature that allows users to select the color gradient they wish to use to display the quality of their network signal data. Users can select from 3 different options, 1 of which is suited for colorblind users.
BadVR’s mission as a company is to democratize insight. The first step towards doing this is making data accessible to everyone. One of the most important lessons we learned during the process of developing SeeSignal is that accessibility matters. Accessibility design needs to be imbued into the DNA of our product. Every product decision needs to include some thought towards it. If we end excluding even a small number of people from understanding their data, BadVR does not accomplish our mission. We can, should, and will make sure any data visualized on our platform is accessible to all.
…And This Is Just The Beginning!
We’ve learned so much while developing for Magic Leap’s platform, but our story doesn’t end here. BadVR is excited to continue our mission to democratize insight by building out our fully interactive, fully immersive data analytics platform. Follow along with us as we continue to discover new insights, release new data environments, and deliver spicy haute takes on Twitter! 🔥
The BadVR team looks forward to continuing to reimagine what data can be.
And if you’re interested in an enterprise demo, please reach out now!