A huge part of being a designer is creating deliverables. They are a means for us to communicate our ideas on how a product should work/look/feel to clients, stakeholders, developers, and other team members. If used properly, they can be an extremely effective and efficient way to convey your designs.
But not all deliverables exist for the greater good. Don’t be a slave to the deliverable and some predefined process. Just because other projects required a certain set of documents doesn’t mean that all projects should. Creating deliverables for the hell of it wastes your time and isn’t helpful in moving your project forward. As a designer, you should assess the needs of your project and create a deliverable that will speak directly to those needs.
Don’t just create deliverables. Create the right deliverables.
Let’s use wireframes as an example. Wireframing is a crucial step in the process of creating a website or app. This we know. They’re the first visualization of your new product and the foundation the rest of your team (developers, visual designers, and everyone in between) will be working from.
But wireframes can come in many flavors. Some are crude drawings on the backs of a bar napkins while others are highly detailed, computer-generated documents. Which should you create for your project? Should you add annotations? Clickable hotspots?
The answer, as with just about anything in our industry is it depends. There is no “one-size-fits-all” solution.
So, how do I decide what type of wireframe deliverable I need?
Just like the product you are trying to build, you need a strategy. You need to:
Define your audience Who is this for? Developers? Stakeholders? Other designers? As with anything you design, you need to know who you’re building this for.
Find their needs What does your audience need from this document? Why are you creating it? Do they even really need a document?Answering these questions allows you to focus on your goal and helps you avoid spending egregious time creating deliverables that are overproduced or unnecessary.
Build a deliverable that speaks to those needs For instance, if I’m creating wireframes for a couple of other designers I sit next to all day, I probably won’t give them every single screen (just the complicated ones), and I probably won’t annotate them much (if at all). Something as simple as a whiteboard sketch could work in this case. But if my audience is a group of developers who are thousands of miles away and collaboration will be limited at best, I’m going to create a more refined deck of wireframes, and they’re going to include tons of annotations and functional requirements. I might even throw in some clickable hotspots or animations to make sure the concepts are completely clear as a standalone document.
When it comes to design, the end user isn’t your only user. You have clients, stakeholders, developers, other designers in between, and you need to consider these people when creating your deliverables. User-centered design isn’t just for people who use your end products. It’s for your collaborators too! Use it in everything you do — making deliverables, writing emails, speaking with stakeholders, etc. It’s all a big design task.