Our way of working
The Thinkmill Method
We’ve had the privilege to work on an amazing variety of projects over many years, exposing us to many and different kinds of teams and problems. Over time, we’ve developed a method for product development that helps us build compelling software.
This is the teaching material of this method. We use it as a resource when training Thinkmillers one-on-one in the principles, culture, and practices of how we work. It’s a living document that evolves as we evolve our practice. We’re sharing this method in the hope that it’s of interest, and maybe even useful.
What is the Thinkmill Method?
A way of approaching software design and development that increases the likelihood of shipping good and compelling software, while maintaining the wellbeing of the people involved. It focuses on team dynamics, silo-breaking, and shared responsibility as foundational for cultivating unified and productive teams.
It is not a framework, prescription, or a paint-by-numbers affair. It assumes (and requires) competent craftspeople who care deeply about the problems they’re solving and who know how to wield the tools of the trade. Like all good professional tools, there are few guard rails, and lots of sharp bits.
The Thinkmill Method comprises:
- Fundamentals – the principles and mindsets that underpin the Thinkmill method
- Team structure – the way we organise ourselves
- Playbook – the tools and processes for which we reach
The Thinkmill Method in a nutshell
Fundamentals
The basic principles and mindsets that underpin our approach.
Design is a team sport
Design is a conversation and good-faith negotiation between multiple practices, not something that “designers” do, and others wait to build. We use “design” in the holistic sense, encompassing everything that contributes to a positive user experience outcome – interface, database, API, pricing, etc. Good and compelling products result from successfully integrating these practices into a coherent and compelling whole.
Design artefacts are an abstraction
We use abstractions (interface designs, UX wireframes, entity relationship diagrams) to communicate and collaborate across practice areas. However, abstractions only approximate the actual product and user experience. As early and much as possible, work with or close to code.
Schema-led
We follow a schema-led approach in our work. A schema (conceptual, database, or API) describes the domain in terms of objects and their relationships, and is an especially useful artefact that builds shared understanding between practice areas. When defined in code, it serves as a shared source of truth, allowing UX/UI, front-end, and back-end work to proceed independently with confidence.
Work in the open
By working in the open, it’s much easier to stay in sync, and it enables the design conversation to take place with less friction. Working in the open means actively and regularly sharing your WIP with the team, and stakeholders. Doing so reveals gaps, mistakes, bugs, and dead ends, and it’s a highly efficient and accessible way to communicate context and status.
Stay synced
By working in-sync from the start, building shared context and understanding together, and not getting too far ahead of each other, cross-functional teams will make better trade-offs and fewer compromises.
Build for user-experience outcomes
People use the software we make. Therefore we hold positive user-experience outcomes to be the primary and shared goal (see design is a team sport). We frame goals in UX terms, and we make decisions with respect to and with awareness of their impact on the users’ experience.
Bias towards code
A significant amount of time can be spent pushing pixels around a screen. Jump into code as soon as possible to validate assumptions and get a feel for how the real user experience is shaping up. Working with code will reveal blindspots that lurk in design artefacts.
Check your blindspots
Similar to cars, our design tools have blindspots and limitations of which we need to be aware. For example, it’s hard to design for performance in Figma, a11y in a product spec, or for usability in a database schema. The team looks out for each others’ blindspots and ensures all facets of software (usability, accessibility, performance, desirability, etc) are considered and designed to create good and compelling products.
Mind the gap
Gaps exist at the seams which join the practice areas. For example, a gap may exist between what the interface design calls for, and what the API currently allows — or, what the business wants, and what’s possible given an existing back-end. In practical terms, gap finding involves habitually comparing UI or UX spec against API or back-end ones, and looking for gaps between the two. Gap filling is simply the collective act of closing a gap, typically by changing a user interface, changing the system to enable it, or changing the scope/requirements.
Team structure
This is how we might organise a team of practitioners that follow this method. This is a general picture. Keep the principles, but it’s ok to vary the people and labels as needed.
There are many kinds of problems and multiple ways to organise people around them. This section is intentionally broad, leaving the specific team to apply the appropriate fundamentals.
Core solution squad
The core group is a cross-functional team made up of leads from multiple practices. Typically, this takes the form of a trio or quartet representing product, design, engineering, etc. More complex undertakings may call for additional and more specialised individuals.
The core solution squad “journeys together” – that is, operates as a high-sync partnership.
The objective for the core squad is to achieve a shared and cross-functional understanding of the problem, constraints and opportunities, and ultimately, the solution.
Core solutions team, working in a co-design partnership, builds shared understanding over time.
Delivery squad
The delivery squad helps do and deliver the work. Depending on the size of the project or team, the delivery squad may just be the core solutions squad wearing different hats. This squad is unblocked and empowered by shared artefacts, and the shared understanding that they convey.
Shared understanding artefacts
As the team works together, the emerging shared understanding is documented in a range of artefacts as appropriate, which help to get and keep the group in-sync and aligned throughout.
The core team should use any and all tools and processes to help create shared understanding, but some common, particularly useful ones include:
- Product & customer spec
- Core concept modelling and/or Data modelling
- Schema definition
- Activity mapping
- Route mapping and/or process mapping
- User flows and/or wire-framing
Playbook
The Thinkmill Method playbook is a library of practices, with guides, examples, and prior art, that aims to serve as a reference for teams working in this way. It aims to be highly practical and applicable, without being prescriptive.
Coming soon
We’ll be publishing our playbook over the coming months, starting with the core practices. Subscribe below to get updates when we publish new resources.
Subscribe for updates
We send a newsletter from time to time when we publish new resources, articles, and open source projects on the topics of software design and engineering, design systems, and process & practice.
Related resources
Boris (Thinkmill’s CEO & Head of Design) spoke about the our methodology at the Delighters meetup in Sydney, Australia. At that time we toyed with calling the method “Antifragile”, but changed our mind later.
news
Boris was a panellist at Design x Engineering Co-Lab
Our Co-CEO, Boris Bozic, was one of three expert panellists who spoke at the first Design x Engineering Co-Lab on Design Systems, in Sydney. We’re proud to have his serious design systems knowledge at the helm of our design-engineering practice. Thank you for the words of wisdom and experience shared by the other panellists Dominik Wilkowski and Maria Christley; and to Morgan Fletcher for MC-ing the event, and Atlassian for hosting us with an impressive pizza spread. We’ll be there for the next.
article
What we learned applying the Thinkmill Method to a complex accounting app
We recently wrapped up delivery of a feature for a client’s complex accounting app. The project presented a valuable opportunity to battle-test our thinking around how we build products. We implemented a range of activities and techniques from the Thinkmill Method, and came away with valuable insights related to where it shines, what’s needed in order for it to do so, and how to improve it going forward. Here‘s what we learned along the way.
· 7 min readarticle
Visualising a schema-led approach using FigJam
Thinkmill uses a schema-led approach to design, which involves building visual representations of data structures to help teams understand the underlying relationships and dependencies. Recently, we used the Schema Nodes FigJam Widget to visualise the schema and relationships.
· 1 min readarticle
How we think about research at Thinkmill
The true goal of conducting user research is to test the assumptions that have been made, and bring confidence and clarity to a project and its vision. However, organisations often perceive research as a long, drawn-out process that won’t bring value for months. At Thinkmill, we focus on designing user research that can be acted on immediately and will make a substantial difference to your team today.
· 4 min readarticle
Route Map - a lightweight schema for defining a UX blueprint
A Route Map is essentially a lightweight URL schema for an app or experience. This is how we use it.
· 3 min readarticle
Shared understanding: why it’s important and how to fast-track it in your project
Tips and tricks to get your team’s collective intelligence buzzing in product development.
· 8 min read
We’d love to work with you
Have a chat with one of our co-founders, Jed or Boris, about how Thinkmill can support your organisation’s software ambitions.
Contact us