Adding text to your wireframes is important. It can be just text blocks, but it’d be better to start thinking about real text, at least in its length and size.

Preparing for text content takes a lot more work than most people expect with a project. Here are some handy tips to help you plan ahead and write for humans.

When you are brainstorming ideas and sketching out rough concepts, you'll represent text as blocks or squiggles. In this early stage, you just want to show the placement and hierarchy of the text elements.

Iterate version 1

After getting multiple ideas out and doing some other design activities, it is time to go digital with your wireframes. If you are using Balsamiq, you can use the text blocks as shown above, but this is also a good time to start thinking about text length. How much copy do you want to put in that place? How long is the headline going to be? The page title? How about that informational paragraph?

To get started you can use dummy text. You've probably seen this kind of text a lot. It is referred to as "lorem ipsum" text, and no, do not try and read it and figure out the words. 😉 It's a modified form of Latin used since the beginning of publishing text on paper and is meant as placeholder text that is expected to be replaced by the actual copy.

At this point in time, if you haven't already, it's time to start getting the UX writer and copywriter involved in creating the content for the website or app. So you have the general placement of the copy, but you can help out your fellow teammates, such as writers and developers, by telling them exactly how much room they have to work with.

A cool little trick in Balsamiq is to use the character count on the text UI control.

See that little number on the top right of the box? That's the number of characters outlined in blue in the text control. So if you like the size of the paragraph showing in your wireframes, you can tell both the copywriter and the developer that this space is limited to 336 characters. The copywriter will write around that amount and the developer will code that element to just show that many characters and it will be easier to place other elements on the screen.

When you are designing for both mobile and desktop (known as responsive design), it is important to keep text size and length for different screens in mind. What your text should do is adapt to the screen size and be larger on the mobile device and wrap in a way without you, the user, needing to scroll right and left. (See the second image above). There are multiple ways to do this in code, but from a wireframing perspective, you just need to show how the text will wrap and the hierarchy in the wireframes.

Iterate version 2

What you have been designing so far is what we like to call the "happy path." That means that all your content will fit nicely, there will be no errors on the screen, and you will have all the content you need by the launch date.

It's a great place to start, but the work doesn't end there. Now it's time to plan for what we call "edge cases." Edge cases are anything that can go wrong, will probably go wrong, and any unexpected uses of the software or the presentation of content. An edge case can be expected or unexpected.

• For text, this means creating a list of possible errors for every form field. Write them in the company's tone of voice and make them succinct and useful.
• Remember when we talked about character counts? Well, what happens when there are only a few words of text for that space? Or a lot more text than you allocated? What happens to the extra text and other elements on the screen?
• What about localization? Some languages, such as German, take up a lot more space and can mess up your layout if you don't plan ahead.
• What about the text as it resizes for different devices? This is the time to think through your responsive web design and how your font sizes will display on various devices.
• Finally, don't forget about the text to help with accessibility. Alt text for images, links, and buttons should not be randomly generated by code, it should be written by a human.

Take the time to plan for as many edge cases as you can and don't leave it to the last minute. Your writers and developers will thank you.

Production

Finally, it is launch day. You release the creation to the world and the next day you get an email from a customer about a typo. Don't fret. This happens and is the nature of things. Of course, you and the team did your best, but mistakes happen. Iterate again and in the next release make sure you make as many minor fixes as you can.