Introduction to Wireframing and its Principles

What is Wireframing ?

A wireframe is a layout of a digital interfaces that demonstrates what interface elements will exist on the page. Its commonly used to lay out content and functionality on a page which takes into account user needs and user journeys.

Especially in agile enterprises and startups where there is collaborative and iterative nature of product design and development the importance of Wireframing is more crucial. They play invaluable role in sticking everyone on the same page and see the glimbs of how the information, user journey and layout of the application is structured out.

Why Wireframing?

Wireframes serves like blueprint for design. They lay down path for conceptual structuring out application whether its visually or structurally. Wireframes helps us in communicating following points:

Content: It helps us to know what are the contents which are displayed on the page.

Structure: How the pieces of the application can fit together ?

Information hierarchy: How are the information organised and displayed together.

Functionality: How will the interface work ?

Behaviour: How will the users interact with the interface ? And how does it behave ?

The actual purpose of wireframes varies with the people creating or using them. Its more of like conveying the information we need others to know whether we hand sketch it or prototype it for other to take the clear vision of the product.

Who Uses Wireframing?

Interaction designers, UX designers, Information architects, Illustrators, Graphic designers, Developers, Business analysts, Stakeholders, Usability ExpertsProject managers, Executives, Partners, Clients and more other people are benefited with the process of wireframing.

In short everyone involved in the making of the product uses and are benefited by wireframes.

Image for post
Image credit: Unsplash

Principals of Wireframing:

  • Start with users and know what they need:

First its our responsibility to understand who is going to use my product and what will he/she do there? What we should do is design around those individual needs and user flows to satisfy those user needs. where we first identify and think about the real user needs.

We need to develop a sense of empathy and apply it into our product. The problem of the user is our problem and we are the main person in the problem solving process.

  • Plan little — do the rest:

Great products are great and successful because they are built upon the plans. The questions are to be clarified before we approach the process. The questions might be alike:

  • Who are our main users?
  • What are the user needs and goals?
  • What are the business needs and goals?
  • What existing product or design patterns work for your users and business?
  • What are the gaps in what’s currently out there?
  • What are some product requirements you have given your users needs and goals(as well as those of our business)?
  • What are your constraints (i.e. time, resources, money, skills)?
  • Setting expectations — not just goals:

What are the steps in the design pro- cess, who is involved, what are the deadlines for each step, what level of fidelity is necessary to properly communicate, and so forth. Think about what you expect of others and what is expected of them, but try to keep it simple so you don’t get in trouble.

  • Everything has meaning:

Our product sketches, wireframes, and prototypes are methods of communicating just like any language in the world. Every piece of text, colour, gradient, shadow, shape, and image you put down has a meaning, just like there are definitions for every word.

  • Be consistent, not uniform:

If possible we need to use the same design language/patters to communicate with our users help them to familiarise with our product.

We can’t imagine every scenario and write rules for it like a design style guide. Every circumstance is different and should be addressed on its own terms. What unites things, therefore, should be a consistent approach — one that users will hopefully come to understand and trust.

  • Low-fidelity doesn’t mean unrealistic:

Whenever possible we need to add the details that we will need, even though we are doing the rough approximations. The common problem is when we think the paragraphs were going to be 3 to 6 lines long because those bulk paragraphs may effect the overall look, feel, emphasis on the page. So real contents and images should be tried to incorporate despite its low fidelity.

So scrap the “Lorem Ipsum” and get realistic about what you’re trying to convey to your users as early as possible.

  • Experiment and Collaborate:

The best way to build an effective product is to grow something small and evolve it quickly and iterate widely. With the help of iterations we turn small failure into lessons.

Low-fidelity design helps us and our team to explore many potential solutions quickly before focusing in on one solution and polishing and refining it into the final product. Initially, it may appear there are many solutions to a design challenge. However, you can only decide which will work best after exploring a few of them and laying them out in front of you — to see, touch and feel. Inexperienced we designers will over-commit to their initial ideas and fall in love with what is likely the wrong solution — good designers know better.

Ultimately, we are working in the wrong fidelity if you can’t product concepts quickly. And you’re wasting precious time if our wireframes are just grayscale versions of a design you already have your mind set on. Use wireframing as a means to an end, not the end in itself.

  • Our designs will be built:

A great design can take a form of terrible solution. The every animation, boxes, modal, gallery, map and other elements needs to be coded. We can draw and make ideas before us faster but it takes a lot of time and skills to make it work in the real sense. Every project has budgetary, time, and resource constraints, and you should internalise that with everything you add to your wireframes, even little components – there are no small changes, and there’s a trade-off for every decision we take.

  • Shipped is better than perfect:

The goal of sketching, wireframing and prototyping is delivering a great product concepts not actual deliverables. Everyone in the team wants us to communicate the right level of details about what they need to do to make a great feasible solution so they can ship better products much faster. If we have sketched something on a paper which may seems like a solid solution to the existing problem, there is no value in re-creating it in a wireframe or high fidelity.

In some cases, we may have to quickly replicate it for organisational purposes, but lets don’t make deliverables for the sake of it.


Our wireframe should be a visual guide to the framework of your product and how it will be navigated. Looks and visual appeal are not factors at this stage. Our main concern with a wireframe should be presenting our content in a way that is familiar to users of this kind of service.

Our mission is to make it easier for your users to accomplish their goals. By presenting our information in this way, we are aligning the business goals of your product with the needs of our users.This provides the project team, specifically the designers, confidence in moving forward. Wireframes will also save considerable time and money in the testing and amends phase later in the work process.

As a designer we have lot of online tools available to build our wireframes. For choosing a best tool what fits us in our workflow, I would recommend an article written in Toptal blog entitled “Form and Function — A Guide to the Top Wireframe Tools” by Shane Ketterman.

Deja un comentario

Scroll al inicio