Whether you are a designer, developer, project manager, or executive, you are writing as part of your daily job. Taking meeting notes, commenting on agile boards, writing emails, chatting on Teams, sketching an idea on the corner of a notebook—as multi-disciplinary creatives, we are using writing as a tool in almost every aspect of our jobs.
When working with designers, there is an assumption that the only output of their work is design; from wireframes to UI assets, it can seem that these are the only deliverables that matter. Let’s instead focus on the designer’s process of writing and how he/she can bring writing as a collaboration tool to the larger team.
The end-to-end process of user experience design is much more than visual assets. Working in distributed, multi-disciplinary teams, a designer’s objective is to create continuity and clarity around the problems that are being solved and deliver a visual solution. Great user experience comes from a deep understanding of the user’s problems. Designers have a process that they use to get to these solutions, and it can be really valuable to bring these processes to the greater team.
The act of putting pen to paper can be the first step in the 'design thinking' process. Stating clear objectives, writing problem statements, taking meeting notes, commenting on user stories, and annotating designs are all part of the design process.
Synthesising a project from inside your head to a fully thought-out concept is the challenge. Doing this in a team where people have multiple views can be even more complicated to get everyone on the same page. When you write out the ideas, it forces you to articulate the problem and start making decisions. It creates an artefact that can be shared, edited, and rethought.
When projects start with a written objective, it evens out the playing field in internal and client-facing meetings. It makes the thought process accessible and understandable across all disciplines. When business owners, clients, developers, designers, and project managers are working in tandem, having statements can create alignment in the thought process of the design, feature set, or core problems.
Ways to Write About the User’s Experience
Writing can exist in more concrete forms, and it can occur in more casual ways like comments and handwritten notes. All of these are valuable and contribute to the process of building a product. One of the best ways to synthesise design—whether it is a new concept or a feature for an existing product—is to write out problem statements, use-cases, and goals for the project.
Write a few sentences that summarise the core problems that the product is attempting to solve. This statement should be a cohesive and clear set of ideas that encompass the overall concept of the project.
Core scenarios that summarise ways that users interact with the product help to create a feature set within the product, app, or website. Use-cases can be from the perspective of many different users, and they tend to start with who the person is, and what they would like to accomplish. Once you are done writing all of these scenarios, you can break them into ‘core’ and ‘edge’ cases. The product or feature should aim to solve the core use cases in the most pronounced ways and handle the edge cases with minimal interference to the main feature set.
Goals trace back to the problem statement. Each feature's goal should directly align with solving a problem. For example, the user's goal is to create a new post or search for a city. Would building this feature help the user accomplish his/her goal? Does this button lead him/her to create that post?
When a team is reviewing a design, having a deep understanding of the problem that the feature is attempting to solve creates a much better field for gathering feedback. The conversation around the design morphs from nit-picky color conversations to deep functionality and flow discussions, e.g., “How does this button accomplish this goal?”.
Often, when there is indecision on a project, it can mean the problem is not clearly defined. Without that clarity, it can be hard to discuss the reasoning behind building anything. When you can track decisions back to a clear problem, the logic of the solution tends to make more sense.
In a developer-centric world, requirements are the core of the project. It is a designer's role to understand and contribute so that the output of the design matches the goals of the user story. Even though this exercise does not happen in design software, the conversations that shape the product are also designing.
Requirements are made up of user stories, which align business objectives, design, and development towards the same goal on the same timeline. Often, user stories seem like more effort than the individual design or development task, but they provide necessary agreement on the functionality of each feature.
Probably the most well-known written deliverable from a designer is annotated wireframes. Documenting design in the form of wireframes can save hours of miscommunication. Without annotations, the wireframes are open to interpretation and assumptions. Useful wireframes identify key functionality, flows, and error states. The output of the wireframes is just as organised and comprehensive as the product screens they contain.
Keeping up with the changes in the product as the developers work can also be a challenge. Part of agile methodology is to be flexible and change course when needed. Updating designs and following along with developers ensures a seamless production process. While working with developers in an agile board, many of the critical decisions progress in the comments or emails. Keeping up with the changes, offering your opinion, and creating clarity in the comments can be some of the most productive work a designer can do. As the product constantly evolves, designers can contribute to changes by commenting and updating designs in tandem with developers.
Designs have a life beyond the immediate team members of the project. When you are not in a meeting to explain every feature, or when you pass the work off to another designer or development team, that legacy of information gets lost and may be open to interpretation. The problem statements, use-cases, wireframes, and comments house the decision process of the product.
Wireframes can also end up in legal and security reviews, where the teams need a quick understanding of the product without any explanation from the designer who worked on them. These can be passed off to educate anyone new to the product. Other times, design concepts end up in the hands of product owners or executives that need to present the project. The written artefacts that are created to present the concepts, design, or feature can be just as important as the design itself.
Write About It
The next time you go to write an email, comment on a thread, or talk about feature sets in a meeting, try framing the conversation in problem statements, use-cases, or goals to align the team and track back to core ideas.
Getting cross-functional teams to have the same discussions about a project will create a better atmosphere for collaboration and alignment. Reinforcing ways to communicate by writing, sharing, and editing with team members from multiple disciplines helps everyone to be on the same page. As a designer, think about the mileage of the artefacts that are created for a project, how often they are used, and how they need to stand on their own. The value of clear direction in design documentation can provide clarity and continuity, from the smallest features to entirely new project ideas. As a team, we can elevate our writing to make a collaborative and streamlined effort in our agile world.