Information needed to design

What information do you need in order to design something?

• The copy/text
• Assets (photos, etc.)

are probably the first things that come to mind. Both of these are pieces used when thinking through layout, and without them, you can't create an accurate design.

I think there are a few different kinds of information you need:

• Primary information: information that is displayed as-is (copy, media, functional elements like buttons, etc.)
• Secondary information: information taken into account while designing (target audience, the site's purpose, etc.)

It's a bit of a rough split, but you can divide it into primary and secondary information this way. At the very least, having the primary information ready to go is something I'd hope for as a designer.

A good design system is one that works well no matter what information comes in, but if a design can handle absolutely any scenario, then to begin with, there was no need to build it from scratch.

To come up with a design that matches the requirements, we want at least the primary information in place.

How far does "design" go?

Digging in a bit further, this leads into the question of what elements actually make up a website or web service.

The book IA Thinking: An IA Mindset for Web Producers and Practitioners includes the following well-known diagram.

It's quoted in all kinds of texts, and although from a different source, we also used it in this article (Knowledge for understanding what you're looking at).

*The process required to build a website, originally titled "Elements of User Experience" This diagram was redrawn by the author

Up through the "strategy" and "requirements" layers in this diagram, that information should already be in place as required information. Having things like functional specifications and content requirements organized into wireframes makes it much easier to carry over into design, and is a good practice.

If you're only given the "strategy" layer and try to handle the "requirements" layer within the design process itself, you end up with things like missing UI elements, or missing statuses that should have been accounted for when building out the functionality. Requirements are also often hard to picture from bullet-point text alone, which is exactly why wireframes matter so much.

Design can sometimes be seen as something that creates a "1" out of a "0," but there's a real difference in quality and in downstream work between design built on thorough preparation and design that isn't.

...Well, of course, it's always better if you can do everything. How you allocate your finite resources is an important consideration when it comes to creating something good.