Context && Experience
Here we'll build on both the Context and Audience sections of our Creative Brief by describing specifically how our audience will encounter the work and what the intended experience should entail and how it should feel. What do you expect/hope your audience's reaction or interaction with your project to be? What prior knowledge are you assuming? What barriers might they face (time, tech, mobility, sensory)?
Where does your target audience typically encounter work like this? Identify the ideal platform/venue (web, gallery, tabletop, festival, public space), run-time or length of the session, any list any requirements and/or constraints (lighting, sound spill, bandwidth, devices).
If this is a game, what's the turn/phase structure? game loop? win/fail states? difficulty curve? If this is an interactive creative computing piece describe the UX, what are the primary modes of interaction, navigation and feedback? If this is a performance or installation what is the spacial layout? what roles do performers/audience play? what are the stages or what is the flow/progression? When possible show, don't tell (use diagrams and sketches over written descriptions).
Evaluation Criteria
Transform the rubric you described in your brief into a weighted list. Identify 3â5 categories and give each a % value, for example: Clarity of Experience (45%); Systems/Rules Coherence (20%); Craft/Polish (20%); Accessibility & Safety (15%); This makes explicit what project's priorities are and keeps everyone (even if thats just you and me) accountable to what matters most. Add a couple of sentences to each category describing what "good" looks like for each.
Define how you will measure success by choosing a framework that fits your project. This can take the form of an acceptance criteria (specific benchmarks that must be met), an impact plan (how your project will affect its audience or community), and/or specific metrics (engagement, feedback, technical performance, etc) and state it explicitly. List the qualitative signals and quantitative targets, how you'll gather them, when you'll check them, and the pass/fail thresholds that trigger next steps. The result should be an unambiguous set of criteria that all stakeholders (me, you and any collaborators) can use to judge whether the project has met its goals.
For example, you could describe a plan for gathering qualitative data, how you plan to capture what people say, feel, and do in context. In practice, designers may expose a small sample from their target audience (3-6 folks) to the project and follow up with either short exit interviews or conduct a focus group where they lead a conversation (question based) with all of them together. They might start with a cold read and ask, "What did this piece communicate to you?" before asking more goal-focused questions like "Where did you get stuck?" and "What did you try next?". Another approach is to setup a structured observation where they'll watch a their audience interact with and/or experience the work and take careful notes: verbatim quotes, visible behaviors (confusion, furstration, delight), and moments of friction or flow. Synthesize your notes with an affinity map or brief rubric so themes are comparable across sessions, and document decisions you'll prototype next.
If your project is better served by quantative metrics you can count or time, describe your plan for collecting those. Game developers, web designers and software artists integrate simple analytics tooling (often using pre-existing libraries or APIs) to log: user events, completion states, replays, page visits, fps (frames per second), session length, or setup time. For board games or installations, use tally sheets and timers to record turns per minute, rule lookups, time spent interacting, or component misuses. Tie each metric to a target, for example: a game's tutorial completion should be greater than 70%; time spent interacting with the installation should be longer than 3 mins; the generative art system should render no less than 60 fps; etc.
The Specs
This should be the largest section of your doc, it's where you map out the plan for what to make. These should not be vague descriptions, these should be concrete artifacts that a collaborator could use to start working on your project (whether or not you have collaborators, imagining one as the target audience for this doc is helpful). This can include diagrams, formats, wireframes, check lists, whatever is most useful in your particular case. While some narrative components are best expressed in writing, a general rule of thumb here is: show don't tell.
Creative/Art Direction: Capture the look, sound and feel in a way that ensures a coherent style. You can start by borrowing elements from your mood board, but rather than simply creating a collage that transmits a vibe, this must be a document that clearly instructs someone on how to deliver that vibe. This can include: color/texture palettes, typography, 2D styles (e.g., pixel art), 3D styles (ex: low-poly), file formats that effect aesthetics (e.g., color profiles, bit depth, sample rate); music genre/style constraints (rhtymic patters, instrumentation, etc) animation/motion principles. The goal is to create a style guide that is clear enough to ensure consistency but flexible enough to iterate.
Diagrams: Create visual diagrams that help communicate key aspects of your project clearly at a glance. For example, with installation work it's useful to have blueprints and spatial/floor plans to describe the dimensions of space, projector rigging, throw distances, power/cable paths, and safety clearances. For hardware projects and designed objects it's useful to draw schematics (idealy with software like EAGLE that can be directly printed onto cirguit boards or SVGs which can be used to create prototypes with CNC machines and laser cutters). For web and software art projects use wireframes to sketch a layout, hierarchy, states, and navigation without before worrying about the actual design/aesthetic.
Content Lists: Pair your diagrams with concise checklists that fill in the gaps and ensures nothing gets lost in the visuals: list specific parts, their behaviors, and what must be produced. Create a content inventory that breaks the project down into every individual part that needs to be written, drawn, recorded etc. If you're working on a game, list your entities/assets, but also your mechanics. For web/software art projects, list your pages/views but also any events/conditions (including error states). For installations list your components but also any special systems (generative algorithms, data pipelines). Other lists might include levels, pages, scenes, cards, tracks, data files, rules, states, etc. Create different lists for different content categories. Prioritize every item (e.g., must-have, should-have, could-have). This will not only help you track your progress but will make it easier to scope for your project when you start working on the Production Plan.
Time-based Models: Many MADD capstones are time-based media projects, in these instances it's helpeful to map how the experience is meant to unfold over time. UX flows, loop diagrams, flowcharts, story boards and journey maps help to sequance out stages in explicit ways. Whether your working on a game (think game loops), a software/web project (think UI/UX events and flows), an installation (think story boards) or a media performance (think visual scores), taking time to describe what happens when helps make the important beats, timing, and transitions clear.
Values && Ethics: Create any checklist and list any commitments that should guide your production and how you'll uphold them in practice. For example, consent && privacy: whether you collect data and, if so, what, why, where it's stored, and for how long (alternatively it might be important to state that no data is being collected). Accessibility: text size/contrast, captions/subtitles, alternative inputs/remapping, motion/photosensitivity options, physical access and wayfinding. Content sensitivities: warnings, cultural/context notes, community consultation where appropriate. Licensing && attribution: asset sources and planned licenses for release, attribution plan for any open source or creative commons componetns that require it. It's worth to include some sort of checklist or verification plan for this (what you'll test/check for and how) so these aren't just aspirations.