Design for a real client
Designing for a real client means solving an authentic organisational and customer problem while contributing an original point of view. The client is not simply an audience that approves finished visuals: they supply business context, constraints, specialist knowledge and decisions throughout the project. UAL’s account of a recent live brief notes that a genuine business challenge changes the designer’s attention from aesthetics alone to feasibility, communication and impact.[1]
Begin with a discovery meeting. Confirm the business challenge, intended customer or user, desired change, project scope, deliverables, decision makers, budget assumptions, deadlines and definition of success. Ask what evidence already exists, what has been tried, which constraints are fixed and which are open to challenge. Translate the conversation into a short project charter and send it back for written confirmation; unresolved questions should be logged as assumptions, not silently treated as facts.
Map the stakeholders. Distinguish the project owner, day-to-day contact, final approver, technical specialists, commercial team, makers, suppliers and people who will wear, buy, sell or maintain the product. Decide who must be consulted, who supplies information and who has authority to approve each milestone. Customer research should be proportionate but direct: store observation, product reviews, competitor comparison, staff interviews, wardrobe conversations, fit trials or user testing can reveal needs that a client summary misses. In an LCF project with Marks & Spencer, store visits and interviews with staff and potential customers exposed market gaps, while regular client check-ins redirected the work.[2]
Establish professional working rules before sharing development. Agree file formats, meeting rhythm, response times, version names, approval method and where decisions are recorded. Clarify confidentiality, publicity, ownership, licensing, collaborator credits and whether student work may be published or submitted to awards. AIGA’s standard design-services agreement treats scope, client responsibilities, review periods, changes, schedules and rights as explicit project terms; even an educational brief benefits from recording these issues in plain language.[4]
Maintain a decision log with the date, issue, evidence, decision, owner and effect on scope or timing. After every review, circulate a concise recap: what was approved, what must change, what information is outstanding and what happens next. This protects both creativity and trust because the team can distinguish an evolving idea from an uncontrolled change. Escalate risks early—for example unavailable fabric, an inaccessible price point or a delayed fitting—together with options and consequences.
Review gate: Ask whether the project can be understood by someone who missed the kickoff. The charter should identify the real problem, intended user, measurable outcome, boundaries, owners, milestones and approval path. Check that research represents the customer rather than stereotypes, that confidential material is marked correctly and that every major design choice can be connected to a client or user need.
Industry project task: Create a client-discovery pack containing a one-page charter, stakeholder map, ten interview questions, research plan, decision log and written kickoff recap. Add a short note identifying one client assumption you intend to test rather than accept.