Start with the job a person needs to do
We begin by understanding the audience, the task, the environment in which the product will be used, and what a successful outcome looks like. We do not add complexity merely because a feature is fashionable or because another product uses it.
Match the experience to its responsibilities
Company information, service explanations, public guides, and product updates need to be clear, quick to open, easy to share, and straightforward to maintain. Other experiences may require accounts, private records, synchronisation across devices, payments, collaboration, or permissions. Those responsibilities need stronger operational controls and a design that treats private data carefully.
We decide feature by feature. A need for sign-in, for example, brings questions about account recovery, authorisation, abuse prevention, support, and data retention—not only a new screen.
Plan for unreliable connections and real devices
We consider smaller screens, limited data plans, older devices, accessibility settings, and interruptions in connectivity. When an offline option is useful, we explain which previously opened information remains available and which actions still require a connection.
Keep security proportional to the work
We minimise the information we collect, avoid storing secrets in public interfaces, and use access controls wherever private information or privileged actions are involved. Browser-side checks help the experience, but they are not a substitute for server-side permission checks when a product handles protected data.
Release what we can support
We prefer a smaller, verified first release over a long list of untested promises. We publish the current product status, test the important journeys, gather useful feedback, and expand the scope when the need and maintenance plan are clear.