From time to time, I get asked what design tools and methods I use for client deliverables, presentations, and final documentation. I thought I’d share the approaches that work best for me.
When Do You Need Deliverables?
Throughout the development of a software project, concrete rhythms, rituals, and deliverables make it easier for clients and project teams to feel progress. These might include iteration meetings, backlog planning sessions, design sprints, design mockups, and revisions.
However, deliverables can be helpful even earlier in the process, during the research, design, and planning phase. At this point, the activities can be more abstract, including workflow diagrams (which are drawings of mini drawings, lots of abstraction there), human-centered design activities with lots of sticky notes, and customer interviews. All of this can be a lot to keep track of. For me, it helps to provide deliverables to document these learnings for the client, internal team, and other stakeholders.
What Form Should Deliverables Take?
The research, design, and planning phase is about what you want to build, not how you want to build it. It requires creating empathy for real users, understanding the business, and immersing our team in the product ecosystem.
This type of work does not lend itself to shiny visual designs or finishing features in code, so creating an appropriate deliverable is critical to helping my clients feel like they’re along for the ride. A polished deliverable that is appropriate for the client can lead to great understanding and more clarity in future work.
There’s no one-sized-fits-all design tool that I use for every project. Different client situations call for different solutions, and varied levels of fidelity. Here are a few of my favorites.
These are great for mood-boards, gathering UI inspiration, competitive analysis documentation (of visual design), and later in the process, style guides. They’re also fabulous for pulling together a polished deliverable quickly. InVision Boards are constrained, not meant to be customized (fonts, etc.), and have a simple setup that makes for a really flexible tool.
For highly collaborative projects, Google presentations are the way to go. They’re good for design briefs or presentations that explain complicated workflows, context scenarios, personas, etc. However, I don’t use them for detailed, custom decks for clients. I prefer to keep things simple: black, white, color for simple diagrams, and quite minimal. Ideally, this deliverable should be viewed on a screen, rather than in a printed deck.
The most robust of the tools I use for compiling and synthesizing projects is InDesign. Our design team has been creating project templates to make our client deliverables more efficient and professional looking. Using InDesign lets us choose font systems and layouts that will print well, so we can deliver a finished product guidebook prior to beginning agile development. These guidebooks are meant to summarize the work done during our research phase, documenting key decisions and other design activities. We can also fine-tune the design of the document to reflect the client’s brand.
Despite these three design tools being my current favorites, the tools I use to document our human-centered design and visual design processes are constantly changing. It’s just one more reminder not to get too attached, and to remain agile in our work.