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
- Playbook – the tools and processes for which we reach
Subscribe for updates
For updates on future Thinkmill method publications, subscribe to our newsletter.
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.
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.
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.
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.
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.
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.
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.
Mind the gap
Gaps exist at the edges of practice areas – either between what an interface design calls for, and what the API currently allows; or what the business wants, and what’s possible in the back-end. Gap finding involves habitually comparing the UI or UX spec against API or back-end ones, and spotting the difference. Gap filling involves either changing the interface, the system, or the scope/requirements to ensure parity.
Playbook
The tools, ceremonies, and artefacts we use when working together.
Activity Mapping
Activity mapping is a way to dynamically capture, and work on, product requirements in a format that’s more useful than a static document.
· 3 min readCore concepts
Core concepts are an expression of a project‘s underlying data model and relationships, translated into a written format that the team can build an aligned understanding on.
· 4 min readDACI
Created by Atlassian – DACI is a framework that helps delivery teams make effective and efficient group decisions.
· 1 min readDesign Ethnography
Adopted form the world of Anthropology, Design Ethnography is a research method that captures everyday life to discover interesting and unseen user experience opportunities.
· 3 min readFunctional wireframing
Functional wireframing documents how the various pages and interface elements of an app or website need to come together in order to support the user.
· 4 min readKickoff
The kickoff is a document creation ceremony that serves as a high-level contract between the business and delivery team that captures the goals of the project that helps to reveal hidden assumptions which may cause issues down the road.
· 4 min read
Related resources
Boris (Thinkmill’s CEO & Head of Design) spoke about our methodology at the Delighters meetup in Sydney, Australia. At that time we toyed with calling the method “Antifragile”, but changed our mind later.
article
Storybook and Mock APIs: A Powerful Prototyping Combo
No back-end? No worries! In this tutorial we’ll be using Storybook and a Mock API to create a mocked prototype so we can get on with keeping our stakeholders excited.
· 12 min readtalk
Unleashing Designers with Tailwind CSS
How TailwindCSS can help bridge the gap between design and development, and foster a more inclusive and efficient working environment.
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.
· 2 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 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