Designing for an Open Source World
I am a visual designer. My degree is in graphic design. I spent the majority of my career creating print design, web design, and identity design. I then started my journey in the tech industry delivering immersive visual experiences on a new head-mounted display (HMD) hardware platform. I have made my living through visual communication for nearly 30 years. And in all that time, I have never shown my audience a concept before it was fully realized. I have not let them poke around in my design process to witness my ideation, to page through my sketches, or to interact with my prototypes. That all changed, and changed suddenly, when I joined the Babylon.js team.
Most designers are familiar with the process I was taught:
- Meet with the client to learn what they are trying to accomplish.
- Deep dive and try to understand what they really need and what vehicles are available and appropriate for their messaging.
- Research the industry and audience to understand the table stakes and where there is opportunity to stand out.
- Sketch. Sketch more. When you think you are done, sketch again to make sure.
- Create paper prototypes to clear the first hurdles of your design.
- Create digital prototypes and mock-ups that can inform you of holes in your plans.
- Test and polish everything.
- Present your concepts to the client and revise based on reaction.
- Polish and test more.
- Once you have done everything you can think of, you unleash your experience on the world and hold your breath to see how the project lands.
I had never experienced working on an open source project before joining the Babylon.js team. Everything I had done had either been proprietary or was intended to make a splash on the audience. Surprise was our ally and keeping the curtains closed in the process is how we made our living.
As the first and only visual designer working full time on the team, I stepped into a culture where everything was immediately put out in the open for the Babylon.js community to use and react to. There was nothing done in secret and nothing was a surprise to the community. The team would talk about their plans on the community forum and elicit feedback to help them land how the features should work.
To say this is a major shift in my perception of creation is an understatement. Not only am I allowed to let our users look under the hood, that is the expectation. We don’t isolate ourselves in a room to think of new features and guess at what our users may want only to spend months designing them before they are put to code. The Babylon.js team works much faster than that. Features can spring up from community requests and be well into the development process before I can even wrap my head around them completely. What have I gotten myself into?
But the beauty of this system is that it is ultimately very freeing. Originally, I had a hard time letting features out into the wild before we had polished every edge of the visual presentation. But what I have come to realize is that working in an open format like this allows us to create stronger features. Babylon.js has a couple of releases a year and these are the points at which the new features are finished and stable. Before that, every new feature is readily available to use in our preview branch. This branch changes a lot, often several times in one day. But what I see in the community is that most users just live in our preview branch. They are always grabbing the latest new feature and giving it a workout to see how it can help their projects.
Sending out features to be used early in the design process allows us to see how the community uses it or where they contribute code back to the feature to make it better. Seeing how the end user engages with a new feature is only one-half of the benefit to designing open source software. The other is that I am able to see the feature working in context early in the design process and can test in the real environment without needing to create a whole prototype framework. These prototypes usually have a lot of hand waving in parts of the design because rebuilding all the functionality of the live environment does not make sense. This hand waving can have the side effect of masking holes in the design that will be exposed when it hits production code and churn engineering resources with changes and redesign. Being able to see a preliminary design in context and have full integration means we can take slow and deliberate steps toward the finished product without huge leaps of faith and bets that we won’t waste resources.
Working this way does require a strong tie between designers and engineers with an understanding that we will go back and polish, add to, or revise a feature design along the way. The compromise is that I loosen the reins on showing a design in its early and ugly state while the engineers know that they will need to come back and touch the code a few times as the design evolves. I am extremely fortunate with the Babylon.js team as everyone shares the same understanding. We all want to make the best tools available for our users and leverage this open source design method to iterate out in the open and make exactly what our users need.
While designing for open source software was initially a very uncomfortable place for me, I really appreciate the freedom and flexibility of bringing our community along for the ride. There are some things we do that are still a surprise for our users like our rebranding effort or our new release demos but most of our work is done in the open. For the most part, I find that hearing how all of our users are engaging with a new feature on almost a daily basis leads to a stronger solution that fulfills the needs of the customer.
Working in the open was never something I saw coming in my career, but now that I have opened that door I never want to close it again.