Hiring a product designer or frontend developer: a practical guide for teams

Decide whether your project needs product design, frontend development or both. Compare portfolios, define deliverables and prepare a useful hiring brief.

Product specialists reviewing a workflow together in a bright studio

A company can know that its product needs help without knowing which role to hire. Screens may look inconsistent, delivery may feel slow, or customers may struggle to complete a task. The useful first question is not which title sounds most senior. It is which part of the work is missing.

This is my practical framework for defining an engagement before comparing portfolios. It is intended for founders, hiring managers and product teams considering a design or frontend partner. It is not a promise that one person can replace every specialist on a complex product.

Choose the role around the bottleneck

If the team is uncertain about user journeys, information hierarchy or which problem to solve, start with product design. A useful design engagement should clarify the workflow and test the important decisions, not simply produce attractive screens.

If the product direction is settled but the interface still needs to be implemented, start with frontend development. Ask how the developer handles responsive behaviour, component reuse, loading and error states, accessibility and integration with your existing backend.

If the difficult part is preserving design intent through implementation, a partner who works across design and frontend can be useful. Define the boundaries explicitly. Backend architecture, security review, native mobile engineering and production operations should not be silently assumed to be included.

Review one case study deeply

A gallery shows taste. A detailed conversation shows judgement. Ask the candidate to walk through the starting problem, their specific contribution, the constraints and a decision they changed after feedback. Distinguish individual work from team output without dismissing collaboration.

  • What did the person own, and who handled the other disciplines?
  • Which user journey or business problem drove the decisions?
  • How were alternative approaches evaluated?
  • Can they explain mobile behaviour and less-visible states?
  • What was delivered, and what evidence supports any claimed outcome?

A candidate should be able to say what they do not know. Measured results are valuable, but a portfolio should not invent conversion gains when measurement was outside the engagement. Clear reasoning is more useful than a percentage without context.

Agree on deliverables before discussing a deadline

Replace a vague request such as 'make the app modern' with one important flow, the intended users and the outcome you want to improve. List the screens and states you already know about, then leave room for discovery to uncover missing ones.

For design work, agree whether you need research, a prototype, a component system or implementation specifications. For frontend work, agree the codebase, supported devices, integration boundaries, review process and handover documentation. Ownership of source files and access to production should be discussed early.

Use a small paid scope to test collaboration

For a substantial engagement, I would prefer a bounded paid discovery or implementation milestone over a large speculative redesign. Choose work that produces something useful even if the collaboration does not continue. Agree acceptance criteria in advance and review the process as well as the output.

Look for understandable updates, early questions and honest escalation when requirements conflict. A polished final screen cannot compensate for a process that leaves your team unable to review decisions or maintain the work.

Send a brief that makes a useful reply possible

  • Your product or website link and the people it serves.
  • The main problem, with one concrete example.
  • What already exists: research, designs, code or a working product.
  • Who will collaborate and approve decisions.
  • Your budget range and desired start date.
  • The first outcome that would make the engagement worthwhile.

You do not need to have every requirement solved before reaching out. It is enough to explain the uncertainty. A good first conversation should help decide whether the right next step is discovery, design, implementation or a different specialist.

For website projects, I combine content hierarchy, interface design and responsive frontend delivery within an agreed scope. Discuss a website design or frontend project

For business applications, begin with the workflow and the constraints rather than a long feature list. Explore custom software engagements