Difference in People not Documents
Iâve been asked and have not yet given a satisfactory answer to the question, âwhat is the difference between wireframes and visuals?â
To answer the question we first do an internal review of the artifacts of each. Wireframes are usually pictorial representations of information, features and user scenarios (not an exhaustive list). Usually they appear sparse, black, white, gray, and have a lot of accompanying annotations. Itâs the first step in explaining an â experienceâ. You will of course see some âdesignâ in them as they are visual and they are solutions, but they donât capture everything and shouldnât capture everything. Visuals use wireframes as a supplement, as a sort of requirements doc. But the visuals take the experience and start to make it real. Through them the experience gets fleshed out, things are put in their more proper place, considerations for surrounding elements are thought out, things change becauseâŚ
Why do they change? This is the question we very often get from the client. And here is where the fundamental problem lies. Things change even though they had previously been approved. How does that make sense?
It makes perfect sense if you set expectations correctly. But thatâs a different story. We are talking about what happens more often than not, wireframes are delivered, approved lets color those wireframes in and get this bitch developed!
Lets focus not on the deliverables, but on who or whom is creating them. Imagine a scale, on the far left is the visually driven thought process and on the far right is the data driven process. No one good designer falls on the end of either. But the scale does shift and it shifts based on what we are creating. For wireframes the scale shifts more towards the data driven process. We ask a lot of questions about requirements, users, personas, research in order to create a framework for the software we are building. We start thinking about a lot of things that you canât actually see, but that are analyzed by how we use things. We start to build a conversation, sometimes a very boring one, between user and software. A part of that conversation involves presentation, but if we donât know what we are presenting whatâs the point?
From these thoughts and processes we return wireframes, ideas, checkpoints to make sure we have captured requirements, packaged the requirements into an experience and readied the team to move forward.
Now we must shift. And when the shift happens things change because we are now aware of more than just blank placeholders and gray boxes, weâve got color, real images, buttons and even more considerations specific to the device we are building to. A shift in thought and process has occurred, responsibility has shifted and changes WILL occur. But thatâs ok, because if we have done well as a team we will be designing with a shared vision in mind. Decisions and changes are made for a better experience and as time progresses, focus changes and new challenges come up. A designer or design team that doesnât shift will not be able to create a whole product, a full experience. If change is not allowed the product suffers because the shift was not allowed and the product remains at a stage not fully developed, not fully explored and ultimately not realized. Experiences live on a large spectrum that shifting designers explore. It is the mindset during creation and iteration that leads us to the differences between wireframes and visuals, not the deliverables.
