Design Systems That Keep Every Screen Consistent
A documented set of colours, type, spacing rules and reusable components with every state drawn, so the next screen looks like the ones before it. GullySystem builds design systems for growing products and multi-team development.
What a Design System Is, in Practical Terms
A design system is the agreed vocabulary of your software, written down once so the next screen, the next developer and the next agency do not have to invent it again. It is not a style guide PDF sitting in a shared drive. We deliver it as three connected things your team can actually work from.
Foundations
The decisions everything else depends on: the colour set with names and rules about where each is allowed, the type scale, the spacing steps, corner radii, shadow levels and icon style.
Components
Buttons, inputs, selects, tables, tabs, modals, toasts and the rest, each drawn in every state it will meet in real use — default, hover, focus, disabled, loading, error, empty and read-only.
Rules and Worked Examples
Written guidance on which component to use when, how they combine into a page, what not to do, and examples taken from your own screens so the guidance is never abstract.
How Inconsistency Actually Shows Up
Nobody sets out to build an inconsistent product. It arrives quietly, in ways that look harmless one screen at a time.
Six Shades of the Same Blue
Each screen was coloured by whoever built it. The brand looks slightly different on every page, and nobody can say which blue is correct because there is no list to check against.
Three Different Date Pickers
The same task behaves differently depending on where in the product you are standing. Staff end up learning each screen separately instead of learning the software once.
The New Developer Invents a Pattern
With nothing to copy from, a new joiner builds a perfectly reasonable screen using their own conventions. It works, it ships, and now there are two conventions to maintain.
A Small Change Means Editing Forty Files
Changing a button height or the error colour becomes a hunt through the codebase, so the change is postponed and the inconsistency becomes permanent.
The Design File and the Built Product Disagree
The file says one thing, the running software says another, and neither is treated as the authority — so every small question turns into a conversation between three people.
Two Teams Building Two Products
A second team started a new module in its own repository. It solves the same problems its own way, and the two halves of the product stop feeling related.
How We Build the System
We start from the screens you already have rather than from a blank palette, so the system describes your product instead of replacing it.
Inventory What Already Exists
We collect every screen you have and count the real variety in it: every button, every input, every colour actually in use. That list, uncomfortable as it usually is, decides what the system must cover.
Settle the Foundations First
Colour, type and spacing are named and agreed before a single component is drawn, because everything depends on them and renaming them afterwards is expensive.
Build Components Against Real Screens
Components are tested by rebuilding your three or four hardest existing screens out of them. A library that cannot reproduce your own screens is not finished.
Name Things the Way Your Team Speaks
Tokens and components take the words your developers and designers already use, so adoption does not begin with learning a new vocabulary.
Write the Rules Down
Each component ships with when to use it, when not to, its states, its content guidance and its accessibility notes, kept in one place your team can search.
Agree Who Is Allowed to Change It
A system nobody owns decays. We set out how a new component is proposed, who approves it, and how an approved change reaches both the design files and the code.
Making It Real in Code
A system that lives only inside a design tool gets ignored the first time a deadline arrives. We specify it so your developers can implement it directly.
Tokens as Variables
Colour, spacing, type and radius values exported as named variables your developers drop into the codebase, so a change is made in one place and appears everywhere.
Specified for Your Framework
Component specifications written against what you build in, whether that is React, Vue, Angular, Blade templates or React Native, rather than in the abstract.
Built on What You Already Use
Where you already run Tailwind, Bootstrap, Material or a licensed component kit, the system maps onto it and constrains it instead of replacing it and throwing away working code.
A Migration Order, Not a Rewrite
Old screens are converted in an agreed order, alongside work already on the roadmap, so adoption does not need a separate project nobody has budget for.
A Session With the Developers
We walk the people implementing it through the system, then review the first components they build so the interpretation is corrected early rather than after fifty screens.
What Decides the Size of a Design System
A system can cover the buttons of one product or the shared language of a whole family of applications. That span is agreed before we begin.
- How many products it has to serve — one web application, or a web app, a mobile app and a customer portal together
- The state of what exists today: three loosely similar screens systemise far faster than sixty built over four years by different hands
- Component depth — a core set of forms, tables and navigation, or that plus charts, calendars, file uploads and rich text
- Documentation depth: something your own designers can read, versus a system an outside vendor can follow unsupervised
- Whether you want design specifications only, or specifications plus a coded component library
- Whether accessibility rules and dark mode are part of the system from the start
If You Need the Whole Design Engagement
A design system is worth building when there are screens to apply it to. Where the screens themselves still need designing, that is the wider service.
Frequently asked questions
Do we need a design system yet, or is it too early?
If one person designs and one person builds, probably not yet. It starts paying when two or more people are making screens, when a second module or product appears, when work is being handed to an outside vendor, or when your team argues about spacing and colours often enough that somebody notices. Before that, a short component sheet is usually enough.
Can you build a system on top of the UI library our developers already use?
Yes, and we prefer it. Replacing a working library is expensive and rarely improves anything a customer sees. We define your foundations, map them onto that library's components, extend it where your screens need something it lacks, and document which of its options your team is allowed to use.
Will a design system slow our developers down?
The first weeks cost something, then it goes the other way. Early on there is a library to learn and existing screens to convert. After that most new screens are assembled from parts that already exist, and the arguments about spacing, colour and button styles simply stop happening.
How is a design system priced?
By how much has to be covered rather than by page count. The main factors are the number of products it serves, how many components are in scope, whether the audit has to make sense of a large existing product, how deep the documentation goes, and whether a coded library is included alongside the design specifications.
How long before the team is actually using it?
Foundations and the first components can be in use while the rest is still being built, and we deliver in that order deliberately. Full adoption across an existing product depends on your release schedule, since converting old screens happens alongside work you already had planned rather than instead of it.
Can our in-house team extend the system after handover?
Yes, and that is the point of it. You own the source files, the tokens and the documentation, and the contribution rules describe how a new component gets added and approved. We stay available for review when a big addition comes up, but nothing in the system requires our involvement.
What do you need from us to start?
Access to your current screens or a demo login, your logo and any brand rules you already follow, the name of the framework or component library your product is built in, and one designer or developer who can answer questions about why things are the way they are. If there are no brand guidelines, we work from what exists.
Tell us what you need.
Send a short brief and one of our engineers will come back to you — usually the same day.
- No obligation
- We reply the same working day
- Your details stay private