Projects across apps, websites and stores
The projects below describe the kinds of work we take on and the problems they started with. We've written them as summaries rather than pitches, so you can judge whether the shape of the work matches what you need. Client names and specific results are shared in conversation where we have permission to discuss them.
What these projects have in common
Most started with a gap between what the business thought it was offering and what users could actually find. A store with strong products and a checkout that lost people at the delivery step. An app with good features and navigation nobody could predict. A service business whose website described the company instead of answering the questions customers asked on the phone.
The work is usually less about adding and more about ordering, clarifying and removing. That pattern shows up in every engagement we take, whether the deliverable is an app, a marketing site, a store or a design system, and it is the first thing we look for when we open a brief.
first release, both stores, same night desk
Mobile app work
Typical app projects involve taking a defined feature set from concept to a first release on iOS and Android. That usually means discovery, a clickable prototype, a React Native build, and a launch plan covering store submission and the first round of fixes.
We've worked on products where the main challenge was onboarding, where the app had to work offline, and where the interface had to follow platform conventions closely enough that users didn't need to learn anything new. Apple's Human Interface Guidelines come up in review more often than people expect.
What we take on in an app build
- Onboarding that explains itself screens cut, not added
- Offline behaviour designed up front sync rules, conflict states
- Platform conventions kept iOS and Android, natively
- Store submission and first fixes review notes handled
Website and marketing site work
Website projects range from content-led business sites on WordPress to marketing sites built in Webflow where launch speed mattered. The recurring theme is structure: fewer pages, clearer paths, and content written for the person reading it rather than the search engine indexing it.
Where a client has an in-house content team, we build the templates and components so they can publish without needing a developer for every new page.
templates handed over with the site
Content-led business sites
WordPress builds where the page set is planned around the questions customers actually ask, not around a list of services nobody reads twice.
Marketing sites
Webflow where launch speed mattered, with components set up so the marketing team can change a campaign page without a deploy.
Templates and handover
Reusable page templates, documented editing rules and a short walkthrough so publishing a new page does not need a developer.
E-commerce projects
Store projects usually start with a conversion problem rather than a design problem. Product pages missing the details customers need. A cart that behaves differently on mobile. Shipping and returns explained in a way that raises more questions than it answers.
- Product pages that answer the last question specs, sizes, lead time
- A cart that behaves the same on every device mobile and desktop parity
- Shipping and returns written before launch flat language, no surprises
- Payment and fulfilment the business can run invoice, bank transfer, pickup
We work on both platform stores and custom front ends, and we set up the payment and fulfilment methods the business can actually run, including invoice and bank transfer, cash on delivery, and card payment taken in person at pickup. Nothing goes live that the team cannot process on a normal Tuesday.
UX/UI and design system work
Some engagements are design only. A product team with developers in place but no designer, a business rebranding and needing its interface brought in line, or an organisation that has grown several inconsistent products and wants a single component library. In these cases we work in Figma, build shared libraries, and hand off with documentation that developers can act on without a follow-up meeting for every screen.
what usually comes out of a design-only engagement
A component library with named states, spacing rules and content guidance, plus a short written handoff that explains where a developer is allowed to improvise and where they are not.
library reviewed screen by screen, on the wall
Accessibility and remediation projects
We take on audits and remediation for sites and apps that have already been assessed against WCAG. Common findings include contrast failures on form elements, missing focus indicators, headings used for visual size rather than structure, and interactive elements that can't be reached by keyboard.
Remediation is usually faster than clients expect once the findings are prioritised, though some issues touch layout and require design changes rather than code fixes. We work through the list in order of what blocks people, not in order of what is easiest to tick off.
Public sector and regulated work
Projects with procurement requirements, published standards or public accountability tend to be more documented than commercial work. The Australian Government Design System is a useful reference for these engagements, and not only for government clients: its component patterns and content guidance are unusually clear about what makes a service usable.
If your project has to satisfy an external standard, tell us at the start so it shapes the design rather than being checked at the end.
How we talk about results
Where a client has approved specific figures, we'll share them directly. Otherwise, we describe what changed in the product and let you ask the follow-up questions that matter to your situation. If you want to know how a project like yours was actually run, ask us in the first conversation and we'll walk through the decisions rather than a summary slide.
Judging whether the shape of the work fits
The quickest way to find out is to describe your situation: what the product or store does now, where people get stuck, and what has already been tried. We'll tell you plainly whether it matches work we do well, and what a first phase would look like if it does.
Start with a brief
Tell us the feature set or the page set, who it is for, and the date you are working toward. A paragraph is enough to begin.
Start a briefAsk about a sector
If your project carries procurement rules, published standards or an existing accessibility assessment, say so early and we'll scope around it.
Ask about a specific sectorStudio
Suite 1, Shop 1, 7F Parkes Street
Harris Park, NSW 2150, Australia
Monday to Friday, 9:00 AM – 6:00 PM