In digital product development, prototypes are a great way to dig into a user problem and see if an idea is solving that problem. Prototypes place your ideas in the context of user devices and workflows. This context makes you think about all of the interactions your users will have and also helps to clearly communicate the idea to other people.
Clearly communicating to others is one of the biggest benefits of prototypes, because whether you’re sharing your work with an internal design team or a client, they are able to see for themselves how an idea functions. They aren’t left to their own interpretation or guessing, making it easier for designers and “non-designers” to have productive conversations around feedback and sharing ideas.
While using prototypes to communicate ideas better is a typical part of the design process, there are a few things to consider to bring others into your process and turn them into strong, meaningful design partners.
Share Early and Often
Before you get too deep into an idea, share your work, be open to hearing other people’s ideas, and keep iterating. This can be hard, and you may feel like your idea might not be ready to share; but it can make people share feedback more readily when they don’t think you’ve invested a ton of time on an idea. We all want to portray that we know what we’re doing at all times, especially at work. It’s natural. But we need to let go of our ego to truly open up our work to others. It makes the work stronger.
At DockYard we work on teams that are typically made up of a lead designer, supporting designer, lead engineer, supporting engineer, front-end engineer (we call them UXD and if you don’t have them, you should get them), and project manager. There’s also the client side of this team, which can be a few people, but at the very least it’s a product owner. That’s a lot of people to bring into the process, but knowing everyone has the same goal — to produce a product of high quality that solves a real problem — should put you at ease.
Great suggestions and ideas come from all disciplines, even those beyond design. Engineering often brings thoughts on what’s feasible to build within a timeline; UXD comes from the perspective of accessibility and feasibility; and the client often brings a business perspective. But everyone is thinking about the end user, and all of these perspectives offer insight into the experience. So invite those perspectives in as early as possible.
Putting together quick prototypes that demonstrate a few ideas and sharing them in Slack channels with the team or jumping on a video call to walk through them early on will get people in the mindset that they’re involved in the process, too.
As much as you might feel productive by designing heads down for a week or two and then presenting your work to the team or client, I’ve found this to be counter productive. It takes longer to review and leads to more rounds of large changes versus quick rounds of feedback and iterations. Working in a silo also sets the precedent that you are handling the idea generation on your own and they are merely providing feedback on your ideas rather than contributing to them.
Hi-fi vs Low-fi: Strike the Right Balance
The level of fidelity can be crucial to your new partners’ understanding of a feature. Sharing unpolished prototypes is just fine as long as you preface that they’re unpolished. I like to set the stage for everyone and reiterate what the problem is, the constraints, and the level of fidelity the prototypes are at. This eliminates any thought of, “Is this what this is going to look like at the end?”
Design systems have enabled prototypes to be put together quickly. If there’s a solid design system in place, we’ll usually get right to prototyping using styled components. In either scenario, I explain to the team and client what they can expect to see.
Whether it’s a low- or hi-fidelity prototype, using representative data in your prototypes will push the boundaries of your design by revealing areas where it may break down, and the data will allow your team to see the user experience in context. No lorem ipsum here, unless we’re talking large paragraphs of text. Even then, there are article copy generators that are probably better suited.
Offer Specific Feedback
Providing design feedback is a hard thing to do, especially for clients who don’t do it often. To set up yourself and your team for a successful feedback session, you need to tell stakeholders what feedback you need. Early on I will usually say I want feedback on the user flow, interactions, feasibility, and the proposed solution in terms of meeting key business and user goals.
If there are placeholders in the design or things in draft form, such as styling or certain interactions, I will say that I’m not looking for feedback on those items at this time. I’ll be upfront on things I’m unsure about or any problems I encountered and invite them to brainstorm solutions.
Depending on who I’m meeting with, the client or the internal team, and assuming they’re not in the same meeting, I’ll let them know that any ideas we come up with will need to be run by the other team members. This leaves options open to be explored, but also sets the parameter that we are still exploring, and any proposed solution will need validation. As we get further through the process and have gone through a few iterations, what feedback I look for becomes narrower and more specific.
Ensure Proper Hand Off
When handing off designs to developers and engineers, the designs shouldn’t just cover a single mocked-up state for each screen. Every state should be captured, not just from the UI side, but for the user workflow as well. What is the ideal state? What happens when there’s a partial state? What happens when there’s an empty state? What happens when there’s an error state? What happens when things are loading? It can also be really valuable to document any gaps in functionality that the prototype doesn’t cover. Hand offs are never exactly that, there’s usually some back-and-forth needed for clarity, so make sure you’re carving out time to answer questions that come up.
Create Meaningful Design Partners
Whether designing custom software, mobile, or web applications, prototypes are powerful tools in the digital product design process, and it’s a designer’s responsibility to make sure that everyone is equipped to use them the right way at the right times. Don’t just prototype and share your work to fill a checkbox: Really take other people’s perspectives into consideration when reviewing them. By treating prototypes as an evolving representation of the team’s collective ideas, instead of as precious artifacts, you’re creating valuable design partners who will have meaningful impact developing stronger digital tools that benefit all users.
DockYard is a digital product agency offering custom software, mobile, and web application development consulting. We provide exceptional professional services in strategy, user experience, design, and full stack engineering using Ember.js and Elixir. With staff nationwide, we’ve got consultants in key markets across the United States, including San Francisco, San Diego, Phoenix, Dallas, Detroit, Miami, Pittsburgh, Baltimore, Boston and New York.
