Building a team: Prototyping at W12 Studios
My experience embarking on our React.js journey
W12 Studios is a young digital product design agency based in London. We’ve been designing digital interfaces, primarily for the TV, for almost 4 years. During that time the studio has grown close to 40 designers, cemented itself in the TV landscape across both the US and Europe, and expanded its digital expertise to numerous other platforms. The journey has also given birth to an internal prototyping team exploring it’s own potential…
My journey with W12 began soon after it’s conception. A fresh-faced broadcasting graduate, somewhat oblivious to the digital world. Then a motion designer, I was tasked with bringing user journeys to life. I soon realised how tedious animating interfaces was going to become. Cue the beginning of my journey with code. I dived into the world of expressions — rigging interfaces in order to eliminate duplicate key framing.
It didn’t take long before I was looking to add interaction to my work. Along the way, I was getting crash courses in interaction design, user experience, visual practices and presentation techniques. I was like a sponge; soaking it all up. It became a habit, and I got pretty good at it. So after a few trials with various tools and technologies, I ventured into openFrameworks.
The combination of this eagerness to learn and W12’s openness to letting myself and others like me run with something would define an element of our culture today, an internal prototyping team, and, in turn, the latest step forward for us as a department — embracing React.
18 months on, W12 Prototyping is about to become seven strong — comprised of both homegrown and seasoned Creative Technologists. Over that time I’ve expanded into native development in Swift. Together, we’ve formed a highly involved, collaborative effort to define the future of prototyping at W12.
The first task for our collective leadership was to standardise our workflow and practices to accommodate our growth and ever increasing workload.
Until now, we would develop a prototype with any tool we were comfortable with or thought might suit the job. WordPress, Swift, openFrameworks, Quartz Composer, Keynote, pen and paper — whatever. If a concept could be conveyed and tested then it succeeded in it’s job as a prototype. This was both a blessing and a curse. TV products share many of the same elements; think transport controls, channel lineups, VOD purchase flows. Freedom across tools meant an inevitable about of recreation.
The adoption of the React framework allows us to develop a set of core components that aim to increase our efficiency across projects that share many of the same elements. We had made animating interfaces less tedious, it was time to do the same for building them.
My programming journey is still in it’s infancy. I’ve become increasingly proficient in Swift, and enjoy it. I naturally gravitated towards React Native.
Despite my prior eagerness to dive into new tools and technologies, this was the most testing, partly due to my averse attitude from the start. I was comfortable in my Xcode bubble. Why would I want to develop something of the same standard in a more roundabout way? The cross-platform thing was impressive, and the simulator reloading was neat, but I was forever battling to get everything working together — the novelty wasn’t convincing me. Sometimes things were ‘ES5’, sometimes they were ‘ES6’, sometimes ‘ES6’ was ‘ES2015’, sometimes it’s all jumbled together. Atom as the text editor, Xcode to run the simulator, Chrome to debug, Terminal for the node server. It all felt like one big mess.
One month on, and I have finally opened up to the bigger picture. I’m learning to understand the mess, not just accept the magic. It is making me a better developer — just as I was told it would.
What’s worked well
Our role as prototypers is to bridge the gap between design and development. We explore, test, validate, or even prove things can be done. Pigeonholing ourselves would have adverse effects on our ability to best bring our creative work to life. In contrast, React has provided us with greater opportunities. We have scope to work with Android, can focus our efforts on developing our components, and have the flexibility to combine other technologies.
React’s component based structure has undoubtedly streamlined our workflow. Not only that, collaboration on projects has improved enormously. Having previously stuck to our own methods and technologies, prototypes were often owned by sole technologists, making them difficult to pick up by others. It wasn’t scalable. Alignment has enabled us to share projects; keeping people motivated with a variety of work and encouraging better knowledge sharing. This was made possible by standardising our way of working. Embracing React has made learning and troubleshooting more effective and efficient.
What I’ve learnt
My React journey is only just beginning. Despite that, in little over a month, I feel confident in saying I’ve added another tool to my belt. I’ve learnt, this time more than ever, that persistence will pay off. No matter how great the Udemy course; the best way to make things stick is to apply it to a project. Whether that’s a live client project or just a random idea — it provides a platform to continue plugging new learning into; eventually encapsulating the entire process.
As we collectively find ourselves working proficiently with React, the next stage is to create and develop our shared library of components. Our goal is to form a product’s foundations rapidly, providing more time for experimentation in new and unique interactions, ambitious motion implementation, and more advanced functionality to extend our prototypes.