Many people assume design is a type of art. Those people are wrong. Yet, the assumption is understandable when the products of our work tend to be largely visual. Communicating an idea visually is pretty abstract and requires practice in order to think in that way. It is the reason young designers are required to express their ideas with sketches. Most people are surprised then to open my design sketchbook and see more words than pictures.
Writing is an integral part of my creative process as an interaction designer, so I have strong opinions about the importance of writing while designing. The writing I do every day falls into four categories: copywriting, strategizing, note-taking, and general mind dumping. I view them as undertakings that carry weight in the success of a project. I even consider them a responsibility to the user, my client, my team, and myself.
Everyone thinks differently and records their ideas differently, so it would be incredibly domineering of me to suggest that every designer becomes a writer. But I’m going to suggest that every designer becomes a writer.
Responsibility to the user and the client is in assuring them the product they’re using (or paying for) is quality. A good control of language and grammar makes a design appear intelligent and trustworthy. Well-written copy cannot make up for poor design; but, poor copy can most certainly bring a good design down.
The copy is actually as much a part of a design as the chosen typeface because it reinforces the identity of the app. The copy even has an extra element that visuals don’t have because in addition to an audience, it has a speaker. If the speaker is the app, then “who” is the app? The speaker will set the tone for the message being delivered to the user. When the messaging and the visuals are aligned, the app will have harmony.
Some teams already have copywriters for the designs or client presentations, but even the filler copy included in mockups can have an impact on how the design is received. Good writing is the same as what Jared Spool says good design is: invisible. A typo or poor word choice here and there may not seem like a big deal, but each one is a distraction. In a presentation, the client may become concerned about the spelling and grammar instead of the design, making it harder to get necessary feedback. If the errors go all the way to launch, they can even break the experience for the users. They could begin to see the app as ill-considered, which can even cause them to be more critical of the entire experience as a whole.
The designer’s responsibility to her project team is in keeping them informed of the design strategy. Because design is ultimately about solutions, everyone at ChaiOne is encouraged to think like a designer. That’s not actually as pretentious as it sounds. It means every person (production designers, developers, QA, project managers) is thinking of the user. When everyone on the team is on board with the designer’s vision, each person can make decisions that will benefit the user. Taking notes on the strategy behind the screens can help the designer organize her thoughts, but also educate her team members. A strategy can be as simple as detailing: this is how I understand the problem, this is how I plan to solve the problem, and here are my reasons.
Why is it important to do this? Why should it be in text form? Designers can’t think of it all. No matter how detailed the walkthroughs and specs, something will always fail to be thoroughly explained. It should be up to the developer or the project manager to ask for clarification of the designer’s intent, but sometimes they won’t. They get too busy, the designer gets too busy, and they’ll make an assumption about the design to keep their workflows moving. By writing and sharing the app’s strategy, the designer’s team members will be more aligned with the big picture, allowing them to make better decisions in their own roles to benefit the user. A well-recorded strategy will not replace the need for the designer’s input on details, but it’ll free the designer from some amount of micro-managing.
It’s not a developer or project manager’s job to design as much as it isn’t a designer’s role to code or manage project costs and the timeline. The strategy writing is about providing a team with the “why." They may only ask for black and white instructions, but adding the why can take them so much further (even if only in causing them to trust the designer’s decisions). Designers don’t just design screens, they design systems. It’s the designer’s job to inform everyone on the team how to use her system. This is about teaching them to fish instead of repeatedly catching them fish. A team that aligns with the designer’s views will be more cohesive. Cohesiveness will make the team more trustworthy to the client, and more trust means more freedom to make decisions that will benefit the user.
Not everyone on a team will be present in a client meeting, nor should they have to be. Capturing a meeting or usability session will help the designer remember details later on and help those who weren’t present visualize what happened. In order to do this effectively, context will mean everything. Remember missing a day of class and getting notes from a friend, only to find out her notes were incredibly vague and impossible from which to gain knowledge? It’s probably because they lacked context. When taking notes, a designer should employ the six Ws of observation: who, what, when, where, why, and how (which technically has a W in it). Record quotes; record emotions; record points and counterpoints; record distractions or moments of misunderstanding. The data is important, but the context of the data qualifies it, allowing the designer and her team to properly analyze the meeting’s events afterward.
Note-taking is also important for feedback received from other designers. If you are in a critique and receive feedback, write it down. Even if it’s someone casually walking by your computer and making a comment, write it down. You will forget. This is a responsibility to one’s self. Keeping notes on people’s feedback allows the designer to make sure to address every issue brought up. After doing this for a while, the designer can even look back and see the project’s growth as well as her own.
Free writing is a method in which a writer records her thoughts without stopping. The result is usually a lot of nonsense, but it can help the writer explore every node of an idea and get her thoughts out without inhibitions. Free writing, in this sense, may be a little extreme for most designers, but taking time to journal about a project can bring thoughts in the back of one’s head out into the open.
What do you understand about the problem you’re trying to solve? What is still unknown? What are some inconsistencies in the system? What is going to be a challenge? What are your initial thoughts on the direction of the project and how do you think this may change? Seeing the reaches of a project makes design decisions more considered.
Developing writing as a skill increases the designer’s ability to effectively communicate to the user, clients, her team, and even herself. Engaging in the thoughts and practices of a writer is really all for one purpose: telling a story. Whether it’s copy or notes, the story told is what will engage people and provide understanding.