TASC Computer Graphics and Design common mistakes
TASC Computer Graphics and Design · Understand the traps and how to avoid them.
Submitting a design or file with RGB colour values and 72 dpi settings when the brief specifies print output, so the final product is rejected on technical grounds.
Candidates practise almost exclusively on screen and never internalise the RGB-versus-CMYK and screen-resolution-versus-print-resolution distinction; the difference is invisible on a monitor, so nothing signals the error.
What to do instead
Before export, run a fixed checklist: colour mode, resolution, bleed, and file format against the brief. Practise converting a sample file from RGB to CMYK and comparing the on-screen shift so the consequence becomes concrete.
Flattening or rasterising vector artwork (logos, type, icons) before final delivery, producing pixelated edges when scaled.
Raster tools are more familiar and offer quicker visual results, so candidates reach for them by default and treat vector formats as an afterthought rather than a deliberate choice.
What to do instead
Learn to state the rule aloud: anything that must scale without loss stays vector. Rebuild one logo in a vector tool and export at three sizes to see the quality difference firsthand.
Building a layout with no grid, inconsistent margins, and ad-hoc alignment, so the composition looks unstable and spacing varies from element to element.
Candidates compose by eye and nudge objects until they 'look right', which produces near-misses that read as sloppy rather than intentional; they have not internalised alignment and proximity as structural tools.
What to do instead
Set up columns, margins, and a baseline grid before placing any content, and use alignment and distribute commands rather than manual dragging. Review the layout with guides visible to catch off-grid elements.
Choosing type sizes and line lengths without regard to hierarchy or readability, resulting in body text that is too small, too wide, or indistinguishable from headings.
Candidates select fonts by appearance alone and underestimate how viewing distance and column width affect legibility; they also conflate 'looks interesting' with 'communicates clearly'.
What to do instead
Apply a deliberate scale (for example a clear ratio between body, subhead, and headline), cap line length at a comfortable reading measure, and test the layout at actual output size rather than zoomed in.
Ignoring contrast and accessibility when pairing text and background colours, so key information becomes unreadable for low-vision users or in poor viewing conditions.
Designers judge contrast on a bright, well-calibrated monitor and trust their own perception; they rarely check numeric contrast ratios or simulate colour-vision deficiency.
What to do instead
Check every text-background pair against a contrast ratio target, and preview the design through a colour-blindness simulation. Treat contrast as a pass/fail criterion, not a matter of taste.
Delivering files with missing links, unembedded fonts, or unpackaged assets, so the project breaks when opened on another machine.
Candidates work on a single machine where everything resolves locally and never experience the failure themselves, so packaging feels like unnecessary bureaucracy.
What to do instead
Make packaging the final step of every project: collect linked images, embed or supply fonts, and reopen the packaged folder on a different account or machine to confirm nothing is missing.
Misunderstanding resolution and image scaling, upsampling a low-resolution image to fill a large area and calling it fixed.
Candidates equate a larger pixel dimension with higher quality and do not realise interpolation invents no detail; the problem only shows at print size.
What to do instead
Calculate required pixel dimensions from physical size and target resolution before placing an image, and reject any asset that falls short. Verify by viewing at 100 percent and at print scale.
Using ambiguous or non-standard layer and file naming, then delivering a file whose structure cannot be understood or edited by anyone else.
Naming feels cosmetic and candidates optimise for their own short-term memory during a fast build, leaving 'Layer 4 copy 2' throughout the document.
What to do instead
Adopt a naming convention from the first element created, group related layers, and delete hidden or unused ones before delivery. Treat file structure as part of the deliverable, not private scaffolding.
Exporting to the wrong format or with destructive compression, such as a lossy format for a logo or a flattened file when layers were requested.
Candidates default to whatever format they use most and do not connect format choice to purpose (web display, print, editable handoff), so compression artefacts and lost editability go unnoticed.
What to do instead
Map each deliverable to its purpose before exporting: lossless or vector for logos and print, appropriately compressed formats for web, layered source files when handoff is specified. Inspect the exported file, not just the canvas.
Skipping the proof or preflight check, sending a file with typos, cut-off content, or elements outside the trim area.
Candidates finish when the design looks complete on screen and treat review as a separate stage they will do later; zoomed-out views hide overflow and small errors.
What to do instead
Build a fixed preflight routine: spell-check, inspect at high zoom and full-page view, confirm nothing crosses the trim or bleed boundary, and export a proof to review away from the editing environment.