Which Programs Design Is Made In: Raster, Vector, Interfaces and Generation

The tool question is usually a different question

Clients often ask which application the work will be made in, and they almost always mean something else: will I receive files I can open and hand on. That is a sensible question, asked through the name of a tool.

The application itself does not determine quality. A raster editor does not prevent a good mark, and a vector editor does not guarantee one that reads at sixteen pixels. Method determines that: whether the task was framed, the result verified and the handover assembled.

But the choice of tool is not neutral, for a different reason. Each class of application has its own territory, and work made in the wrong class creates problems later — at print, at handover to a developer, or at the first revision.

What follows sets out what is made where, where the boundaries fall, and what to agree before starting, whatever names appear in your contract.

It is worth remembering that the list of tools changes faster than the principles behind them. Application names that were standard five years ago have been partly displaced, while the division into raster, vector, interface work and generation has stayed exactly where it was and will most likely outlive the next wave as well.

Raster and vector: the boundary that matters

The whole range of design software divides on one question: how the image is stored. Raster is a grid of pixels — photography, collage, retouching, texture. Vector is a description of shapes as formulas — a mark, an icon, a diagram, a typographic lockup.

A raster image has a fixed size. Doubled, it loses sharpness; enlarged to a shopfront sign, it falls apart. A vector description scales without loss from a favicon to a facade, because it is recalculated every time it is output.

From which follows the practical rule behind most mistakes in this area: a logo, icons and any element of an identity live in vector. Photography and anything built on photography lives in raster. Mixing them inside a layout is fine; mixing them inside the mark's source file is not.

That is why a mark "made in Photoshop" usually has to be redrawn: not because the editor is poor, but because the job was not its job.

What a raster editor is for

A raster editor — Photoshop and its equivalents — is the tool for working with photography and with the image as material. Colour correction, retouching, cropping, removing what does not belong, combining frames, preparing images for a specific carrier.

The same applies to visuals for advertising and social media: setting text over a frame, collage, working with light and shadow, bringing disparate photographs to one tone so a series looks shot on the same day.

And preparation for print: colour profile, resolution, bleed. These are nearly invisible until the printer and extremely visible afterwards.

What a raster editor is not for: drawing a logo as a final source, assembling interfaces, or laying out multi-page documents. All of that is technically possible and practically awkward.

What a vector editor is for

Vector is the territory of the mark, icons, diagrams and any graphic that has to scale. Curves are built here, proportions aligned, spacing between elements set, and versions prepared for different grounds and sizes.

This is also where the compact version of a mark is born: not scaled down but simplified, with the detail that merges at small sizes removed. That cannot be done in raster, because simplification means working with the shapes themselves.

Every handover format comes out of vector: the editable source, SVG for the site, PDF or EPS for print. Raster PNGs are exported from it, not the other way round.

SVG deserves separate mention: it is not a picture but markup a browser reads as text, so the mark stays crisp on any screen and usually weighs less than a raster equivalent.

What an interface editor is for

The third class is interface design tooling. What distinguishes it is not drawing but working with repeatable elements: a component is described once and updates across every layout at once.

Sites and applications are assembled here: grid, states for buttons and fields, behaviour across widths, links between screens. Handover to a developer lives here too — sizes, spacing and colours are read directly from the layout.

The decisive advantage of this class is that it supports a system rather than a set of separate pictures. A thirty-page site assembled without components diverges by its third update.

A mark arrives here as finished vector and photographs as already-processed raster. An interface editor uses them; it does not create them.

Image generation: where it belongs

Generative tools added a fourth class, and it settled somewhere other than expected. They are strongest during exploration: an hour covers more visual directions than a day of drawing, and agreement on territory arrives sooner.

They are also useful for intermediate material: a background, a texture, a compositional sketch, filling a layout with a meaningful image instead of a grey rectangle. All of that speeds up the conversation and does not reach the final work unaltered.

Their limits are those of any raster, plus two of their own. First, format: the output is raster and a mark still requires manual vector drawing. Second, rights: terms of use differ between services and jurisdictions, and they get established before an image goes onto packaging.

And a third, remembered last: generation does not check what the result resembles. Comparing it against existing marks and images stays a separate human step.

What to agree before starting

First, the form the files will take. Not the name of an application but a list: editable source, vector of the mark, exports for web and print, fonts with their licence stated.

Second, who owns what. Are sources part of the handover or retained by the supplier? Without sources, every later change means drawing it again, which is effectively a second invoice for the same work.

Third, the provenance of images. Original photography, licensed stock and generated material carry different restrictions, and mixing them in one project without noting which is which is a way to inherit trouble later.

Fourth, fonts. They are licensed separately by type of use, and a typeface legitimately sitting in a layout cannot always be placed on a website or embedded in an application.

How this looks on a real project

The usual order runs like this. Task and material come before any tool. Then the search for a direction, where generation saves time and a person makes the decision.

Then the mark in vector with its mandatory checks: reduction to icon size, one colour, light and dark grounds, a real photograph. Then photographic work in raster, bringing a series to one tone.

Then assembly of pages or carriers in an interface editor, where elements become components. Then handover: files, states, rules and a written list of what the work did not include.

At VITON13 the design service covers that chain end to end — from the mark through pages to presentation assets — starting at $70 and running one to eight working days depending on volume.

So when choosing a supplier it is more useful to ask how the result gets verified and what the handover contains than which applications sit on their machine. The answers to those two questions predict the outcome far more reliably than a list of icons in somebody's dock.