When I was transitioning from UX to game design, I designed the interface for Cyberpark/Sierra Online – my first large-scale social gaming platform. Working alongside game designers taught me how to design a social interface with complex interacting systems. Working as a designer on innovative, genre-defining games & products like The Sims, Ultima Online, Rockband, and eBay taught me to think of digital services as systems first. Working alongside talented designers like Will Wright, Chris Trottier, Richard Garriott, Raph Koster, and Dan Teasdale taught me how to model, develop and bring complex systems to life.
Part of why I “fit in” as a gamedev was my background in science – which taught me how to form a hypothesis, collect data to confirm or disprove it, draw conclusions from the data, and make revisions to the hypothesis. The thrill of discovering TRUTH made me fall in love with science – then in graduate school, I had a front-row seat to the spectacle of scientists fudging their data to keep their funders happy. I decided to look elsewhere in my search for TRUTH – and discovered computer science and software architecture.
For a science geek and truth-seeker, building software is a revelation – because it makes transparent that there is no ultimate TRUTH – only the contextual Truth determined by what your players finds engaging, useful, delightful, and accessible. “Truth” is all about what works in your particular context, for your particular audience.
Lean/Agile UX is about discovering this Contextual Truth via prototyping, user-testing, iteration, and a relentless focus on testing your assumptions with real users. That process also describes how every successful game I’ve ever worked on was created. Systems and games aren’t fully designed up-front – they’re prototyped into existence, brought to life through interaction, iteration, and tuning.
If your environment discourages UX testing, iteration and tuning, you’re gonna a hard time innovating. I ran into this recently with a client – a mid-sized startup with the appetite and ambition to innovate, but repeated failed attempts. After some digging, I discovered that the development environment itself is not setup to do UX experiments – it’s setup to integrate and push code that’s been specified. Creating a UX sandbox to test and iterate new features and systems is non-existent – and when I pushed forward and actually set one up, the process was expensive, painful and ultimately rejected.
When I explained why we need to do agile user-testing and iteration to create great UX and bring new systems and features to life, the Head of Product Development told me “We shouldn’t be doing user-testing – my engineers don’t want to build wireframes. We need finished Photoshop specs for pages they can just build once.” This sentiment was echoed by the branding agency that took over the project – who assured the team that any user-testing involving less than 2000 users should be ignored.
Change is hard. If you want to stay ahead of the curve, and practice Lean UX throughout your lifecycle, make it a priority to create a sandbox where your design team can test and iterate new systems and features with real data and real users. It takes work in the short-term – but the longterm payoff for integrating this into your development practices is worth it.