If we’ve ever worked together on a project, I often use analogies for home building.
Building anything whether it be small or big is a deeply rewarding human experience affirming our abilities to construct something meaningful that gives back to our greater community. If you can build one thing, you could likely build many things.
What makes building insurmountable is not knowing how to build. Everything looks like a large boulder the size of a small boulder preventing us to know where to start. We can strive to build something like a home for ourselves knowing what makes a home — a solid foundation, walls that hold warmth, windows to observe the outside world — and be waylaid by a lack of knowledge in how to build all those things together as something tangible. We can hazard some guesses that certain actions must happen in order before other actions can happen. Money for materials that meets our bar of quality and acquiring permitting for these things to happen in sequential order is likely involved. We can likely get far in draw a picture and layout of we imagine this space should exist almost as if it were plucked from the realm of possibility then refined to a crude sketch.
Professional architects and construction workers exist to guide us through this process shepherding us from the realm of imagination through ambiguity and eventually creation. While we can defer to them, ultimately our innate sense of creating kicks in giving us some sense of ownership. I am not a home builder and I am assuming you aren’t either, but we can distill some idea of building a home from living in one and extend that knowledge with curiosity. If you can build one small thing, you can build a large thing from many small things. That feels like how a home would be built — a concrete foundation is poured, wood beams form a skeleton, a roof is placed on top. All of these things had be to built or gathered individually. Even adobe homes — a structure of mostly uniform material — are made from hundreds if not thousands of individually dried mud brick.
Building is a superpower unaware of the limitations you posses. Careful and thoughtful planning annihilates barriers placed in our way.
A Strong Foundation
Operating from a set of concrete truths gives us a shared language for building many things with repetition.
We know a home must be built on something sturdy otherwise it may sink from ground shift, crumple in a flood or collapse in an earthquake. The same can be said for anything else. Is the environment we are in in conducive to building? If not, how can shore it up to support any ambiguity in the future?
Typically, a poured concrete foundation that can support multiple tons of weight and material is ideal for a home but may prove inadequate for a taller building. A foundation doesn’t need to be immutable forever and support only one type of structure — an office building begs for a more robust and deep concrete and steel foundation — but careful planning into the future assures our foundation can support our home of the current and expansion in the future if we want to house family members and guest friends.
In practice: Code doesn’t need to do everything it is ever intended to do right from the start. Investing time in the euphoric journey of perfection dooms the good enough from being iterated in to a more idealized version of its true self. Planning for the future can inform what we’ll eventually need to support in a feature set. When thinking about the future of localization of Notion’s Marketing site, it supported only English and Korean content at the time. Nothing was wrong with how the site supported changing between two languages — this functionality had supported Notion’s launch into Korea and would sustain its presence for users there.
However, to scale beyond one more language would introduce unneeded repetition in code resulting in larger checks for a user’s language that could leave edge cases where the wrong content would be served. We didn’t need to rip out everything and start over from scratch, but rather optimize some areas — perhaps cracked appeared in our concrete foundation — and expand the foundation base. Time up front on this foundation allows Notion’s Marketing site to be read in any language content is written for happening with a few declarative checks vs dozens and dozens of spot checks that would be easy to lose track of. We reduce the risk of edge cases and remove the pain of localizing content in the code base for engineers today and the future.
We often romanticize homes from different time periods such as the San Francisco Victorian, Brooklyn Brownstone or Eichler tract home. However, we are not beholden to the building techniques of those times. Earthquakes are an occurrence along the United States’ Western Coast that have devastated structures of all types. As the events occur, we gain a better understanding of tectonic forces that topple our man-made creations.
Simultaneously, the untouched Victorian home of a century ago still standing hasn’t been imbued with this knowledge as a sort of gained immunity through infection against disease — it simply exists through chance perseverance — but we can make the same type of home again with the power to withstand a quake. We should continuously discover how things are built in response to knowledge gained since we last built the same thing. Repetition in process does not mean a calcification of learning.
In practice: When starting a new project or modifying an existing one by adding new features, looking back on what has been done and evaluating if it makes sense is always a great first step. Perhaps a new technology has come out that makes what we want to do much easier — say building a responsive grid — that was unavailable years early causing a lack of engineer resourcing to scrap that feature. Perhaps we’ve discovered a new way of working together that mitigates pain points of such a project we’re undertaking and they’re worth using going forward. Giving yourself space and time to experiment and take risks to discover a new method of work or learning the hard way something cannot work is valuable and worth investigating then disseminating to your fellow teammates.
Building is a fulfilling activity. We can apply the ideals of home building to chip away at our large boulder of work into a smaller boulder.
Share status as early as possible
A wood frame being put up may not mean much for an interior designer but knowing the dimensions of a space can help plan for furniture and decoration.
- Concrete designations and ownership lets us build our blocks in tandem as much as possible
- More “Oh, I have thoughts on this!” Feedback that can derail progress, but really, these feelings will always be there. We’re lowering the threshold to raise questions with great ramifications
- Camaraderie forms when we see our team mates persevere against the odds to construct something magical
In practice: How you use your craft to build can appear like an act of mystery or conjuring of magic. It can be unclear when something should happen let alone why, especially when working cross functionally. The moment when you pull back the curtain to reveal your new wonder can be full of unending euphoria but should be reserved for large product launches and public updates. Hiding behind that curtain robs your teammates of understanding how your contributions make something come to fruition and where their work fits in. It also robs them of the learning experience in how you do what you do best.
You can use status updates to shepherd all involved and to evangelize the work you’re doing. If you’re building, say a Help Center, translated content can stress test the layout of what has been designed. Broadcasting when translated content has been brought in can help your fellow Designer and Copy Writer determine if there’s layout issues that need to be resolved from content or some verbiage that no longer makes sense in the context its presented in — maybe side-by-side a product demo video. I’m sure these two would appreciate knowing when they can participate in their part of the process as soon as possible when you’ve unblocked them.
Testing Early And Often
Something can always go wrong. Even if we do everything to the best of our abilities, the elements can strike. It wouldn’t hurt to test how water proof a roof is before the rain comes and destroys what has been done.
- Pull forward design and validation reviews to mitigate future concerns
- Open up more “What if...” questions as things take form
- Stress test with as many variables as much as possible
In practice: Assuming anything that can go wrong, will go wrong isn’t an alarmist mindset — it’s just good planning. Forcing yourself to evaluate what you’ve made at the soonest possible point it can be tested with internal reviews, bug bashes, automated testing and user feedback averts the pain of going too far down one path realizing you’ve gone in the wrong direction and certain doom awaits you at the end of this journey. Testing early pulls forward the anxiety of patching and fixing in the 11th hour in a diluted form that’s much easier to digest. You’ll always have feedback for changes. You’ll always run into something going awry. Preemptively planning for risk gives you much greater clarity on how to move forward in the worst case scenarios.
If we’re continuing to build a Help Center, we know translated content is a large and recurring variable that will either plug in nicely or cause layout issues in non English languages. It makes sense to have this content present (or at least mocked content) while building to reflexively stress test UI as engineers build it. Having this done in a sandbox that Designers, Project Managers, Copywriters, teammates and all interested participants can watch is a light form or distributed quality assurance. We all become much more vested in the shipped version as we get our hands on it and make it familiar through repetitive use. Aside from disaster planning, early testing helps us explore greater possibilities and rethink features we had some conviction on but find no longer stand on their own. Should search options have a filter? At what point should we have pagination because this page is getting quite long and unreadable? I can’t seem to remember my spot on an article, maybe a bookmarking function would help? Giving these questions the time and space to blossom refines what we make and takes potential frustration out of what’s shipped to a user by solving preemptive pain points.
Showing wear against the elements gives us more of an indicator that where we are is a safe harbor against a gathering storm. Some concepts or things built may reach a natural end yet its impact may linger on people who have used a thing. Most assume longevity is a non-malleable state that does not suffer the effects of change. At minimum, learnings can be reused as what not to do.
In practice: A benefit of Software is malleability. If an App makes an impact on us, it will survive in the cultural ether as a cherished memory. Longevity in the digital realm should not be interpreted as an unmovable object impervious to its environment. Rather, the ability to adapt to changing needs recognizing that people change, wants and needs change — everything changes — is a kind acknowledgment of the world we participate in.
What can longevity look like? It can be as simple as a product roadmap for planned updates with clarity intense in the near term and less clear as we look to the future paired with the intent of fusing our conviction with ever changing wants. It can be a framework for code, content or a brand guideline giving us concrete blocks to build our home upon and knowing those blocks may change form — perhaps a technology is optimized our brand guidelines are refined — but they are forged to withstand buckling pressure and provide a safe base. Longevity should not cater to a stale experience pining for a mantle of eventual nostalgia. Longevity should not enforce rigidity to the point of inaction.
A large system of content made through years and years of updates perseveres in its own way. Moving to a new content management system if needed is guaranteed to be a painful experience and making the decision to carry forth content into a new reading experience is its own source of pain. Perhaps a version frozen in time and functionality makes sense to preserve our library of content for the future while an iteration takes us into an exciting and more versatile direction by taking advantage of new technology unavailable to us years earlier. Perhaps the content is outdated and a clean slate is needed. Maybe an archive and fork makes sense. What doesn’t make sense is forcing the past to persist into the future untouched by our present experience.
Go forth and build 🔨