You can start before every word is ready
The designer needs to build a layout, but the final product text is still being written or checked. A blank page does not help, so someone adds “Product name,” a short paragraph and a few numbers.
That may be enough to start drawing. It does not tell you what will happen when the real product name is three times longer.
Mock data means made-up information used for testing. It can be a fictional name, a sample description or an invented list of product details. The information should look and behave like the content you expect to receive.
A useful sample lets the team answer a practical question: will this layout still work when the text changes?
Agree on a list of content
Before making samples, ask the person responsible for the text what the artwork needs to contain.
For a label, the list might include a product name, flavour, weight, ingredients, contact details and a language. A guide might need a title, numbered steps, pictures and warnings.
Each named piece of information is a field. Think of it as a spreadsheet column: one column for the product name, another for the weight.
Agree on the field names early. If the sample calls a field productName, the real file should use that same agreed name.
Ask a few simple questions together:
- Which details must appear on every version?
- Which can be left out?
- Which words must stay exactly as supplied?
- Which details change between languages or countries?
- Who can confirm that the final text is ready?
The designer can then show where each piece belongs in the layout. This often reveals a missing detail before much work has been done.
Make samples that show different problems
Ten nearly identical examples will tell you less than a few carefully chosen ones.
Start with an ordinary product. Then add a long name, a long paragraph and a product with very little content. Include a version without an optional badge and one with several badges.
For a product guide, try three steps and fifteen steps. For a certificate, try a short name and a long name with several parts.
You can write samples yourself, ask the content team to supply them or use a separate tool to generate them. Check any generated samples before using them. A random set of words is not useful if it does not resemble the job.
Use fictional details in early demos when real customer or launch information is not needed. Label the examples clearly so nobody mistakes them for approved product information.
Look at the samples in Illustrator
A spreadsheet can show that the text exists. The artwork shows whether it fits and reads well.
In Paqira, sample content can be entered into a collection or imported from CSV or Excel. A collection is a place to keep related work together, such as the content for a group of labels.
With the artwork connected to that content, the designer can try different examples. Look at the longest name, then the shortest. Check what happens when an optional line is empty.
The designer and content colleague should review these examples together. One may notice that a heading needs more space. The other may notice that a sentence is difficult to understand when split across several lines.
Discuss the actual result. “This warning is hard to read at this size” gives the team a clearer next step than “the layout feels wrong.”
Keep test content easy to recognize
Made-up text is helpful during design and dangerous if it reaches a final file unnoticed.
Keep samples in a clearly named test collection or another agreed test area. Give them obvious names such as “SAMPLE — long product name.” When sending a preview outside the team, make it clear that the text and numbers are for testing.
Before production, check that:
- the person responsible for the content has confirmed the real file,
- the real data has been imported or entered,
- sample items are excluded from the production job,
- a test has been run with the real content,
- the generated artwork has been checked.
Give this list to the operator as well as the designer. The person running the job needs to know which items are ready to use.
Bring in the final text using the same fields
If the sample and final content use the same fields, the layout connections can stay in place. The values change, but the title still goes into the title area and the weight still goes into the weight area.
CSV and Excel imports can create or update several content items. An externalId is a fixed reference used to match an incoming product
with an existing one. A locale identifies the language version.
The colleague preparing the import should keep these references consistent. The designer does not need to rebuild the layout because a spreadsheet has arrived.
Paqira checks the file before import. The team must still check the imported words, numbers and languages before using them in production.
Keep the useful test examples
Do not throw away every sample when the final text arrives. A clearly separated test set can help when someone changes a font, a layout rule or a shared element later.
Run the difficult examples again and compare the results. Does the long title still fit? Is the short version left with an awkward gap? Does the last instruction continue onto the next page correctly?
The content colleague checks meaning and accuracy. The designer checks the layout and readability. The operator follows the agreed run and review steps.
They can all work from the same examples, with a clear idea of what needs attention before the final files are sent.