All fixed set patterns are incapable of adaptability or pliability. The truth is outside of all fixed patterns.
Bruce Lee

As software engineers, it’s in our blood to automate and codify as much as we possibly can. The temptation to do so with process is not any different. However, in our experience, the proverbial “one true way” does not exist. Requirements, scope, and overall goals are unique for each project. And it’s important to be aware of this when approaching a project. We’ve found that by remaining flexible, we are best able to accomodate the specific needs of the client.

Despite our apprehension towards specific doctrines, we have established a few guiding principles that drive our work:

  • Embrace constraints

    We believe that constraints are a good thing. They guide us towards an objective solution. In our case, we embrace the constraints of our medium — the web. We understand its strengths and weaknesses. This helps us deliver the best end result.

    What happens when fundamental constraints are not respected? Frank Chimero does a fantastic job speaking to these consequences in his piece entitled The Web’s Grain:

    “Listen bub,” I say, “it is very impressive that you can teach a bear to ride a bicycle, and it is fascinating and novel. But perhaps it’s cruel? Because that’s not what bears are supposed to do. And look, pal, that bear will never actually be good at riding a bicycle.”

    This is how I feel about so many of the fancy websites I see. “It is fascinating that you can do that, but it’s really not what a website is supposed to do.”

    Most of the solidified techniques about our practice come from the natural ways of the web that have been there since the start. The answer is right there in front of us, in the website itself, and each step we take away from its intentions makes our creations weaker.

  • Deliver code over images

    Somewhere along the way, the term “pixel perfect” infected the design community. What followed was a focus on static deliverables (i.e. .psd, .pdf) that were highly polished but severely brittle. How can we expect a static composition to represent our interfaces when the web itself is not static? There is simply no way to account for its variability with static pixels.

    We prefer to get to code as quickly as possible and continue the process of prototyping from there. Seeing the interface “in the wild” with native functionality allows us to make better decisions compared to evaluating it on a motionless canvas.

  • Performance matters

    Performance is perhaps the single most important component of a quality user experience. Countless studies conclude that slow performance leads to reduction in conversions. Essentially, the longer it takes your website to load, the more traffic you’ll lose as a result.

    With the proliferation of mobile devices and tablets, performance has become even more important. With connectivity instability and less computing power, these devices in particular require performance-driven engineering to maintain fast render times. Unfortunately, performance is often overlooked as a priority.

    We prioritize performance from the very beginning. Given our propensity to deliver live code early in the lifecycle of a project, we have an advantage that many do not. We are able to assess potential bottlenecks and solve those problems early, before the project takes its final shape.