Our Philosophy of Working

Over the last decade, Thinkmill has organically evolved a set of mindsets that inform how we build products. Together, these mindsets form a Philosophy of Working that permeates our daily practice and shapes the tools we make in open source. This article unpacks our mindsets to give you a better sense of how we bring value to the work of product, and offer a case for adopting them in your own team.

Thinkmill mindsets

Engineering-led

Originally coined by our Design Director Lauren Argenta, engineering-led emerged as a product-building mindset stemming from the fact that most Thinkmill practitioners are engineers.

In practical terms, engineering-led means that we tend to think about how the schema, database, and system architecture are going to be developed as a way of informing and shaping (sometimes constraining) the products that we then end up designing. Engineering-led has been a useful way for us to differentiate our way of working from a design-led one, which you may find in other organisations.

For a deeper dive into the engineering-led mindset, watch Lauren talk about how we design in an engineering-led way at ReactConf AU.

Code is the source of truth

This mindset is especially important to the work we do in design. It conveys the idea that in a world of abstractions, converging on code as the primary source of truth — wherever possible — is the least problematic way to build products.

Practitioners who don’t subscribe to this approach might be of the opinion that the artefacts of a design tool like Figma represent the source of truth. In our view they make for a brittle source of truth because they’re a static picture of the dynamic thing that will exist as code running on the internet.

We’ve developed the mindset that as technical designers, all the stuff we’re creating and expressing will ultimately live as code in a repo. So we should work with this reality and limit the abstractions by understanding, referencing, subscribing to, and contributing to – the code. As much and as soon as possible.

As an example, our goal is not to maintain perfect synchrony between Figma components, and the components in the code repository or Storybook; but rather to be comfortable using and improving those components in their native context.

Schema-first

We often talk about schema-first as an extension of the engineering-led mindset. In some ways it’s an expression of how we learned to build software. We found that by describing the data model or a schema for an application first, it serves as middleware to align a product’s back-end infrastructure, API, and front-end needs.

If the practitioners involved in delivering those aspects can converge and collaborate on the schema – it ends up being a useful way of aligning those different practices. Such that you can then go away and work relatively independently and come back to the schema when the need to update shared understandings arises.

Keystone is an open source framework we maintain that’s predicated on this schema-first way of working. With Keystone you literally write schema and it gives you back a database, GraphQL API, and Admin UI.

As opposed to starting with the interface or elsewhere, we strive to start with schema-related questions as much as possible. These questions look something like:

How do we describe the world that we’re building this product in?
What are the core concepts that underpin this world?
What’s the underlying data model that could capably represent those concepts?

Answering these questions in the form of a schema gives us a really good idea of how to design interfaces and flows that are inherently aware of the data that underpins the user experience. The result is fewer gaps when we’re delivering the thing we designed.

Cross-functional collaboration

We’ve found that it’s really hard (if not impossible) to build good software and products if we’re not intentionally working in a deeply collaborative and cross-functional way. Getting people from different practices collaborating effectively is something we think a lot about. Two extensions of this cross-functional mindset are Design Engineering and Code ♥ Design.

Design Engineering

Invision coined this term in their excellent Design Engineering Handbook. We subscribe to this mindset, and have embedded it as a central concept in the Thinkmill Method. Design Engineering to us is not about filling the gaps between the disciplines of design and engineering, but rather acknowledging and optimising their overlap.

As designers, the more we care about accessibility and API design, the better. As engineers, the more we care about interface quality, usability principles and heuristics, the better. The more we overlap, the more we reduce the likelihood of gaps both technical and experiential. Where technical gaps are what we might miss on the path to delivery, and experiential gaps arise from a designer creating without due consideration of something like performance, or conversely, an engineer building something that’s really performant without considering how useable that performant thing is.

Code ♥ Design

Code ♥ Design is another shorthand for our cross-functional way of working across design and engineering that we’re known for. In 2018 we partnered on a mini-conf to bring greater awareness to cross functional collaboration, so there’s a literal physical expression of our mindset out there.