What I Learned About Building Software From My Creative Director

From the beginning, we knew that we wanted to do things differently at Lab 201 than the way we were taught by the years spent at industry jobs. We build software, mostly, and we wanted to tear down all the walls between the creative and technical parts of our process to better allow for flexibility and problem-solving and efficiency and rapid iteration. We occasionally see this in industry, but as an example, in the consumer tech world, Apple is famous for embedding a more user experience and design focused approach to engineering and product building, and what we wanted to embody is sort of the natural extension of this kind of approach, where both the creative and technical sides are first class citizens in the realm of building really cool stuff together.

So when I started working with my partner, cofounder, and creative director, I was prepared to learn a lot about the creative process. And in learning about that, and understanding and internalizing it, I hoped to be able to better integrate our shared processes into a cohesive whole. My sense was that the creative and technical sides came from very different places, and was prepared to be challenged to understand both. But what I was less prepared for, in what now seems less surprising in retrospect, was how much I learned about my own technical processes by studying design.

Process as a tool

There's some kind of collective mythos about the creative process, wherein we imagine that a real, true creative just kind of sits down at a desk, furrows their brow intensely, ruminates a bit, and then plops out a beautiful, polished, final product. This always seemed a bit suspect, so we talked a lot about process, and about where it comes from, and what it means for creative output, and how it drives our work forward.

Throughout these discussions, what I've learned about my partner's design philosophy is this: there is no single creative process. The idea of a unified, singular creative process is a part of the myth, and more specifically, that all of the different processes that we talk about are all just tools in the toolbox for creating great work. Sometimes that means starting with pen on paper, sometimes it means digging into discovery, sometimes it means team brainstorms or revisiting requirements or exploratory research. One that works well as a starting point for one project might be the wrong tool for a different project, and it's our responsibility to know how to use the right one at the right time. Sometimes it's easy to get overly attached to a process that's familiar or comfortable, but eventually, you find yourself in a situation when the right tool for the job is different than the one you happen to be holding.

This really resonated with me, and I flashback-ed through all the engineering teams I've been a part of that ended up treating frameworks themselves as the end goal, something immutable and inflexible, even at the cost of the team or product.

And even if it seems obvious, it's hard to avoid. The dangers inherent in any overly-dogmatic implementation of a framework or tool or process probably should be self-evident, but sometimes it really is a matter of seeing the forest for the trees. In engineering, Scrum tends to be a great example of the dangers of framework dogmatism, partially because it's so widespread, and partially because it's so easy to implement an unproductive Scrum workflow. Maybe the formally structured nature of Scrum is partially to blame, which makes it easy to rely on performance metrics like story and ticket estimations as a way to measure team success. The obvious issue, though, is that team success should be, and has to be, measured by things like how much value the product delivers value to its users. But because this is a very hard question to answer, and because it exists adjacent to much easier questions to answer, namely, how much code was written or how many estimated points were completed this sprint, we end up defaulting to the easier metrics, which invariably leads to the comforting but shallow equivocation of productivity to success.

I see this in code linting and styling as well. Ultimately, good code is clear and maintainable. That's it. That's the goal. And most of the time, code that is consistent is also clear and maintainable. But when a religious adherence to a style guide ends up prioritizing the guide itself over clarity, making the code less clear or less easy to read, this is absolutely the point at which to remind ourselves that the tools created to help us accomplish a wider goal are just that, tools, and that we have to be intentional about the things that are actually important, instead of lazily defaulting to the tool as a shallow heuristic of the bigger picture.

Purpose and Problem-Solving

There's sometimes a misunderstanding when it comes to design that the job of design is making things look pretty. This is a mildly annoying at best, but more often than not, is actually something that gets in the way of the real design process. Because, at least for the kinds of design we do, design is about much more than that. It's about balancing functionality, as well as form, and considering and understanding users' workflows and intentions and expectations, built on top of solid research and grounded in a firm understanding of the problem space and project limitations. As my partner often puts it, "design is 90% science, and 10% everything else." And it's true. If we were artists, then we'd be able to create something that we personally think is beautiful, and wouldn't have to worry if everyone gets the same message. But in design, we do. Design has to care, because design has purpose. And if our work doesn't bring everyone to the same place, doesn't deliver on the promise to users to inform or teach or provide some kind of functionality or value, well, then that's bad design.

So when we take on projects, the first thing we try to do is make sure we are all on the same page about what problems we are trying to solve first. Almost certainly, the primary problems aren't simply "we want something pretty," but something more like "we need to track corporate expenses easily." So when we come back and present something at the design stage, we always start by reframing the intention and purpose of the brief to ensure that we are working towards a solution to the real underlying problems. This is helpful because it frames the conversation around how the problem and potential solutions relate to each other, and we can turn subjective feedback like "I don't like the color here" into more objective and productive discussions based on purpose, like "We use color here to highlight the available primary user actions. What other ways can we direct user attention to these primary workflows?" In this way, it becomes clear what the objective intention is behind, at what may seem at first glance, like subjective artistic decisions.

Software engineering also comes with its own mix of functional purpose and subjective decision-making. There is, admittedly, much less disconnect in terms of what people think about the role of engineers and what we actually do, as in a design-as-art kind of way, but it does exist. Ultimately, presenting engineering and technical or architectural proposals in the context of the original problem space helps us explicitly walk through the decision-making process with clients, and also gives us an opportunity to call out the trade-offs inherent to making decisions in the way we're proposing. Starting from the problem tends to center discussion around the "why," which gives a more comprehensive view of the "how" and the "what" that comes after.

Finding a Common Language

Design, and communicating about design, especially to non industry people, has an additional layer of obscurity because there is some inescapable part of talking about visual design that is subjective. Not only in the philosophically unsolvable "is your red, my red?" kind of way, but also in the way that we use words to map to different visual ideas. A logo that one person says is "modern" and "friendly" might be "retro" and "stoic" to someone else, and it's difficult to standardize the kinds of language we use to talk about these things across individuals. The way that we usually handle this at Lab 201 is to start with the visuals, and work backwards to building a shared language that we can all use to communicate together. In practice, we'll sit down with clients at project onset, and walk through visual references together, allowing them to talk through what they're seeing and how they they would describe things, and as we do, we start establishing the common language we'll continue to use throughout the rest of the project to ensure everyone is on the same page.

In engineering, by contrast, we tend to take a lot of the technical and formal jargon and accept it as part of an objective backdrop that assumes no need for common contextualization or discussion. For some technical concepts that are well defined or governed by a universal spec, that usually works fine, but the importance of context in engineering teams is unmistakably there too. The number of times I've heard things like "python is slow" or "MongoDB is fast" without a common understanding of what "slow" or "fast" means in the specific context of the project is alarmingly high, even in large, established teams. Taking the time to contextualize and develop shared understanding within a team allows everyone to move better and faster together, working towards the same goals with confidence.

Inspiration

We talk about inspiration a lot, and about what drives us to continue to innovate and create cool stuff. And one thing that I've realized working with my design partner is that inspiration is something that we have to allow ourselves to find. I used to think that inspiration was exclusively something that happened to you, in a sort of ready or not, involuntary, reflexive, divine-strike-of-lightning kind of way. I believe this kind of inspiration does exists, but more often than not, it's a quiet kind of inspiration, the kind that makes you go, "huh, thats neat," something that makes you think just a little bit differently about a small piece of the world.

A lifetime ago, when I was a freshman studying music at Berklee, I remember thinking that every single performance I heard was mind-blowingly awesome. All of it was amazing. I was inspired and energized by every concert or recital or peer jam session I sat in on. But sometime by the end of senior year, I think I had lost some of that willingness to be inspired, and some of it was replaced by a driving competitiveness, a "I could do that better" or "they messed up there" kind of thinking that didn't allow the proper space for inspiration.

So we've made it our goal to be as open as possible to this quiet kind of inspiration, too. And what I've discovered in doing this, in being open, is that this is as much a creative skill as anything else, something that we have to practice, like lifting weights or practicing an instrument, that keeps us sharp and ready for the next thing to come along. The more you look for inspiration, even the small, everyday kinds of inspiration, the more you happen to find it. And maybe this is one of those things that's just so obvious that it gets somehow obfuscated by its proximity to expectation, like looking for your glasses when they're already on your face, but to me, this is also one of those improbably convenient and beautiful truths about the world we live in: inspiration is everywhere, as long as you're willing to see it.

In Other News

We are incredibly pleased to announced that Lab 201 has been certified as an verified agency with DesignRush, one of the leading creative agency marketplaces and organization behind the prestigious DesignRush Design Awards. We have a lot of very cool stuff coming down the pipeline, and we can't wait to be able to share soon.