Design education centres lots on being 'given a brief'. Might just be me, but no one has ever given me a design brief in my career so far. No clear problem statements or one-pagers. Much more likely the client or decision maker will say "You figure it out" or "What do YOU think?". It took my years to learn design briefs aren't a thing. This isn't bad. My point is giving design students briefs doesn't prepare them for careers in design. Happy to be challenged.
As someone else alluded to in the comments, I think the existence or quality of the brief very much depends on the area of design you're working in, so "design" is probably too broad a brush stroke. The merit of an overly prescriptive brief obviously differs between say Graphic Design and Product, but I'd argue they absolutely should and likely do exist in some form. In graphic design, clients usually know what they do (or more don't don't) want, but may lack the language or ability to get it out of their head and into yours. In the worst cases they're simply looking for someone to do exactly what they say, but are bad at saying so. And in product/software, nobody should be embarking on anything without at least a hypothesis to investigate as an initial direction of travel, aligned to an idea of business value or user need. Even if that hypothesis is "do some discovery on this", to me this is still a brief under a different name and can be collaboratively built upon as knowledge grows. So design education could probably help here not by teaching students to rely on briefs, but on teaching how to extract them from clients both as a valuable professional practice, and for the sake of their own sanity.
💯. Designing the brief with your team, users and stakeholders *is* the work.
I’ve given lots of design briefs? Granted, more for graphic designers than interaction/service designers. Having briefed a lot I think briefing itself is an important skill and necessarily involves the designer. But whoever’s briefing should be responsible for setting out their thinking/problems/limitations/hopes clearly on paper so it’s not assumed and can then be developed in collaboration with the designer. Designers should be able to expect this in my opinion.
I’d say you’d got to start with giving students a design brief so they understand the importance of defining a problem clearly as a first step. By the time I got to the last year of my degree I was making my own brief and defining the problem. It’s difficult realise that lack of definition creates problems down the line (as often happens in the real world) unless you realise what having definition does bring.
It's much more an agency thing - as in, you're working in an environment with account directors and so on, possibly expert marketing buyers of their services from industry, and the two sides cook up a brief and a quote. I've been involved in the cooking up many times. It's old school, IMO, as agile has rather done away with those kind of briefs. In contract work there's often a Statement of Work that's kind of a brief but has been put together as a thing to kick off the work rather than a brief for it.
I’ve had plenty of of briefs. Some formal contracts, some informal discussions. They most often need challenging and (re-)writing, which is a key skill. Above all, a long time ago I learnt the lesson of not starting a project without clear written agreement on the objectives and deliverables (brief), which sometimes need constant updates. Where I find the real key separator with professional designers though, is being able to spot new opportunities to add value as you go through a project. Quite often that’s the next brief, being able to spot it is what creates demand and flow of design projects. Having people in the team who can do it is invaluable. We are probably not saying something to dissimilar, but just with different views on what constitutes a brief.
You’re right. A large group of design lecturers from different colleges and I often discussed getting rid of the brief. The people who challenged it were the students who weren’t yet ready for a lack of clarity about what was required (and many colleagues for the same reason - usually the ones who were practicing designers three days a week, go figure), validating bodies from industry who insist on courses ticking certain boxes, and quality assurance bodies having ‘guaranteed’ experiences. It’s safer at masters level (and can be a lot of fun, but not as inclusive as I’d like) and in certain disciplines where they are less restricted by industry requirements (ie not architecture, engineering, etc which are very prescriptive). But while it’s true (generally) that ‘the brief’ doesn’t exist in industry, the role of a course is not to replicate industry experience (there are alternatives for that) but to provide a broad educational experience and exposure to certain concepts. That said it depends what industry you work in. In the public sector ‘the brief’ is alive and, sadly, very well.
Design education starts before design education. So much of the criteria for student success in our pre-university education system is built around following worked examples and completing pre-defined outputs, rather than on exercising enquiry and creativity. I saw this as an educator at university level. Even though we briefed our first year students, initially the majority of them expressed discomfort at the latitude afforded to them by design briefs. Many wanted to be told and/or shown what to do - 'what should the end result look like?'. Setting design briefs doesn't totally prepare students for careers in design. But not setting design briefs sets students up to fail design education.
I’ve been given loads. They’re usually called “statements of work” and 99% of them of crap. The best one I ever saw listed outcomes in priority order based on solid user research.
Director of Design and Research at Genomics England
7moI agree that not many people we work with are used to giving briefs (in my most recent experience in leading in house design teams in health tech organisations) - though this shouldn’t stop the designers from owning the briefs and clarifying what’s needed. A simple template could be a very effective tool to aid better communication and co-create the brief with the stakeholder: what is the problem we are looking to solve, who is the intended user, who are the stakeholders, what dependencies does this work have, what risks do we foresee, what assumptions are we making, what is outside of the scope of this work, what “deliverables” are expected, and what timelines will we be working towards? The goal is not necessarily to come up with a brilliant brief and sign it off, but to use this tool to have a good conversation about the work at hand. Projects evolve naturally as new information gets introduced, but the headlines in the template remain true and help as an anchor to go back and align as the work evolves.