Build a custom design system when two or more people ship UI in the same product and keep rebuilding the same components. For most SaaS startups that happens around Series A, or when a second platform arrives. Before then, adopt an existing system. Agencies quote builds from $5,000 to $60,000+, and keeping a system alive takes a team of 2 to 3 people.

‍

This guide draws on Nielsen Norman Group's Design Systems 101, the zeroheight Design Systems Report 2026 (147 practitioners), and the Sparkbox 2022 Design Systems Survey (219 responses). Cost ranges come from agency price guides, which are estimates written by firms that sell design systems.

‍

Adhitya is a Senior UI/UX Designer at Hatypo Studio, a UI/UX design and development studio in Surakarta, Indonesia. Hatypo has delivered 20+ dashboard and SaaS projects since 2021. This guide covers the decisions a SaaS team faces when its interface starts to grow.

• Adopt or adapt an existing system first; Nielsen Norman Group calls adopting the lowest-cost route.
• Build a custom system when more than one person rebuilds the same components, or a second platform or brand arrives.
• Agency price guides put a starter system at $5,000 to $10,000 and a multi-brand system at $25,000 to $60,000+.
• Maintenance is the larger commitment: lack of resourcing is the top challenge for 56% of teams in zeroheight's 2026 data.
• Adoption decides the return: only 7% of systems are fully adopted across all teams.

A design system is a complete set of standards for managing design at scale with reusable components and patterns, according to Nielsen Norman Group. It has 2 parts: a repository of assets and the people who maintain it. A repository nobody maintains goes out of date.

‍

In Sparkbox's 2022 survey, 98% of systems contained typefaces, colors and styles, 95% contained components and 69% had design tokens. A startup version can stop there. Starter packages in Dot2Shape's price guide run 30 to 50 components with basic tokens and a Figma library.

When is it too early?

‍Nielsen Norman Group says a full system rarely pays back on a proof of concept or a prototype that will change, because its benefit is reuse of future design work. If you are still testing whether anyone wants the product, adopt an existing system and put the budget into research.

‍

The same source says systems fit companies that expect years of repeatable design work. Example: a pre-seed product with 8 screens and one designer has little to repeat.

‍

Which signals say it is time?

These are the signals I check first. Each one means the same design decision is being made more than once, by different people or on different screens.

‍

• The same component exists in 3 versions. Audit the product for buttons, tables and form fields. If you find 3 button styles, someone is redesigning a button every sprint.

‍

• A second designer or front-end developer joins. One person can keep a library in their head. Two people need a shared reference, and Nielsen Norman Group says a unified language cuts time lost to miscommunication.

‍

• A second platform or brand arrives. Dark mode, a mobile app or a white-label customer needs theming. In zeroheight's data, 76% of teams use tokens for visual modes such as light and dark, and 63% use them for different brands or products.

‍

• The product passes about 20 screens. One agency guide advises investing early once a product grows beyond 20 screens. Treat that as a rule of thumb.

‍

• UI bugs repeat. Developers fix the same spacing and state issues on different screens. Brad Frost names UI-related bugs as a signal that should fall as a system gets adopted, in a Smashing Magazine interview.

This is the order I use with SaaS teams so the first release stays small and gets used.

‍

1. Audit the live product. Screenshot every screen and group the buttons, inputs, tables and modals. The audit shows how many versions of each component exist and which ones the team uses most.

‍

2. Define tokens first. Tokens are named values for color, type, spacing and radius. The Design Tokens Community Group format reached a stable version (2025.10) in October 2025. It is a community specification and not on the W3C Standards Track. In zeroheight's data, 86% of systems include tokens.

‍

3. Build only the components the next two sprints need. Start with buttons, inputs, selects, tables and modals. Agency starter packages run 30 to 50 components, and I treat that as an upper limit for the first release.

‍

4. Name an owner and a contribution path. One person approves what enters the system, and anyone on the product team can propose a change. In zeroheight's data, 65% of teams already work this way.

‍

5. Write short usage guidance. For each component, state when to use it, when to skip it and what the states look like. Poor documentation was the most common complaint from subscribers in Sparkbox's survey.

‍

6. Review every quarter. Check the 3 numbers from the previous section and remove components nobody uses. Only 16% of teams in Sparkbox's survey tracked metrics, so a quarterly review already puts you ahead.

Nielsen Norman Group describes 3 routes: adopt an existing system, adapt one, or create your own. Cost, time and brand control all rise in that order. Adopting is the lowest-cost route, and the savings from adapting shrink as customizations pile up.

‍

Building your own pays off when your needs cannot be met by an open-source system, per the same article. Check that before you commission a custom build.

‍

A quick test: list your 10 most used components and check which ones an open-source system already covers. If most are covered, adapt that system and spend the budget on the few components that carry your brand. If few are covered, the case for a custom build is stronger.

‍

How much does each option cost?

Published prices vary because agencies scope differently. Dot2Shape puts a starter system at $5,000 to $10,000, a growth system at $10,000 to $25,000 and a multi-brand system at $25,000 to $60,000+. Its timelines run 4 to 6 weeks, 8 to 12 weeks and 12 to 20 weeks.

‍

Other guides disagree. Orbix Studio lists $15,000 to $50,000 in one table, $8,000 to $25,000 over 4 to 10 weeks in another, and $10,000 to $50,000 in its FAQ. Ask every agency which components, tokens, documentation and code the quote includes.

‍

‍Parallel prices design system creation inside an app project at $3,000 to $12,000. It also says building a custom system in Figma adds 20 to 40 hours compared with adapting a component library.

The in-house row doubles Parallel's US first-year cost of $120,000 to $200,000 per designer, which includes recruiting, software and overhead. A developer is extra.

Nielsen Norman Group says creating and maintaining a system is time-intensive and needs a dedicated team, because systems keep evolving with feedback. For larger organizations it suggests at least 1 interaction designer, 1 visual designer and 1 developer.

‍

Real teams are smaller. In zeroheight's data, 28% of design system teams have 1 to 2 people and 33% have 3 to 5. Even so, 61% say they lack enough people, and resourcing is the most common challenge at 56%.

‍

The sample leans large: only 11% of respondents work at companies with 1 to 100 employees. Startup data is thin, so use these numbers for direction.

‍

Adoption is the ongoing cost. Only 7% of teams in zeroheight's data call their system fully adopted across all teams, and satisfaction with leadership buy-in fell from 42% to 32% in a year.

‍

‍Sparkbox's 2022 survey found that 30% of respondents had support, training and onboarding for system users. Among those who called their system successful, 76% did. Budget for training time as well as component work.

‍

For a startup, I would plan for 1 named owner (a designer) plus a developer who builds the code components. Both can be part-time at first, as long as one person decides what enters the system.

‍

What does a first-year budget look like for a Series A team?

Here is an illustration built from the figures above, not a quote. A team with 1 designer and 3 front-end developers picks the growth tier. Dot2Shape's range for that tier is $10,000 to $25,000 over 8 to 12 weeks.

‍

The owner and the developer spend part of their week on handover during those weeks, so count their time as part of the cost.

‍

That one-time spend sits far below the $240,000 to $400,000 for 2 dedicated in-house designers. The comparison leaves out the work after launch: new components, training and the quarterly review.

‍

Ask every agency to include a handover your owner can maintain, and set aside time each sprint for upkeep.

A scale-up must pick a team model. In zeroheight's data, 51% of systems run a centralized team, 31% a hybrid and 13% a federated one.

‍

Staffing complaints differ by model: 53% of centralized teams say they lack people, against 68% of hybrid and 74% of federated teams. Federated teams cite unclear ownership and design system work losing out to feature work.

‍

I would start centralized with 2 to 3 people, then open contributions to product teams once the core components are stable. In the same report, 65% of teams already let anyone on the product team contribute.

Brad Frost points to internal measures: how quickly projects ship, how many UI-related bugs developers field, and how many UI-related issues reach customer support. The bug and support counts should trend down as the system gets adopted.

‍

Few teams measure at all. In zeroheight's report, 31% track speed of development and 5% track ROI. In Sparkbox's survey, 16% tracked any metrics. Pick 3 numbers before you start: time to build a new screen, UI bugs per release, and the share of screens built from system components.

‍

You will see claims that design systems cut design and development costs by 30% to 50%. One agency guide attributes the figure to Forrester and Medium analysis. We could not trace it to a primary study, so measure your own numbers.

Most SaaS teams ask this when the interface starts to grow faster than the team can keep it consistent. Hatypo Studio has delivered 20+ dashboard and SaaS projects since 2021, and projects start at $3,000 with price following scope.

‍

• If you are starting a new product, we design a small token and component set around your first screens, so it grows with the product.
• If your current system is underperforming, we audit the live UI, find the duplicate components and fix the ones that cause the most rework.
• If your product has outgrown its first system, we plan the move to a team model and contribution path that fits your headcount.

‍

Tell us where your product stands and we will tell you whether to adopt, adapt or build. Book a consultation.

Healthtech UX works when accessibility, compliance and trust are designed as one system from the first wireframe. In practice that means building to WCAG 2.2 Level AA, which includes the 2.1 AA standard HHS requires of federally funded providers from May 2027, treating health data as a protected category under HIPAA and GDPR, and telling users plainly where their data goes.

‍

This guide draws on the W3C's WCAG 2.2 documentation, the HHS Section 504 interim final rule, GDPR Article 7 and Article 9, the FTC Health Breach Notification Rule, the FDA's human factors guidance, and a 2019 JAMA Network Open study of health app data sharing.

‍

I'm Adhitya, a Senior UI/UX Designer at Hatypo Studio, where our team has delivered 10+ healthtech projects since 2021. This guide covers three questions every healthtech interface has to answer: who can use it, what rules apply to it, and why a patient should trust it with their data.

The WHO estimates that 1.3 billion people, 16% of the world's population, experience significant disability. In healthtech, one inaccessible screen can stop someone from booking a visit, reading a result or refilling a prescription.

‍

The current standard is WCAG 2.2, which the W3C published on October 5, 2023. It adds 9 success criteria to 2.1 and retires 4.1.1 Parsing. The six new Level A and AA criteria all change how health screens get designed:

‍

• Target Size, Minimum (2.5.8, AA). Pointer targets need at least 24 by 24 CSS pixels, or enough spacing around them (W3C). Check dose steppers, time-slot chips and close buttons first.
• Accessible Authentication, Minimum (3.3.8, AA). Login can't depend on memorizing or transcribing something unless an alternative exists (W3C). Allow paste, support password managers and WebAuthn passkeys, and let one-time codes autofill.
• Redundant Entry (3.3.7, A). Don't ask for details the patient already gave in the same process. An intake form that repeats date of birth on step 4 fails.
• Dragging Movements (2.5.7, AA). Any control operated by dragging, such as a pain-scale slider, needs a single-tap alternative.
• Focus Not Obscured, Minimum (2.4.11, AA). A sticky header or cookie banner can't fully cover the element that has keyboard focus.
• Consistent Help (3.2.6, A). Put help, such as a nurse line or chat link, in the same place on every page.

‍

In the US, HHS's Office for Civil Rights pushed its Section 504 deadlines back one year in an interim final rule effective May 7, 2026. Recipients with 15 or more employees must meet WCAG 2.1 Level AA for web content and mobile apps by May 11, 2027. Smaller recipients have until May 10, 2028.

‍

Design to 2.2 AA from the start. It keeps every 2.1 criterion except the obsolete Parsing one, so it covers the HHS standard without a second pass.

Which rules apply depends on who holds the data, what the product does, and where its users live. The table lists the ones that most often change what a screen looks like, with the design consequence of each.

‍

‍

HIPAA covers providers, plans, clearinghouses and their business associates. A consumer app outside that group can still fall under the FTC rule, which since its 2024 amendments names health apps not covered by HIPAA and treats an unauthorized disclosure as a breach. Consumer notices must name the third parties that received the data.

‍

HHS has proposed a Security Rule overhaul that would require encryption, multifactor authentication and network segmentation. Fierce Healthcare reported in July 2026 that the target for a final rule slipped to July 2027. Design the MFA flow now and treat the final text as pending.

‍

Under GDPR Article 9, health data is a special category, and processing it needs a lawful exception such as explicit consent. Explicit consent means an express statement for a specific purpose, so pre-ticked boxes and bundled terms checkboxes fail. Article 7 adds that withdrawing consent must be as easy as giving it.

‍

If your software counts as a medical device, the FDA expects a human factors process: analyze use-related risks, then validate with representative users in realistic conditions. IEC 62366-1 is the international standard for the same process.

Trust starts with what the product does with data. A 2019 JAMA Network Open study by Huckvale, Torous and Larsen tested 36 top-ranked depression and smoking-cessation apps. Of those, 33 sent data to third parties, 29 sent it to Google or Facebook, and only 25 had a privacy policy.

‍

Users can't anticipate sharing that the interface never mentions. Six practices address it:

‍

1. State the reason at the field. Put a one-line purpose beside each sensitive input, such as "We use your date of birth to match your records." A link to a policy page asks the user to leave the task.
2. Audit third-party scripts. List every analytics, advertising and session-replay script on logged-in pages. Remove any whose purpose and legal basis you can't name.
3. Separate consent from terms. Give each purpose one choice and no pre-ticked box. GDPR requires this for health data, and a single-purpose screen is also easier to understand.
4. Make leaving as easy as joining. Put consent withdrawal and account deletion in settings, within the same number of taps as the original opt-in.
5. Write at the reader's level. Use plain language, define clinical terms and spell out units. Healthy People 2030 defines organizational health literacy as the degree to which organizations enable people to find, understand and use information for health decisions.
6. Show who stands behind the content. Name clinical reviewers, date medical content and keep a contact route on every page, which also supports WCAG's Consistent Help criterion.

Compliance checks cost the least at the stage where the decision is made.

‍

1. Map the data before drawing screens. List every field, who sees it, where it is stored and which rule applies. Designers and legal share this data map, and every later screen refers back to it.
2. Annotate accessibility in the design file. Add contrast ratios, target sizes, focus order and screen reader labels to each component, so developers receive the criteria together with the design.
3. Design the consent and failure states first. Consent, session timeout, lockout, failed login and error screens carry compliance duties and usually get designed last.
4. Test with the users who struggle most. Recruit people who use screen readers, have low vision or limited motor control, and have low health literacy. For regulated devices, run the FDA-style validation with representative users.
5. Keep an evidence file. GDPR Article 7 requires you to be able to show that consent was given, so log the consent text version and a timestamp with each choice. Store audit reports and test notes beside it.
6. Re-audit every release. Rules and deadlines keep moving: HHS extended its Section 504 dates in May 2026, and the HIPAA Security Rule target slipped to July 2027. Add an accessibility check to each release.

Healthtech screens carry accessibility, privacy and safety duties at the same time, and the design work moves faster when those constraints enter at the wireframe stage.

‍

Hatypo Studio has delivered 10+ healthtech projects and 20+ dashboard and SaaS projects since 2021; projects start at $3,000 and the price follows the scope.

‍

• If you're starting a new healthtech product, we design the screens, flows and consent patterns around WCAG 2.2 AA from the first wireframe.
• If your existing portal or app loses patients at login or intake, we audit those flows against WCAG 2.2 and redesign the steps that fail.
• If your product has outgrown its first version, we rebuild the design system so every component carries its accessibility and consent rules.

‍

Tell us which stage you're at and we'll scope it together: Book a consultation.

Fintech onboarding earns trust in the first 60 seconds by showing proof before it asks for data. Show what the product does and costs, who runs it and which regulator oversees it, then ask for the least data you can, explain each request, and finish with a first real result. In Signicat's 2022 survey, 68% of European consumers had abandoned a financial application.

‍

This guide draws on Signicat's 2022 Battle to Onboard survey as reported by FinTech Global and Payment Expert, Nielsen Norman Group's research on trustworthy design and progressive disclosure, Baymard Institute's 2025 checkout study, and Gitte Lindgaard's 50-millisecond first-impression study as reported by Nature.

People judge a screen before they read it. Carleton University researcher Gitte Lindgaard and her team found that visual appeal can be assessed in 50 milliseconds, and those quick verdicts matched ratings given after longer viewing.

‍

That study measured visual appeal, not trust. It does show how little time a first screen gets, and money raises the stakes. In Signicat's 2022 survey of 7,600 European consumers, 68% had abandoned a financial application in 2021, up from 63% in 2020.

‍

The reasons were split. Time needed, the amount of personal data requested, and people changing their minds each drew 21%. Two of those three are decisions a design team controls. Separately, 92% of respondents said they worry about how providers use their data.

‍

The 60 seconds in the title is a working frame, not a measured cutoff. We use it to sort onboarding into 4 questions a new user answers in order: what is this, who is behind it, what will it ask of me, and what do I get? The sections below follow that order.

Nielsen Norman Group's trust research names 4 factors people use to judge a site: design quality, upfront disclosure, comprehensive and current content, and connection to the rest of the web. Its later study found users still weigh the same 4 that Jakob Nielsen listed in 1999.NN/g also reports that asking for personal information before people can explore degrades trust. For a fintech app, that rules out a signup wall as the first screen. Let people see the product, the pricing and the rules first.

The first screens should answer 3 questions before any form field appears:

• What does it do and what does it cost? One line on the product, and fees visible without an account. NN/g observed that sites missing basic information were quickly dropped from consideration.
• Who runs it and who regulates it? Show the legal entity name, the regulator and the license number, linked to the regulator's public register where one exists.
• How do I reach a person? Show a support channel and a stated response time without scrolling.

‍

NN/g notes that typos and broken links quickly degrade credibility. A screen that handles money has less room for them, so fix them before launch.

Every field asks for trust. In Signicat's survey, 38% of respondents abandoned an application because they lacked the right identity documents, and 21% left over the volume of personal data requested.

‍

Three habits cut those exits:

• Ask for each item at the step that needs it. NN/g's progressive disclosure defers advanced features until they matter. Applied to data, that means email first, name next, and ID only when verification starts.
• Say what's needed before the step starts. "You'll need a passport or national ID and about 3 minutes" lets people get the document before they begin.
• Put the reason beside the field. One sentence is enough: "We check your ID to confirm it's you. Financial accounts require it.

‍

Payment and ID capture need extra care. Baymard's 2025 checkout study found that 19% of 1,026 US respondents had abandoned a checkout in the previous 3 months because they didn't trust the site with their card details. Testers felt less secure when card fields looked like every other field.

‍

That is e-commerce data, so it gives a directional signal for fintech. Card linking and ID capture are the same moment in a fintech flow. Give those fields their own container, a lock icon and one line on how the data is stored.

The 5 steps below turn the 4 questions into screens. The time windows are design targets for the trust decision. Full identity verification can run longer, and that's fine once the user has a reason to continue.

‍

1. 0 to 10 seconds: say what this is. The first screen has one line describing the product, one primary action and a link to fees. It asks for nothing yet. A new user should be able to repeat the offer to a friend after reading it once.
2. 10 to 20 seconds: show who is behind it. Put the legal entity name, regulator and license number on the welcome screen or one tap from it. Add a support channel. These are the 3 facts a cautious user looks for before typing anything.
3. 20 to 40 seconds: ask for the least you can. Start with a phone number or email and a verification code. Place the reason for each field beside it, and show where the user is in the flow, for example "Step 1 of 3".
4. 40 to 50 seconds: preview the verification step. Before the ID or selfie screen, say which document is needed, how long the check takes and what happens to the image afterwards. Where regulation permits, let the user see a preview of the account first.
5. 50 to 60 seconds: give a first real result. Show something concrete: a confirmed account, a quoted rate, a sample dashboard populated with the user's own name. End with the next step and a time estimate.

A trust signal works when the user can check it and the product can back it up. These 5 fail that test.

‍

• Badges with no source. A "bank-grade security" icon that links nowhere gives a cautious user nothing to verify. Link each badge to the certificate, register or policy behind it.
• Social proof nobody can confirm. A line like "Trusted by 1M users" needs a date and a source. If finance can't confirm the number, remove the line.
• Jargon in security copy. "256-bit encryption" means little to most users. Say what it protects, for example "Your ID image is encrypted and deleted after verification," and write only what the product does. Engineering and compliance should confirm each claim.
• Early gates. NN/g reports that asking for personal information before users can explore degrades trust. A required account before the user sees any rate is the common case.
• Vague errors. A failed ID check is a trust moment. Say what failed, offer a retry, and give a route to a human.

Trust has no single metric. Put a funnel event on every screen in the 5 steps, then read the drop-off at each one against that step's job. Signicat's 3 abandonment reasons (time, data volume, changed mind) give you hypotheses to test first.

‍

1. Define one core flow. For a wallet, that's sign-up, KYC, top-up and send.
2. List your regulators and markets. EU users mean PSD2 and the EAA. Card data means PCI DSS. Indonesian users mean UU PDP and OJK rules.
3. Count screens and states. Include errors, empty states and review states along withthe happy path.
4. Pick a team model and region. Multiply estimated hours by the rate from the table above.
5. Add a budget line for research, testing and design QA. Plan yearly upkeep separately; Six2eight estimates it at 15% to 25% of the build cost.

‍

‍

Pair the numbers with moderated sessions on the first 3 screens. Ask new users to say what the product is, who runs it and what it will ask for next. Teammates know the answers, so recruit people who have never seen the product.

Onboarding is where a new fintech product wins or loses its first users.Hatypo Studio has delivered 15+ fintech projects since 2021, and projects start at $3,000 with the price following the scope.

‍

• If you're building a new fintech app, we design the first-run flow from welcome screen to first result before development starts.
• If your onboarding loses users on a specific step, we review the funnel and redesign that step.
• If your product has outgrown its first version, we redesign the flow across web and mobile.


‍

Tell us where your users drop off and we'll suggest where to start: Book a consultation.