SmartLink
Web design & development

Design system services in Pakistan: tokens, components and rollout

Design system services in Pakistan are bought when an organisation notices that its website, its portal and its internal application look like three companies. SmartLink Services builds these systems from Karachi: colour, type, spacing and elevation defined as tokens, a component library with every interactive state drawn and coded, usage guidance, and a rollout plan for the products that already exist. Contrast and focus behaviour are verified against WCAG 2.1 AA inside the component rather than audited on the page. Below is what the work costs at market rates, how long it takes, and whether to design the system first or extract it from what you have already shipped.

Discuss this service
Scope
Web \u00b7 app \u00b7 portal
Form
Tokens + components
Docs
Usage guidance
Overview

One system, or three products that look like three companies.

Organisations rarely set out to have inconsistent interfaces. It happens because the website was built by one team, the customer portal by another two years later, and the internal application by a contractor who never saw either. Each used the brand guidelines, each interpreted them slightly differently, and now there are four blues, three button heights and two ideas about what a form error looks like. Nobody can point to the moment it went wrong, because it happened gradually.

A design system is the mechanism for stopping that. Colour, type, spacing, radius and elevation are defined once as named tokens. Components are built once, with every state, and documented so that using one correctly is easier than building a new one. The point is not aesthetic consistency for its own sake. It is that a team can build a new screen quickly without making twenty small decisions somebody else already made differently last quarter.

Systems that fail do so for predictable reasons: no owner, no version, no migration path for what already exists, and a set of components designers use but developers cannot. So we build tokens that exist in code as well as in the design tool, components documented with their real states, and a rollout plan that acknowledges the products you already run. A system nobody adopts is a document, not a system.

Scope

What Design systems & brand application covers

Everything below is agreed in writing before any web & digital work starts, so both sides know what is in and what is not.

What the work covers

  • Audit of existing screens and inconsistencies
  • Colour, type, spacing and elevation token definition
  • Core component library with every interactive state
  • Usage guidance and do-not patterns
  • Accessibility contrast and focus verification
  • Rollout plan across existing products

What you get at handover

  • Token set in code and design tool
  • Documented component library
  • Usage guidelines
  • Accessibility verification report
  • Migration plan for existing screens

Typically involves

Figma Design tokens Storybook WCAG AA
Discuss this service
01

Tokens that survive contact with developers

The usual first attempt at tokens is a palette named after the colours. Brand blue, light blue, grey ninety. It works until somebody needs to know which grey is for borders and which is for disabled text, and then it becomes a matter of taste again. Naming by appearance also makes a dark theme almost impossible, because a token called light grey cannot sensibly become dark grey without every reference in the codebase reading as a lie.

Two layers solve it. Primitive tokens hold the raw values and are never used directly. Semantic tokens name a purpose: surface, surface raised, text primary, text muted, border subtle, action, action hover, danger. Components reference only the semantic layer. Changing a theme then becomes a remapping of that layer, and a developer choosing a colour is choosing a role rather than a shade, which is a decision they can make correctly without consulting anybody.

For this to hold, the tokens need one source that generates both the design tool variables and the code artefacts, whether that is a stylesheet with custom properties, a theme file or platform specific output. When designers and developers maintain separate copies, the two drift within a release or two, and the drift is invisible until somebody compares screens side by side. A generated pipeline is not sophisticated engineering. It is the difference between a system and a suggestion.

  • A primitive layer of raw values that components never reference directly
  • A semantic layer naming purpose, such as surface, text muted, border subtle and danger
  • One source generating both design tool variables and the code artefacts developers consume
  • Theming handled by remapping the semantic layer rather than by editing components
  • Spacing, radius and type held on a scale, so arbitrary values stand out in review
02

A component is not finished until every state is drawn

Component libraries usually ship the default state and stop. Hover, focus, active, disabled, loading, error and read only get invented later by whoever needs them first, and they are invented differently in each product. Focus is the one most often missing and the one that matters most, because a visible focus indicator is what makes an interface usable from a keyboard and is a WCAG 2.1 AA requirement rather than a stylistic preference.

Content behaviour belongs in the definition too. What a button does with a label twice as long as the example. What a table does on a narrow screen. What a card looks like with no image, and with a title running to three lines. What a select does with two hundred options. Each of these has an answer, and writing the answer once in the component prevents twenty different answers appearing across the products that consume it.

We document components where developers will see them, normally in a running component explorer rather than a static page, with the properties, the variants and the usage guidance alongside the rendered example. Do not patterns are worth as much as the recommended ones: which component to use for a destructive action, when a modal is the wrong choice, why a tooltip cannot hold the only copy of important information. Guidance that exists only in a designer's head does not scale past one project.

  • Default, hover, focus visible, active, disabled, loading, error and read only states specified
  • Behaviour defined for long labels, missing images, empty lists and unusually large option sets
  • Components documented in a running explorer with properties, variants and usage guidance
  • Do not patterns written down alongside the recommended ones
  • Responsive behaviour defined per component rather than left to each consuming team
01

What a design system costs in Pakistan

No published price band covers design systems in this market, and any supplier offering one has not asked what you already have. The work is part design and part front end engineering, so the comparable measure is rates. Full stack development is published at PKR 3,500 to 8,000 an hour in Pakistan with senior specialists at the top of that band, and junior work at PKR 500 to 1,000. Component engineering belongs at the senior end, because a component written carelessly is copied into forty screens before anybody notices.

Where a system is commissioned as a project rather than staffed by the hour, custom web application pricing at PKR 200,000 to 1,000,000 and upwards is the nearest published comparator, and it holds for a reason: a design system is software with documentation attached, and it carries the same maintenance obligation.

Scope is decided by four things. Component count comes first, and it should be small. Buttons, inputs, selects, tables, modals, navigation, notifications and form layout will carry most of an enterprise product, and a library of ninety components is usually a symptom rather than an achievement. States are second, since a component is not finished until disabled, loading, error, focused, hovered and read only are all drawn and coded. Implementation is third, and it doubles the conversation: a token set in Figma is a design deliverable, while the same tokens as code in Storybook with tests around them is engineering. Migration is fourth and it is the line most often left out. Applying the system to three products that already exist is a schedule of work per product, not a launch event. All of these are market rates rather than our quotation. A real figure follows discovery, once the component list, the implementation target and the products in scope are agreed.

  • Rates compared rather than a package price, since no published band exists for this work
  • A deliberately small component set, because a large library is usually a symptom
  • Every interactive state drawn and coded before a component is called finished
  • Design tool tokens and coded tokens quoted as two different deliverables
  • Migration of existing products scheduled per product rather than treated as a launch
02

How long a design system takes to build

Reported timelines give six to twelve weeks for a focused single scope go live, and a first useful system fits that band: tokens agreed, the core components drawn and coded, documentation written and one real screen rebuilt on top of it to prove the thing works. Attempting the whole library before anything is used is the reliable way to spend a quarter and ship a slide deck.

Agreement is what takes the time rather than production. Colour is decided by whoever owns the brand, and that person may sit in marketing, in a parent company or in a document from 2018 that nobody can find. Type licensing is a real question with a real answer needed before a font is shipped in a product. We ask for the brand owner by name in the first week.

The second variable is which product goes first. A system with no consumer is a theory, so we rebuild one genuine screen inside the sprint that produces the components, and that screen finds the gaps no review would have found.

Rollout is a longer horizon and should be planned as such. Three products with their own release calendars and their own teams adopt at their own pace, and the honest sequence is new work built on the system first, existing screens migrated when they are being touched anyway, and only the worst offenders migrated for their own sake. Attempting all three at once competes with every feature those teams have already committed to, and the system loses that argument.

  • Six to twelve weeks reported for a first useful token set and core component library
  • The brand owner identified by name before colour and type are settled
  • Font licensing checked before a typeface is shipped inside a product
  • One real screen rebuilt on the system inside the same sprint that produces it
  • Rollout planned per product, with existing screens migrated as they are touched
03

Building the system first or extracting it from what you have shipped

There are two honest starting points and the difference is more than sequence. Building first means agreeing tokens and components in the abstract, from the brand and from principles, then applying them outwards. Extracting means taking the products you already run, cataloguing what is actually on the screens, and deciding which of the eleven button styles survives. The second is less satisfying and it is right more often.

Extraction wins where products already exist, which describes most organisations that ask for this. An audit takes a fortnight and produces something uncomfortable and useful: nine greys where the brand has three, four different date formats, two competing table designs, a modal that traps keyboard focus. Every one of those is a decision waiting to be taken rather than a component waiting to be designed, and the system that comes out of it is grounded in what your teams actually build rather than in what a designer would prefer they built. It also arrives with its own adoption argument, since a developer who has seen the audit does not need persuading.

Designing first suits a genuinely new product, a rebrand that changes the foundations underneath everything, or an organisation whose existing screens are so inconsistent that cataloguing them would be archaeology rather than analysis. Even then the system needs a consumer inside weeks. A library built with no product on it accumulates components nobody asked for and misses the ones everybody needs, and we have seen a beautifully documented system abandoned within a year for exactly that reason.

One thing decides the outcome more than either route does. Somebody has to own the system after the first release, with time allocated rather than goodwill assumed, and there has to be a way for a team to propose a component without convening a committee to approve it. Where no owner can be named, the honest advice is to build a smaller set of shared components inside one product and stop there. A design system with nobody responsible for it becomes one more inconsistent thing for everybody else to be inconsistent with.

  • An audit of existing screens run first wherever products already exist
  • Design led creation reserved for new products or a foundational rebrand
  • A real consumer product committed to the system within weeks of the first components
  • A named owner with allocated time agreed before the system is built
  • A smaller shared component set inside one product recommended where no owner exists
How we deliver

Delivering Design systems & brand application

Nothing is drawn until we know what the existing site has already earned. The six steps below start with an audit and end with a maintenance schedule, because that is where sites are actually lost.

  1. 01

    Discover

    Every existing URL is crawled and matched against analytics, so we know which pages earn traffic and which have never been read. Content owners are named in the same week, with dates attached.

  2. 02

    Blueprint

    Address structure, the content model and the authorisation rules for any signed in area come first. Wireframes follow, and the redirect map from old URLs to new is drafted before a template is designed.

  3. 03

    Build

    Components are built once and reused, to WCAG 2.1 AA, with content areas that an editor can change without a developer. Portal screens are wired to the source system, not to a copied database.

  4. 04

    Test

    Keyboard navigation, screen reader order, form labelling and contrast are checked against the standard, not assumed. Checkout is tested with a real payment provider in test mode, including a declined card.

  5. 05

    Go live

    Redirects go live with the site, and we watch server logs and search console for the ones we missed. Certificate, domain and analytics property are checked as a list, in your accounts.

  6. 06

    Run

    Framework and plugin updates go on a schedule, staged before production. Uptime monitoring requests a page that exercises the database, because a site can answer and still be broken where it counts.

Working together

When a design system is not worth building

If you have one website, one team and no plans for a second product, a design system is overhead dressed as good practice. A style guide and a well organised stylesheet will serve you better, and we will say so. The economics change when there are several products, several teams, or a rebuild coming, because then the cost of deciding the same things repeatedly starts to exceed the cost of deciding them once.

Where it is justified, the deliverable is a token set in code and in the design tool, a documented component library, written usage guidance, an accessibility verification report and a sequenced migration plan for the products you already run. The last of those is what makes the difference between a system in use and a system in a folder.

Credentials

Accreditations behind Web & digital

A portal is only as good as the system behind it, so these credentials describe what our web work reads from and runs on.

Oracle

Partner

Portals and dealer dashboards read order status, invoices and statements from the Oracle databases behind your ERP, through read only views and an integration layer rather than a nightly copy.

Microsoft

Partner

Entra ID gives partner and dealer portals a sign in that a customer administrator can revoke. Azure hosts the site, and SQL Server frequently holds the catalogue behind an e-commerce build.

Google

Partner

Analytics and Search Console are configured before launch so a baseline exists to compare against, and Google Cloud hosts the site where a specific region or scale is required.

FBR digital invoicing

Compliant integrations

An online checkout that raises a sales tax invoice has to report it. The order confirmation carries the invoice reference number and QR code, and the customer can download the invoice afterwards.

HIPAA

Compliant practices

Patient portals and appointment booking need encryption in transit, session handling that logs a shared terminal out, restricted logging so health data stays out of it, and a business associate agreement.

Client words

What Web & digital clients say

Comments from people who run web & digital systems day to day.

  • They wrote our requirement documentation knowing it had to survive a tender committee, and they were direct when one of our requirements could only be met by a single supplier. We would not have caught that ourselves. The audit trail design has since been through a full review without a finding.
    IT Director Public sector authority
  • Our first concern with FBR integration was simple: what happens to the tills when the line drops. They built the queueing and retry before anything else and demonstrated it by pulling the connection in front of us. Trading carried on, and the invoices went up when the link came back.
    Operations Manager Retail chain, Pakistan
  • Every vendor we spoke to said they could handle style, colour and size. This team asked to see our order book first, then told us which of the shortlisted platforms would need thousands of item codes to do it. That one piece of advice probably saved us a year.
    General Manager Textile exporter
Questions

Questions about Design systems & brand application

There is no published band for this work, so compare rates and deliverables. Full stack and senior specialist engineering is quoted at PKR 3,500 to 8,000 an hour here, junior work at PKR 500 to 1,000. Commissioned as a project, custom web application pricing of PKR 200,000 to 1,000,000 and upwards is the nearest comparator. Component count, coded implementation and migration decide where inside that you land.

Reported timelines give six to twelve weeks for a focused scope, which covers agreed tokens, a core component set drawn and coded, documentation, and one real screen rebuilt on top of it. Rollout across products that already exist is a longer horizon and is planned per product, since each has its own release calendar and its own team.

A single definition of the parts your interfaces are made from, used by design and by code. Colour, type, spacing and elevation held as tokens; components with every state defined; guidance on when to use each one and what to avoid; and accessibility verified inside the component. The point is that a screen built next year in another team still looks like the same company.

A component library is part of one. The library is the coded components. The system adds the tokens underneath them, the design tool version designers work in, the usage guidance, the accessibility rules and the process for proposing a change. A library without those drifts, because two teams will use the same component to mean two different things within a year.

Yes, and that is the only way it gets adopted. Tokens in Figma for designers, the same tokens in code for developers, components published where your build already pulls from, and documentation in the place your team actually reads. We fit the system to your repository, your framework and your release process rather than asking three teams to change how they work.

Count it rather than assume it. What proportion of screens are built from library components, how many one off colours and spacing values are still in the code, how many components have been copied and altered locally. Those figures are dull and they are honest, and they tell an owner where the system is failing people rather than where people are failing the system.

More in Web & digital

More Web & digital services

Web design & development

UX & UI design

Research, journeys, wireframes and a high-fidelity interface design before a line of production code.

Open service page → Web design & development

Corporate website design & development

Marketing sites built for speed, search and editing by non-technical staff.

Open service page → Web design & development

E-commerce development

Catalogue, checkout, payment and fulfilment, integrated back to ERP and inventory.

Open service page → Web design & development

Web portals & dashboards

Customer, dealer and partner portals over your enterprise data, with permissioned access.

Open service page → Web design & development

Website maintenance & support

Updates, backups, security patching, uptime monitoring and content changes on a retainer.

Open service page →

Four blues and three button heights?

Tell us what you run today and where design systems & brand application is causing you trouble. The first conversation is a consultation rather than a pitch.

Book a consultation All web & digital