It’s a known truism that it is cheaper to prevent issues than it is to fix issues. Defect prevention is a crucial activity for the project team throughout the software development life cycle, including the design phase. Below are 6 tips to help you increase quality during wireframe reviews.
1. Identify Each Unique Component
Unique components add to development and testing time. When reviewing wireframes, identify each component and where it is used. Look for components that seem similar but might have slightly different behavior or testing needs. If you are unsure whether two components are intended to be the same component, just reused, ask the design team for clarification. Identifying components that are similar enough to be reused but do not have a compelling business reason to be unique, helps streamline both design and development efforts.
2. Look for Interactive Components
Do not assume; ensure that you confirm with the designer where interactivity will occur and how it will work. Be specific about which components will be interactive and which will be static. Discussing interactivity early in the design stage can prevent scope creep, identify potential usability concerns, and contribute to a shared team vision. For example: In the case of a card component, will it have a hover state? Will the entire card be selectable or will there be multiple links embedded in the card? Will the card flip when selected?
3. Note the Common and Required Breakpoints
Wireframes should take into account mobile and tablet breakpoints as well as desktop. There may be project specific breakpoints as well. Don’t hesitate to ask about a breakpoint you don’t see it represented or to question a specific component that doesn’t seem mobile-friendly. Maybe it got missed, or maybe there’s a plan that you haven’t seen yet. Talking about breakpoints early avoids surprises down the line and ensures that devices are kept in mind throughout the project.
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.