When scoping work early on a project, I ask myself and the team, whose hands are receiving our deliverable? As researchers, we too often instead ask who’s best served by these deliverables but sometimes fail to see the reality of the situation. At the end of a project, we’re usually a few steps removed from the hands that make the thing, e.g., engineers and product designers who design and develop our recommendations. So how can we shape our handoff to better suit those in between?
In this case, we’re working closely with product managers that are early in refining their product strategy. Development and design resources haven’t been allocated to them yet— really, they’re still making a case for what to develop and why.
High-Fidelity Mockups and Prototypes
Deliverables that don’t line up, in my mind, are high-fidelity mockups or prototypes that show “the way” forward. We don’t have enough here to be that prescriptive. Nor does it serve anyone to paint a “big picture”— it’s too easy with early design work to design without constraint, and that does little to give us our first step on what to launch.
Reflecting on our audience, their needs, their decision power, and the capabilities at their disposal— some considerations come to mind:
- Deliverables should be editable by the client; nothing is fixed yet; therefore, our client should be able to edit our designs based on what they continue to learn
- Deliverable should easily translate to the client’s voice, and our client should be able to take complete ownership of all the material around the designs
- Deliverables should be easy to present, shared, forked, and collaborate across— teams haven’t spun up, the work hasn’t been declared yet, so what’s the work that happens before implementation, and how can we better support it?
In thinking about a flexible medium, it’s pretty clear that Figma would be too high-brow for us. No client should have to learn a design tool from scratch to make small changes. Nor would a PDF or deck help— how can you modify or adjust static screens? What tangible collaboration can happen around a static slide?
So we landed on Miro, both as our design tool and as our deliverable. If you’re unfamiliar with Miro, briefly, it’s a digital and collaborative whiteboard that supports a variety of work. In this case, we used it to develop early screen concepts and wireframes.
We felt Miro’s intentionally limited toolset and client familiarity set us up for success. It’s easy for clients to clone our boards, fork our designs, and most importantly— modify any element across any screen.
What does our deliverable look like in the end?
Everything you see here was made in Miro. We used an icon library plug-in, and the rest is just text and boxes. The point here is for our client to continue to refine, shape, and test these concepts. It’s in support to narrow these initial features down to that single first step they can begin to implement.