UI UX design services in Pakistan: cost, duration and research

What UI UX design costs in Pakistan

Almost nobody in this market publishes a figure for design on its own, which is the first thing worth knowing when comparing two quotations. Design is usually folded into a build price, so the honest way to compare is to ask each supplier what share of the number is design and what that share buys. A business website is published at PKR 80,000 to 200,000 in total, and a custom web application at PKR 200,000 to 1,000,000 and upwards, so design as a separately commissioned stage sits somewhere inside those envelopes rather than beside them.

Where design is bought by itself, hourly rates are the comparable measure. Junior work in this market is quoted at PKR 500 to 1,000 an hour and full stack work at PKR 3,500 to 8,000, with senior specialists at the top of that band. Interface design for an enterprise application belongs near the senior end, and production of additional screens from an agreed system does not, which is why an honest quotation separates the two rather than averaging them.

What moves a design number is not the screen count. User types come first, since a portal serving customers, dealers and internal staff is three journeys with three sets of permissions and three sets of empty states. Research depth is second: eight user interviews and a review of existing analytics is a different commitment from a workshop with three managers. States are third, and they are the ones missing from cheap quotations. Loading, empty, error, no permission, partially filled, offline, four hundred rows and one row. Breakpoints are fourth, because a design agreed on a laptop and handed over without the phone layout drawn simply moves the decision to a developer at eleven at night. A documented component set costs more than a set of screens and pays for itself the moment a second team touches the product. Everything here is market pricing. A real figure follows discovery, once the user types, the research depth and the deliverable list are agreed.

• Design separated out of a bundled build price so two quotations can be compared
• User types counted rather than screens, since each one carries its own journey
• Every screen state drawn, including error, empty, no permission and partial
• Breakpoints agreed up front rather than left to a developer at midnight
• Component documentation quoted as a deliverable in its own right

How long a design stage takes

Reported delivery timelines here give six to twelve weeks for a focused single scope go live, and a design stage is a fraction of that rather than the whole of it. A marketing site with an agreed page set can be researched, wireframed and designed inside three to four weeks. An enterprise application with several user types, a permission model and a real component set belongs in the six to twelve week band on its own, before a line of production code exists.

Access to actual users decides the pace more than the drawing does. Interviews with eight dealers require eight dealers who answer the phone, and the finance manager whose approval screen you are redesigning has a month end. We schedule research around the business rather than the sprint, because interviews compressed into one afternoon produce polite answers rather than useful ones.

Review cycles are the second variable and the one clients control. A named decision maker who can approve wireframes in two working days will halve the calendar against a committee that meets fortnightly. We ask in the first meeting who that person is, and we say plainly what moves if the answer is nobody.

Content is the third. Real product names, real prices, real error messages: a design filled with placeholder text hides every layout problem that matters, and those problems surface in the build where they cost several times more to solve. Ask for the longest product name you actually sell and design against that, not against a convenient one.

Where a design stage runs alongside a build rather than ahead of it, the sequence matters more than the total. Wireframes for the first release go first, the component set follows, and the screens nobody sees until month three are drawn while development is already moving. That keeps designers ahead of developers without asking anybody to guess.

• Three to four weeks realistic for a marketing site design with an agreed page set
• Six to twelve weeks for an application with several user types and a component set
• Research interviews booked around the business calendar rather than the sprint
• One named approver for wireframes, with a stated turnaround
• Real content used in the design so layout problems surface before the build

Starting with research or starting with the design

Both routes are defensible and the wrong one is expensive in a way that shows up late. Research first means interviews, a look at what the analytics already say, journeys mapped per user type, and a wireframe review before anybody chooses a colour. Design first means going straight to the interface on the strength of what the business already believes, then testing that belief on a prototype. The second is faster and cheaper right up to the point where it is wrong.

Skipping formal research is reasonable more often than a design agency will admit. A five page company site with one contact form does not need eight interviews. A pattern used by every serious competitor in your sector, a checkout flow, a login screen: these are solved problems, and re-deriving them from first principles is an expensive way to arrive at what everyone else already does. Where the audience is well understood and the interface is conventional, go to wireframes and test with a prototype instead.

Research earns its cost where the requirement is contested or invisible. A portal replacing a spreadsheet that three people maintain differently. An internal application where every department describes the process another way and all three descriptions are partly right. A product entering a market nobody in the room belongs to. In those cases the money spent on interviews is not spent on design at all, it is spent on avoiding a build of the wrong thing, and we have watched a fortnight of interviews remove a third of a proposed scope because nobody actually did the step it was for.

A note about the analytics you already have. Most organisations we meet are sitting on months of data telling them which pages people leave, which form field they abandon and what they searched for and did not find. Reading that costs almost nothing and sharpens every interview afterwards. So the honest sequence for most projects is not one route or the other. It is a short look at the evidence you own, interviews only where the answer is genuinely unknown, then wireframes early enough that being wrong is still cheap.

• Existing analytics read first, since the evidence is already paid for
• Interviews commissioned where the requirement is contested or unobserved
• Conventional patterns adopted rather than re-derived from first principles
• Wireframes reviewed before visual design, which is the cheapest place to be wrong
• A prototype tested with people who do the work rather than with their managers