6 Tips for Increasing Quality Through Wireframe Reviews
Check out these 6 tips to help you increase quality during wireframe reviews.
In product development, like all kind of development, the goal is to provide value to the end user. Throughout the development cycle, there are many different camps of people fighting for what they think will be the best product for the end user: the dreamers are pushing for hovering, mind-reading, space cameras; finance says a polaroid will be fine; the developer wants to use a digital camera, but integrate it into the system so it only takes one button to take and upload the shot; and the end user really just needs a profile picture for their LinkedIn profile page. How do you reconcile all of these different viewpoints and come up with one solution that everyone can get behind?
It’s important to have a conversation where everyone can mutually agree on what the most logical solution is to the end user’s problem and how that fits into the product.
Key agenda items should include:
1. Identify the Real Problems That You Are Trying to Solve for the User
What is the problem facing the end user?What pain points have they had with other solutions?What are needs versus “nice-to-haves”?Is this a problem that affects a large percentage of the product’s users?
As a team you want to tackle real issues that face the majority of your product’s users. Stay focused! Don’t tackle problems that are not really problems. Once you get into developing a product it is easy to dream up scenarios that may one day affect someone. However, if the issue at hand is not currently affecting a large portion of your clients, then it is not a good business decision to pursue solving it right away. You want to provide value to the end user and you do that by prioritizing solutions to issues that they face on a regular basis.
One of the biggest challenges is to pin down what is needed versus what is in the designs or the vision. Again, stay focused. Go back to the problem that you are trying to solve. If the plan no longer solves the problem, then be willing to adjust to meet the end user’s needs. Also, when talking to a sample set of users, listen to what they are actually identifying as a need versus a want. The first iteration of a product needs to solve problems; we may have time to get fancy and cater to wants in a later version.
2. Listen to Each Other and Be Creative
Make sure that everyone is part of the conversation
Everyone has a different experience and perspective to bring to the conversation
Be open to solving the problem in an entirely different way than what you imagined
Include the whole team including stakeholders in these conversations so that everyone gets a feel for what is important. Diversity of skills and experience foster innovative solutions. Make sure that everyone has a voice - make this time an open forum where everyone is free to speak and be heard. It is so valuable to have the whole team be in on the conversation about how to solve a problem or fulfill a specific requirement. Because people’s minds work so differently, someone could come up with a really simple way to solve something that had previously seemed convoluted or difficult. Talking through things ahead of time before jumping into a complicated solution will save hours of development time. Taking time to talk it through, include everyone’s input and come to a common solution gets everyone on the same page for how to approach the issue and ensures that you are working as a streamlined team.
Speak up! Developers and testers can be some of the best advocates for the end user. As a developer, if you start to build something that just doesn’t seem to make sense, bring that up. Maybe you are seeing some edge case that no one had considered yet and speaking up before you write code will save everyone a lot of time.
3. Deliver Something Simple That Solves the Problem and That Works
Development can be iterative, it doesn't have to be fancy or perfect on the first pass. A new functionality can have the wow factor, but if it doesn’t work or solve the problem, then it doesn’t matter how cool it looks. Get early versions in front of the whole team and the end user to make sure that it is providing value.
A problem in product development is that it is hard to break things down to a real MVP when you have a large vision in mind. It is really important to think about development being iterative - what you first release isn’t the end. There will be many more releases with improvements coming along soon, but you have to start somewhere. Get things functional and meet all of the most basic requirements so that you have a place to start the conversation and go from there.
It has to work. If you get through making half of a lot of different functionalities but none of them is passing QA and working, then you have made a whole lot of nothing. Work hard to complete each piece of work in its most basic form before you move on to something else so that in the end you have a functional MVP.
Make sure that if your product is going in the wrong direction, you figure that out fast! Getting prototypes and early versions in front of the whole team and the end user allows you to get early feedback. Use that feedback to guide the direction of the product to ensure that what you are building is something the end user wants to use and that it provides value.
Learn to value your team - every single member. Listen to the end user as they start to experience early versions of your product. Give them an open venue for sharing feedback and appreciate what their feedback adds to the product. And finally, actually apply the feedback and let it guide your iterative development process. It sounds crazy but some teams go through the motions of collecting feedback but then let their own egos dictate the requirements. Truly listening to your end users and your team members is the key to a successful product.
4. Discuss Pagination and Collapsing/Expanding of Components
The design for pagination directly impacts the scope of development. The same is true for how elements will collapse and expand. Identify areas of concern and discuss them with the team. For example: Will pagination use Ajax or page reloading? Will there be options for first, last, next, and previous? Is there going to be an animation when changing pages? What happens when you expand or collapse a component?
5. Focus on Accessibility
Your finished product needs to be accessible. Note components that might not lend themselves to keyboard navigation or screen readers. Note areas where users might get stuck in a keyboard trap. Ask if images will have captions; confirm that all images will have alt-text. It’s best to plan for accessibility up front before it becomes at risk of being deprioritized later in the development cycle.
6. Call Out the Oddballs
Look for inconsistencies or ‘oddballs’ during your review. For example: Is there a component that looks entirely unique? Is information being presented in multiple formats? Is the navigation consistent or different across pages? It’s possible that oddball design is intentional, but it’s best to confirm that it is before you start development.
Remember that your team is only human; it’s possible someone made a mistake or forgot to update something. When in doubt, ask. The earlier you question something, the earlier you and your team can get an answer and address any concerns. It’s cheaper (and easier) to fix a problem during wireframe review than it is during development.