Choose a portfolio project by starting with the work you want to be hired to do. Identify a plausible buyer, a specific problem, a realistic deliverable, and the evidence the project can produce. The result should help someone judge your ability to handle a similar task.
A project can look impressive while answering none of a client’s questions. A complicated application may be less relevant to a small website-editing service than a carefully documented, accessible information site. This guide helps you choose purposeful samples.
In this guide
Connect a buyer problem to a practice brief
Write one sentence: “A [type of buyer] needs [task completed] because [practical problem].” Keep the problem specific and avoid inventing research. You can describe a fictional scenario for practice without claiming a real business has this need.
Then define what the buyer would receive and how they could assess it. A visual deliverable needs communication and export checks. A spreadsheet needs data and calculation checks. A website needs functional as well as visual checks.
Read the text version: Map a service to the proof a project should produce
Service: event-announcement design. Fictional buyer problem: readers need to find when an event happens and how to book. Practice project: create one square announcement and a separate printable information sheet for a fictional reading club.
The example drawings group Saturday and 11:00, give the long venue name deliberate space, and adapt the information to different proportions. They illustrate hierarchy and adaptation; they are not finished production files.
Keep the brief, the actual exported outputs, the export-check record and asset permissions. These support an explanation of design choices. They do not establish increased attendance or any other commercial result. Confirm actual placement and print specifications for real work.
Practical summary
- Relevant: it resembles a task in your intended service.
- Complete: the output has a defined beginning and end.
- Checkable: you can verify meaningful requirements.
- Explainable: you can describe your decisions and limitations.
Five project briefs across different skills
| Skill | Fictional practice brief | Useful evidence |
|---|---|---|
| Graphic design | Create an event announcement with supplied wording, then adapt it to a second placement. | Hierarchy decisions, versions, export checks, and the reason for layout changes. |
| Video editing | Turn your own short recording into a concise explanation with accurate captions. | Source and final excerpts, edit decisions, caption checks, and an organised handover. |
| WordPress | Build a small service-information site in a practice environment. | A written brief, working navigation, device checks, and a maintenance handover. |
| SEO | Review a practice site and propose a limited set of improvements. | Observed evidence, prioritisation, proposed changes, and clearly stated measurement limits. |
| Virtual assistance | Organise fictional enquiries and meeting requests into a repeatable workflow. | A clean tracker, unresolved questions, scheduling checks, and a written procedure. |
Use the related roadmaps for the prerequisites: design, editing, WordPress, SEO, and virtual assistance. The examples are starting briefs; they are not completed work samples or evidence of commercial outcomes.
Add a useful constraint
Constraints reveal judgement. An event graphic may need to work with a long venue name. A video may have an unclear sentence that requires a question rather than an invented caption. An administrative task may include two requests for the same time.
Choose a constraint that resembles the intended work. Avoid adding unnecessary complexity just to make the project sound advanced. If the constraint prevents you from finishing, reduce the scope or learn the missing prerequisite first.
Keep a record of what you did when the information was incomplete. Asking a well-formed clarification question can be part of professional evidence; silently inventing missing details usually weakens it.
Use the project-selection worksheet
| Field | Write before starting |
|---|---|
| Intended service | The narrow task this project will support. |
| Scenario | The fictional or permission-based context and intended audience. |
| Problem | What needs to become clearer, easier, more accurate, or more usable? |
| Inputs | Text, data, media, access, and permissions available to you. |
| Deliverables | The exact files, pages, or documented outputs you will produce. |
| Constraints | Formats, accessibility needs, limits, and a realistic complication. |
| Acceptance checks | Observable conditions that define a satisfactory result. |
| Portfolio evidence | What you will show and explain, with permissions and limitations. |
Read the text version: Fill a brief before building the portfolio project
Fictional brief: North Lane Reading Club.
- Audience and purpose
- Adults seeking a beginner-friendly reading session. Help them locate the event details and booking action.
- Outputs
- One square announcement and one printable information sheet. Agree the intended destinations and confirm actual print specifications before real production.
- Inputs
- Supplied event title, date, time, long venue name and booking email, plus permitted assets.
- Constraint
- Keep the date easy to find despite the long venue. Adapt each layout deliberately rather than automatically cropping one version.
- Acceptance checks
- All supplied information matches the brief, the text is readable at intended size, the final exports open correctly and asset permissions are recorded.
Retain the brief, both outputs and your actual check record. The fictional project can demonstrate design decisions; it cannot establish attendance results.
Worked example: a small project with a clear purpose
Fictional scenario: A community reading club needs an announcement for its next session. The supplied text contains a title, date, time, location, and booking email. The requested deliverables are a square graphic and a simple printable version.
Constraint: The location name is long, and the date must remain easy to find. The designer chooses a clear hierarchy, groups related details, and adapts the layout for each format rather than shrinking one version automatically.
Checks: Compare the content with the supplied text, inspect readability at intended size, verify the exports, and record the assets used. The portfolio can then explain those decisions and show the two versions. It cannot claim increased event attendance without real measurement.
The project is useful because its purpose, decisions, and checks are visible. Adding ten unrelated graphics would not automatically make the evidence stronger.
Review the brief before spending time on it
Ask whether the sample resembles your intended service, can be completed with available resources, uses permitted material, and will demonstrate something beyond copying a tutorial. If you cannot explain its relevance, revise the brief.
When selecting a second project, add a meaningful difference: another audience, a different input condition, or an additional delivery requirement. Keep the connection to the service clear.
Frequently asked questions
Should I redesign a famous brand?
You can learn from analysing existing work, but an unsolicited redesign must not imply employment or approval. Check asset rights and use a clear concept label. A fictional brief can let you demonstrate similar decisions with less ambiguity.
What if my first project is too basic?
Assess whether it is useful, complete, and appropriate to the task you want to demonstrate. Improve its checks and explanation before adding complexity. A simple project may still reveal important learning gaps.
How do I choose between several portfolio project ideas?
Compare each idea with the service you want to demonstrate. Ask whether it has a clear audience, an inspectable deliverable and a realistic scope for your current ability. Prefer the project that will produce useful evidence and reveal an important learning gap.
Should every portfolio project use a different tool?
No. Choose tools because the brief needs them. Several projects using the same tool can demonstrate different decisions, constraints and outputs. Changing software for its own sake may distract from finishing and checking the work.
What constraints make a fictional project more useful?
Add constraints that resemble the task: a defined audience, supplied wording, a required format, accessibility needs or a limited set of approved assets. Keep them manageable and explain how they affected your decisions. Avoid adding complexity that has no connection to the intended service.
When is a portfolio project complete enough to present?
Compare the result with the brief, open the final exports and resolve material issues. Include a short explanation of your contribution, decisions, checks and limitations. If an important part remains unfinished, label its status clearly rather than presenting it as a complete deliverable.
Finish the work and explain it
Complete the brief, keep your check results, and use the portfolio case-study structure to present it honestly. Assess your ability with the readiness rubric, then connect the evidence to a defined service package.