Designing for Yourself

If I’ve learned one thing from my education, it’s that the innovative or technical merit of a project is nowhere near as important as the experience of using it.  I learned this in my journeys through NYU’s Game Design program, where playtesting of my projects revealed that many of the systems I’d built that the engineer side of my brain was most proud of turned out to be impossible for players to parse.  If a player doesn’t understand a part of your game, it’s useless–so your only recourse is to either abandon the idea entirely, or work hard to make it legible.

This is where we found ourselves recently while working on CAVE.  Sebastian, our brilliant but, until recently, only developer on the project had created many efficient and elegant systems that ran the show.  One of them was born from a clever insight that he’d had: it’d be far easier to run the show at SIGGRAPH if we could control it from a cell phone instead of a computer.  Of course, a lone software engineer regardless of skill will inevitably make decisions that make perfect sense to them, but are inscrutable to others.  Such was the case with the interface he’d designed for our docents to use–it was clean and simple, but had some issues that would’ve gotten in the way while we tried to run the show.  I was delegated the task of fixing it up.

I could’ve taken the easy route of fixing the problems that we had, while leaving the UI design mostly the same so I could get it done quickly and move on.  But there was a problem–all the small idiosyncrasies that Sebastian had to explain to me in order to use the GUI to control the show would become possible points of failure once we handed the phones to the docents assigned to us at SIGGRAPH.  One of our goals with CAVE is to prove that installation VR can be available on a mass scale instead of an individual level.  In order to accomplish that, we must reduce downtime between shows as much as possible.  We had to create a docent-friendly interface.  So we decided to take the hard route, ripping all of the UI design that Sebastian had created in order to start over.

I’m working with Mary Li, a budding UI/UX designer coming out of the Game Design program, to design and implement a new UI together.  Sebastian and I sat down with her to discuss all the problems we had with the current implementation, and all the ways we thought it could be better.  She took that critique and used it to design a new interface  from the ground up.  We’re still in the process of implementing it, but it’s going very well so far!

This process reiterated to me the importance of always being critical of what’s been made before.  So much of successful software design is about iteration, which requires you to take nothing you’ve made for granted.  You must always be looking for ways to make your own work better, or else you’re stuck with the first version of the idea you came up with.  I for one am very glad to live in a world where our doctors no longer wear long-nosed masks.