Recently, I had the opportunity to speak to classes at General Assembly, where I studied UX Design and first learned about creating wireframes. In the sessions with the classes, I had the opportunity to review case studies of the projects they have been working on, and to answer questions in a panel with other graduates.
One of the topics that always comes up in these sessions is wireframes—what software or tools do we use? Are we creating “low-fidelity” or “high-fidelity” wireframes? Do we need visual design skills to do our jobs? These are very similar to the questions that I had when I was a student. And interestingly, the answer to most of these is “it depends”, which was not helpful to me when I was a student, and probably not helpful to these students now.
In trying to answer these questions, I started thinking about what the situations are that determine the choices we make when we’re creating and presenting wireframes and realized that a lot of it comes down to who we’re creating the wireframes for. In the end, wireframes are a communication tool, and the tools and fidelity needed will depend on the client, the project, and how they’re being presented.
In the beginning, we’re communicating big, general ideas to our internal team. We usually start with low-fidelity wireframes as we are ironing out ideas. Low-fidelity means that the wireframes are black/white with no color or images, and tend to have placeholder shapes for images, icons, and blocks of texts. Our internal team will often begin wireframing with sketches on paper or whiteboards to get our general ideas together about what kind of information should be on a page or screen, using lines or arrows to note what the order of activity.
From there, we'll move into higher fidelity wireframes using software to provide more detail, including text and visual design elements. My personal favorites are Axure and Sketch App, and I usually choose software based on three factors. First is whether we have existing wireframes for this project that we’re building on, and what software was used originally. Second is whether we need a clickable prototype for testing. And third is will the visual designer on the project be building on the wires to make design comps, and if so, how can we work together most efficiently. As more detail is added, we’ll start to share the wireframes with the stakeholders in the project to ensure we are moving in the right direction and meeting expectations for the finished project.
Another layer of complexity in creating wireframes is when they’re for the development team. This part depends a lot on who that team is. The level of annotation and documentation required to communicate to an outside development team is much higher than with a team that sits in your office. Annotations and communication from design to development will be the subject for a future blog post.
In closing, this past weekend, I attended the IA Summit in Chicago, and heard Adam Polansky (@AdamtheIA) speak about “Fit & Finish: The Importance of Presentation Value to UX Deliverables.” Adam was able to express some of what I had been thinking very clearly, and his main points were that the level of fidelity will depend on two things. First is “What’s the least I can do to get my message across?”, and the second is “Who is my audience?” It was great to hear his ideas about how to answer these questions, and his insight will help me in making my design choices for future projects. I also look forward to incorporating his great suggestions about working collaboratively.
At Sagepath, wireframes play an essential role in ensuring we are delivering designs that are intuitive, encourage engagement and meet client expectations. If you would like to learn more about the value wireframing can bring to your web design project, drop us a line for more info.