Thanks for coming back! As we’d talked about on the 21st of October, we’ll be continuing the final portion of our 3-week blog article on the importance of preparation and research before interacting with a developer on your next project. With that said, we’re going to dive head first in to wireframing and prototyping.
On the agency’s end, the final stage in the development planning process — usually done before any real coding has begun — entails getting large portions of the application sketched out. You heard that right: This means the development team, or most likely the project manager, will physically draw each of the screens that a user is going to interact with. Of course, there’s software that can quicken this process quite a bit, but you get the drift. Wireframes are essentially outlines of the most important parts of your project. The term “wireframing” was coined because a lot of the time, this portion of the layout looks a bit like they were made from pieces of wire. For an example of a wireframe, click here.
Wireframes can be made either by hand or with a wireframing application. A good set of pencil sketches on white foolscap can help bring the scope of the project — and all its’ features and functionality — down to earth. Wireframes can really help the overall vision become more than just a vision. Microsoft Powerpoint is also a popular, albeit imperfect, tool for creating wireframes. However there are a number of really good and easy-to-use software applications out there that make the process a little easier. These programs usually have libraries of common elements you’d see on a website, mobile app, or desktop application. Things like scroll bars, buttons, forms, etc., are all pretty much drag and drop. Currently, we use a wireframing tool called Balsamiq; it’s easy to use, and as close to an “industry standard” that you can get. Usually, however, your developers should be the ones actually creating the wireframes, and getting feedback from you on them. This is a three-fold strategic decision:
1) In building the “wires”, your developers will be able to show you how they think, and be able to prove they know what they’re doing.
2) Hopefully you’re paying the developers because they’re experts. Getting into the actual flow of a system can be quite daunting, and unless you’ve got a lot of experience in creating these types of documents, they’re not as easy as you might think.
3) If your developers are building out the wireframes, they might come up with creative ideas that never occurred to you during the initial planning. Make them earn their money.
When constructing a wireframe, keep in mind, they are NOT going to look like the actual end product. They’re really just meant to capture the overall functionality and feature-set of the application / user experience. You are not trying to do the graphical design of the entire product. Usually, wireframes go to both the developers (so they can understand what they have to build) and to the designers (so they can see what elements they have to design.) I actually prefer wireframes that look like sketches on the back of a napkin, because they don’t give the designers too many preconceived ideas as to what you want your final product to look like, and you can maximize their creativity as a result. More on this in the next section.
On to prototyping. This is the final, albeit one of the most overlooked, phases in the planning process. Building an actual working version of something before you produce it is common in the manufacturing world, but it doesn’t always make sense in software development. Instead, when we talk about prototyping in programming, we’re normally talking about wireframes that are actually clickable. By this I mean you get to see your cocktail napkin sketches on a screen, or phone, or whatever, and can interact with them in a very basic manner. I know this may seem like an odd, and possibly redundant step, but it is incredibly useful. The reasoning is that while wireframes are great, you can’t really test them on other people without explaining every step of the process. This is a problem for larger, more complicated systems. A button that generally saves an action (“Save”) might make perfect sense to you, but a user might be expecting it to save their work, and close the screen – a subtle, but important difference. Doing simple user testing with co-workers, potential clients, friends, family, or even random retirees you meet at the airport terminal, is an extremely telling method of finding out what users think of your application.
Most modern wireframing tools now have the ability to make these kinds of prototypes. Balsamiq (which I had mentioned earlier) provides you with the ability to do this with some basic linking. It will even generate “clickable” PDF files that you can email to unsuspecting guinea pigs for free testing. There are also a number of other great tools out there to make more interactive wireframes, like Generator and InVision – but these are a little more involved than you might need to get. Another great tool we use is Marvel. Marvel is an app that allows you to take photos of pen and paper sketches and then link areas of them together to make an interactive prototype.
Either way, getting your wireframe down and creating a working prototype might just be the next steps needed to bring your vision to life. Preparation is a key part of the development process, and an integral piece of the end-product. Tune in for more on How to Develop an App next week, or visit us on Twitter for dev tips and more!
