Designing a Website with Content Entry in Mind
Hey designers: Does content entry every break your designs?
Imagine this scenario. You send your beautiful website design to your developers, who do a dynamite job at coding it to the letter. Then content entry rolls around, and suddenly the text is overflowing containers, images are skewed, and the whole layout looks unbalanced.
Why? What happened to my beautifully designed-and-built website? I’ll share some insight into the development process that may help explain this situation.
When developers receive a website design, their goal is to build the website to match the designs as closely as possible. Which means they will copy the exact images, colors, and text you used in the designs. The key aspect to note here is the text. That is because the text is the most variable, especially if the designs include placeholder (e.g. “Lorem Ipsum”) text.
Take the below example: The designs show an image with a centered word on it. But when it comes time to launch the site, the site owners decide they’d prefer it says a sentence. The sentence isn’t centered, it overflows the dark center part of the image, and hits the sides of the window, making it look off balance and difficult to read. The developer thought that the text was only going to be one word, so they didn’t account for a longer wrapped phrase in their development.
In the below example, we have the opposite situation: the designs specified 2 columns of text, but the text ends up changing from a paragraph of text to just 1 sentence. It’s easy to see here that the page now looks off balanced and bare – definitely not the effect the designer was going for!
What we can learn from these examples is that both designers and developers need to account for what real-life text will be entered in the website. This can be done by following a communication system regarding text right off the bat: the designer asks their client, copy-writer, or whoever will be responsible for entering content: “What length of text do you expect to go here? Can you quantify it in words, sentences, or paragraphs? And most importantly, is it subject to change?” There is a good chance the answer to the last question is “Yes”, or “I don’t know”. In which case, when the designer passes the designs to the developers, he/she can point out “in this section, there is one sentence, but the client said that it might change a couple of paragraphs.”
This up-front and early discussion around text length will allow the developer to keep this in mind while coding, which might lead to some conditional fields based on the length of the text, or a more lengthy conversation about the need to change the layout to accommodate the text. Overall, this will lead to a smoother QA process, and fewer post-launch fixes. A win-win-win for the client, designer, and developer!