Oct 07, 2013
Table of contents:
I think one of the most important steps in creating a new website or web application is the stage where you get everything out of your head and on to paper. Not only does this clarify what you have to build, but it also allows you to quickly iterate on your ideas within the real world.
Wireframing is often overlooked when a designer or developer wants to jump straight into the fun bit of actually making something. However it is easy to come up against a mental block of what you should be working on when everything is still abstract ideas floating around your brain.
Personally I find it really difficult to make progress if I don’t iterate on an idea on paper before I jump into Photoshop or code. I find releasing the random ideas on to paper allows me to create a coherent flow of connected thoughts and an actionable to-do list of steps I need to take to get there.
So if you are struggling to make progress on your project, hopefully this post will make the process of wireframing your ideas easy and something that you will do for every new project going forward.
Before I actually get into why you should wireframe and how I usually go about wireframing my projects, first I think it is important to clarify what wireframing is, and what it is not.
Wireframing should be used to solve problems that you will face when designing a User Interface and the corresponding User Experience.
This basically means, you should map out the common user flows, interactions and how the the user will progress from each of the main screens. I also like to solidify the hierarchy of the design, and how each element is placed within each segment, and then within the higher level page so that it is not confusing.
Wireframing is not about the design of elements on the page or adding polish to certain aspects. When you get caught up on these individual components, you end up with a design that is inconsistent and confusing.
Wireframing is an important process to go through because it forces you to get all of your ideas out of your head and on to paper. This allows you to see an overview of the entire application instead of it just being an array of disconnected ideas.
Personally I find it hard to fully imagine how something will work unless I can see it in the real world. When you put something on paper, you suddenly realise that some of the assumptions you were making actually don’t really make sense.
For example, you might have an idea about how you want a profile page to appear in your application. Once you actually draw it out and connect it with the rest of your application you might realise that this design might not be such a good idea.
Once you have wireframed the main screens of the application, you can start to connect them together through user flows. Again this will either reaffirm or expose the flaws in your initial ideas as certain actions will feel awkward once they hit the real world.
Once you start to build up a body of wireframes for the pages and the user flows you can start to think about how your main features will be placed throughout your application and to make this as simple as possible. I find this is usually a good technique for limiting your initial feature set. If you a struggling to fit everything together coherently, your initial idea is probably too complicated. You can always cut stuff out for now and reintroduce it later down the line if the feature still makes sense.
Up until now I’ve been talking about wireframing using paper and a pencil. Personally I find it much quicker to work this way as my wireframes are usually really rough and I end up throwing most of what I do away.
However I know a lot of people like to use professional wireframing tools and some people even like to draw wireframes in Photoshop.
It doesn’t really matter what you use to draw your wireframes. However if you are going to use a more professional tool than pen and paper, remember that these aren’t polished designs, they are about solving design problems. It’s easy to throw away a rough sketch, it is much harder to delete a photoshop document.
If you are required to present your wireframes to a client, you will probably want to clean up your work once you have settled on a design. Although I don’t personally use either of these, I’ve heard both Balsamiq and OmniGraffle are good for this.
As I’ve basically already outlined in this post so far, the following is the process that I usually take when wireframing a new application.
First I usually draw out the main screens of the application. For example in Cribbb, this is the signup page, the main dashboard page, the profile screen and the edit details screen.
On each of the pages I will usually keep drawing them until I stumble upon something I like. You will likely have a couple of components that should be consistent across most of your screens. There are many different ways to handle navigation in Web Applications for example, and so you should experiment with what works best on each page and then all of the pages as a whole.
Next I will draw out the main user flows. For example in Cribbb, I want the user to go from signup straight into a screen that gives context for what the application is about and what that user has experienced up until this point.
Joining discussion threads, posting new discussions and reading through comments are all important user flows that I need to get right in order to make Cribbb feel as simple and as intuitive as possible.
Next I will show how each screen connects to each other along my defined user flows. It’s really important to get this step right before you jump into Photoshop or Code because this is the entire architecture of your design. If you get this wrong, you will spend far too much time thinking when you should be creating.
And finally, I will always try as many different variations of things as I can for almost every possible thing that I draw. As I mentioned earlier, the huge majority of my wireframes get thrown away as I want to experiment on paper a lot before I get into designing things for real.
I see a lot of designers who want to design a specific feature or element on the page in a certain way because they have been inspired by how it has already been implemented on another website. This is a terrible way to go about designing an application because you are only looking at the end product and not the process of how the designer reached that point.
You can’t bolt on other people’s design choices into your application and so it is up to you to walk through the path of decisions yourself.
Once you are happy with your wireframes for each page of your application, it’s time to jump into Photoshop. Although it can be tempting to just jump into Photoshop even if you still have design problems left to solve, I would advise that you wait. I hate getting stuck on a problem in Photoshop because it ends up grinding my progress down to a stop.
I also find it much more difficult to have certain elements polished in photoshop whilst still having unsolved problems on paper. I don’t think you should ever be married to an element before you have solved all of your problems. If you spend a lot of time on something in Photoshop, you are much less likely to cut it if it no longer makes sense.
However, once you are happy with your wireframes, start working in Photoshop to bring life to your plans. Although I’m more of a developer than a designer, I find it much easier to design in Photoshop than I do in code.
A while ago there was the whole argument of designing in photoshop Vs designing in the browser. Personally, I think you should do whatever you want to do as these types of “best practices” usually depend on a lot of variables.
I do think it is a huge advantage to be both the designer and the developer however. For example, when I create a button in Photoshop, I know exactly how I’m going to create it in CSS so I’m not going to design something that is going to be impossible to create in code. I also tend to think about how elements are going to react in a responsive environment, so I usually just do the majority of my design in Photoshop.
If this doesn’t resonate with you, and you would rather design in the browser, don’t worry about it. What works for me, could be a lot different to what works for you.
Wireframing is all about solving design problems, not designing a killer user interface. I see lots of professional designers who are eager to jump straight into the fun process of creating something beautiful. The interface will often end up gorgeous, but it isn’t even close to being simple or intuitive.
Getting your ideas out of your head is not just important for designers, but also for developers. Even if you have no design skills, wireframing your application will allow you to see your ideas visually. This will make planning what you need to code much easier.
Wireframing is all about getting abstract ideas into the real world and seeing how they react. This is a really fun process of experimentation and creativity. Don’t skip it because you want to jump into what you know best.
This is a series of posts on building an entire Open Source application called Cribbb. All of the tutorials will be free to web, and all of the code is available on GitHub.