Product interfaces from one senior team: research before pixels, prototypes your users test before a line of code, accessibility built into the first component rather than audited into the last. Delivered as a design system (a shared library of parts and rules) your product team keeps building on.
PixelCrayons designs product interfaces (research, user flows, prototypes and UI) tested with users before code is written. Engagements start with research scoped honestly to your budget, from analytics review and stakeholder interviews up to moderated usability tests. They ship as a reusable design system with dev-ready handoff, or production code from the same team. WCAG 2.1 AA is the default. Direct for brands, white-label for agencies.
Design is reported as a set of documents you can review without a walkthrough. In the first month you receive the research summary with the tasks users need to complete, the information architecture with every page and its purpose, and the states ledger listing each screen with its empty, loading, error and success states. Review rounds are logged with the decisions taken and the reasons for them.
01Research summary: user tasks, existing friction, and what was observed
02Information architecture: every page, its purpose, and how users reach it
03States ledger: each screen with empty, loading, error and success states
04Component inventory: what is reused, what is new, and where each appears
05Decision log: each review round, what changed and why
Stakeholder interviews, analytics and support-ticket review on every engagement; user interviews, journey mapping and moderated usability tests where budget allows. We're plain about the trade-off: a lean scope leans on analytics and heuristics, a fuller one buys direct user evidence, and your proposal states which you're getting.
Week 1
02
Flows before screens
Journey maps, information architecture and the critical paths (sign-up, first value, checkout, recovery) worked out as flows before any interface is drawn. Most product friction lives between screens, not on them. Designing the route first is how it gets found.
Every project
03
Prototypes users test before code
Clickable prototypes put in front of real users (or the closest proxy your timeline allows) before engineering starts, with findings written up and fed straight back into the design. A wrong assumption costs an hour to fix in Figma and weeks to fix in production. Testing early is the cheapest engineering decision you'll make.
Before build
04
Product UI built as a system
Every colour, size and spacing gets a name (a token), every control becomes a component, and the interaction patterns are written down, all delivered as a reusable library. Screen forty is as considered as screen one, and your team can extend the product without booking a designer for every button. One-off artboards age badly. Systems compound, and the library is handed into your workspace, documented, as part of the engagement.
Every delivery
05
Accessibility as a default
WCAG 2.1 AA contrast, visible focus states, keyboard paths, reduced-motion alternatives and semantic structure are in the base spec of every engagement, not an audit bolted on at the end. Accessible products are simply better-designed products, for every user.
Included
When research is worth buying
Test what is expensive to undo. Ship the rest and watch.
Teams argue about whether to test something and settle it by whoever is most senior in the room. There is a better question: if this is wrong, what does it cost to change? Plot the answer against what you already know and the decision usually makes itself, including the cases where a study would waste your money.
← Little evidenceHow much you already knowStrong evidence →
Vertical · Cost of being wrong · Expensive to undo at the top
Research pays here
Expensive to undo, and you do not yet know. This is the only quadrant where a study is straightforwardly worth its cost.
Decide and commit
Expensive to undo, but the evidence is already in. More research here is procrastination wearing a lab coat.
Ship it and watch
Cheap to undo and unknown. Testing costs more than being wrong. Instrument it and let the live traffic answer.
Just do it
Cheap to undo and already understood. Any process you add here is pure overhead.
1Information architecture and URL structureEvery internal link, every ranking and every bookmark depends on it. Changing it later is a redirect project.
2The core task flow (checkout, booking, onboarding)Rebuilding a flow after launch means re-testing every integration that touches it.
3Who the page is written forGet the audience wrong and every downstream decision inherits it. Cheap to check, expensive to discover late.
4Accessibility baselineCostly to retrofit, but the answer is not in doubt: the standard already tells you what to build.
5Section order on a marketing pageA deploy away from being reversed. Instrument it rather than convening a study.
6Headline and call-to-action wordingThe classic thing teams argue about for a week and could have measured in two.
7Form field order and validation behaviourCheap to change and thoroughly settled by existing convention. Follow it.
Only one quadrant justifies a study. If we propose research for a decision you could reverse on a Tuesday afternoon, push back, and we will tell you when a decision has quietly moved into the quadrant that does.
Illustrative positions: typical of the projects we see, not measured data
04
How it starts
Brief to tested prototype, no mystery in between.
01
Days 1 to 3
Research & audit
Stakeholder interviews, analytics and current-experience review, and the research plan agreed in writing, including which activities are in scope and what the budget buys in user evidence.
02
Days 4 to 7
Flows & direction
Journey maps and the critical paths drawn, information architecture agreed, and the visual direction presented with written rationale and decided with you in the room, so nothing later is a matter of taste.
03
Days 8 to 13
Screens in the system
Priority screens designed inside a live component library from day one: tokens, states and interaction patterns forming as the screens do, so the system grows with the product instead of after it.
04
Start
Prototype lands
A clickable prototype plus the research summary and system foundations, delivered for structured review. From here the cadence repeats: test, learn, refine, extend.
Inside Prism
Your engagement, week to week, in one workspace.
Where the engagement includes it, your design work runs in a Prism workspace you log into: review requests, sign-offs, the task list and the weekly review, with each decision recorded.
Each decision recorded, with the expectation attached.
03
Actions checked against outcome
What we did and what happened, side by side.
Where this fits
UI/UX is one part of the machine.
One team from research readout to release. Need UI/UX web design services for a marketing site rather than a product? Start with web design. Voice and identity unsettled? Start with brand identity. Prototype approved? Design to code builds it, with nothing lost in handoff.
Before you sign
Our commitments
Each one says where it applies and links to its full terms.
Response and start times
We typically respond within four business hours. Eligible engagements can typically start within two to three business days after scope, payment and required access are confirmed.
Business hours are Monday to Friday, 9:00 am to 6:00 pm IST, excluding published company holidays. Typical expectations, not guaranteed service levels.
Every delivery is reviewed before release by QA, your Project or Account Manager and a senior delivery lead, and you then review it against the acceptance criteria agreed at the start. Our specialists use AI to support delivery, with people responsible for reviewing the work. Applicable development work includes 30 days of corrective maintenance after production launch.
Who owns the ad accounts, the data and the work?
Your materials, data and accounts remain yours, and we prefer to work in advertising and analytics accounts you own, with access delegated to our team. Agreed ownership rights in bespoke deliverables transfer under the engagement terms and applicable payment; third-party software and assets keep their licences. We do not withhold customer-owned data or accounts over a payment dispute.
What if we want to stop?
Cancellation, notice and any renewal terms are written into your proposal or statement of work before you accept it. If an engagement ends early, we hand over completed, paid-for work and list any unfinished work separately. For an eligible specialist trial, you can stop within the trial window and pay nothing for eligible trial hours.
How will we know what you are doing?
Before work starts we agree how often you get updates, what the reports cover and who sends them. You know who coordinates your engagement, who owns the work and how to escalate an issue. For hourly and retainer work, time is recorded in Workstatus, so you can see the time records behind your invoice.
As much as the budget buys, and we'd rather tell you that upfront than sell you "research-led design" that's a mood board and a hunch. Every engagement includes stakeholder interviews and an evidence review of your analytics, session recordings and support tickets. Fuller scopes add user interviews, journey mapping and moderated usability tests with your actual users. The proposal states exactly which activities are included, so you know whether decisions will rest on direct user evidence or on informed heuristics.
A focused product-design engagement is scoped by screen count and research depth. Full design systems for larger products run longer and are phased so engineering can start before every screen is finished. Timelines are written into scope with named milestones. If a date moves, you hear it from us first, with the reason.
Review rounds are written into the scope before work starts: structured feedback windows at the research-readout, prototype and pre-handoff stages. That makes revisions a planned part of the process, not a negotiation. Usability findings get the same treatment: when testing contradicts a design decision, we show you the evidence and change the design, rather than defending the artboard. If the brief itself changes mid-project, we re-scope that piece openly instead of absorbing it silently.
Two ways. The dev-ready route: named layers, documented tokens, component variants, interaction and motion notes, and redlines (the exact measurements to build from) a developer who has never met us could work from. Plus, our designers are on call for your engineers' questions during the build at no extra charge. Or skip handoff risk entirely: our own front-end team ships the interface as production code through our design-to-code service. What users get is what you approved in the prototype: same spacing, same motion, same accessibility, with nothing quietly reinterpreted on the way to production.
Included, always. WCAG 2.1 AA contrast, visible focus states, keyboard navigation paths, reduced-motion alternatives and semantic structure are part of the base spec of every component we design, not an audit line you can decline. Designing accessibly from the first component is dramatically cheaper than retrofitting it after launch. It also produces clearer interfaces for every user, not just those relying on assistive technology. If you carry compliance obligations beyond AA (public-sector standards, industry regulation), tell us at scoping and we'll spec and test against them explicitly.
Judge the agency on things you can check in writing. Does the proposal state exactly which research activities are included? Are prototypes tested with users before any code is written? Is WCAG 2.1 AA in the base spec, and are the IP and ownership terms for every file, token and library written down? Our proposals list the research in scope, prototypes are tested before build, AA is the default and IP and ownership terms are agreed before work starts.
Yes. Agency partners white-label our design work under their own brands: your project templates, your client calls, our researchers and designers. The arrangement is NDA-backed. We do not approach the clients you introduce to us for direct business. That protection runs through the work and for twelve months after the last assignment for that client ends, and it is written into the agreement. Every deliverable (research readouts, prototypes, documentation) is prepared to present as your studio's own work. The white-label design page explains how the partnership is structured and how to get our rate card.
Once we have a complete brief, we confirm the date you will receive your scoped, itemised UI/UX proposal. Your materials remain yours. Bespoke deliverable rights, licences and handover are agreed before work starts.
