.png){kind=logo}
When it comes to words and phrases that cause issues in their varying interpretations, “wireframes” is only slightly behind MVP. It’s almost as important to understand (or at least agree upon) what they aren’t, as it is to align on what they are. Here’s a quick snapshot:
Essentially, wireframes can:
Wireframes are the most efficient way to get to a solution and collaborate quickly. They’re basic enough for iteration and detailed enough to deliver a plan. As innovators and product owners, you need to be open to to coaching business partners around what wireframes accomplish in the greater context of their project.
Fidelity – the degree of exactness with which something is copied or reproduced.
Speaking in terms of low fidelity wireframes vs. high fidelity wireframes doesn’t actually hold much water. Wireframes, by nature, are low fidelity. High fidelity screen comps offer visual design and come into play when it’s time to get a more final sign off from partners and development. In short, high fidelity is reserved for later in the game–when the cake batter is ready to pour and bake.
Many partners are on a tight timeline and are looking to get a prototype yesterday. As a result, there will often be requests or expectations to put something more final together to speed up the design-to-dev process. Similar to rushing the discovery process that aligns all of the project stakeholders, skipping wireframes has its consequences.
Much like a small child focusing on the color of a toy rather than how much they want to play with it, fixation is an obstacle for both clients and users. Users, especially on the younger end of the spectrum, are more savvy–which makes it more difficult to test a holistic experience. Fonts, colors, graphical elements–high fidelity comps provide many opportunities for them to run in place.
There’s often at least one stakeholder who rub his/her palms together, grabs a creative hat, and waits with bated breath to determine how much “it pops”. Providing (and receiving) feedback on visual design is always a special experience. Positive or negative, it is entirely too easy to flip the table over during the process.
Too much visual definition upfront spells potential detours. Wireframes are more about partner direction and alignment. Pixel-perfect efforts are NOT directional/conversation starters. More finished work focuses more on the particulars and delights of the end user experience.
How it looks vs. how it works. This is design territory–don’t put the partner in a position where they have to distinguish between UX and UI. More importantly, don’t give them UI BEFORE you have UX. Providing something pretty that presents no information around how to hit business goals and deliver on end user satisfaction is like lacing up your shoes only to walk away from the race. No one wins.
From a more tactical standpoint, it is much easier to update and iterate on an empty box than it is on branded, patterned, styled shapes. Never define product requirements with visual reactions.
Wireframing has been around long before any of the technology and innovations your teams work with today. Why does it remain such an important part of the approach/process? Short answer: Stakeholders.
When wireframing becomes an issue is when it isn’t part of the process. It’s the design process that is informed by discovery alignment. In many cases, teams are expected to start developing on day one, without discovery, sprint 0–or much of anything at all. This should NEVER be the case. Discovery, wireframes, and upfront processes dictate long term success. These components of a product lifecycle are not negotiable for the simple reason that both parties will suffer (and ultimately lose) in their absence.
Consider the reason your teams like to conduct user and/or market research. It’s not all that different from the reason you perform discoveries and put together wireframes, right? You want to define requirements and get support to stimulate the design and development of solutions.
Wireframes link teams internally–so design and dev can unite around a conversation that starts BEFORE the build. Applying what you’ve learned, plus best practices, to requirements in a way that encourages feedback–that’s what wireframes should accomplish for the teams creating them.
From the outside looking in, it’s fair to say you’re going to come across a variety of different approaches and design processes. For example, wireframing at an ad agency is going to be more of a mid-project milestone because they build a creative strategy and deliver creative concepts without actual deployment on the backend.
More full-service & delivery product development companies, however, require wireframes earlier on because they have an agile workflow that includes development and producing a living, breathing product. And then internal, enterprise-level product development is yet another set of circumstances. In short, your service provider, paired with your particular stage in the product lifecycle, determines when and where you will encounter wireframes.
Think of it this way. If you’re questioning the value of something low fidelity–would you ever buy all of your furniture before knowing where you want to live? Whether you buy pieces for family home and buy a condo, or you sell everything and end up with 4000 square feet–you WILL be spending more money and wasting time to adjust, late in the game.
Oh, good. You’re still paying attention. Of course they can’t. Nor can they save a failed app or redefine an audience. But it would be safe to say people who created solar energy, electric cars, and composting solutions made some rough sketches to drive their efforts forward. The more advanced technology, processes, and workflows become, the more we need low fidelity building blocks to achieve alignment and promote communication in product partnerships.
