Before you dive into Photoshop, take a step back and ask yourself if you’re ready to invest a good chunk of time rounding all your corners at the same radius, making sure you’ve got active, hover, and down states on your buttons, or choosing the right color palette and typography. Have you thought about how users will interact with components? Are you missing steps in your checkout process?
When planning and scoping your site, app, menu, car dashboard, or whatever you may be designing, you should include wireframing into your workflow. If you need to click/tap on something to make an occurance happen, it’ll be a great deal of help to map everything out early, so you don’t pause during development and think “Shit, what happens if someone clicks on a permalink from a third-party? Do I send them to a version of the site teasing the content so they sign up? Or do I show them everything and hope the content is enticing enough to make them sign up?” Catch all of these use cases before you design and develop. You’ll probably overlook some scenarios, but better to miss a couple now than to miss a bunch later. Making sure you, and your team, understand the core product and every “nook and cranny” of the experience will not only benefit the overall development of your product, but you’ll have a hell of a lot less to worry about when working on the next push. Instead of adding and fixing a bunch of bugs/functionality that you could’ve easily avoided, you’ll only be working on a handful of bug fixes and focusing more on implementing new features.
Alright, it’s time to wireframe and the first thing you’ve got to decide is the fidelity of your wires. Wireframes should be simple enough to convey the overall architecture, but complex and informative enough so a visual designer or a software engineer can produce based off the exact same documentation. An analogy I’ve been referencing when explaining “information architecture” is comparing a wireframe to a blueprint (Wireframes:Product::Blueprints:House). Wires, with room for flexibility, will help aid and define placement, sizing, copy, images, and more. LoFi (Low Fidelity) wires can be as simple as sketches on paper and HiFi (High Fidelity) wires can get pretty close to a working product. There are plenty of tools you can use to effectively get your ideas across, so choose what might be appropriate for your audience: visual designers, engineers, business/marketing folk, etc…
Sketching (LoFi)
This is by far the quickest, dirtiest, and most accessible way to rapidly get your ideas down. Even if you plan on putting together some more detailed wires together digitally, doodling on paper is a great way to quickly realize your thoughts and concepts. Ideas can come at any time, and if you don’t have a computer in reach, you’ll have to rely on that excellent memory of yours for when you do get to your machine. Brainstorming in a group? Grab some paper, a notebook, or use a whiteboard if available. Sketches can go a long way. If a group from Pixar never got together during lunch and drew a bunch of characters and notes on napkins, we probably wouldn’t have “A Bug’s Life,” “Monsters, Inc.” “Finding Nemo,” and “Wall.E.”
When performing user testing, paper prototypes can be an effective way for simulating things that require quick modifications. Designing for mobile? Try POP to take photos of your sketches and create tappable prototypes right from your device.
Mockup Software (HiFi)
Apps like OmniGraffle, Axure, and Balsamiq allow you to create much more polished wireframes. The advantage to these programs lies both in rapid creation and the ability to generate shareable documentation.”Stencils” allow you to drag-and-drop commonly used components like buttons, dropdown menus, text boxes, image placeholders, all of which you can customize. Export as images or package everything together as a PDF. Axure and Balsamiq take it a bit further and allow you to create clickable prototypes. There are also dedicated online communities that share custom stencils and how-to tutorials.
Ready to test? Throw your images into Keynote or PowerPoint and simulate page transitioning by assigning hit areas and targeting them to the appropriate slides. I’ve been using Axure recently to generate clickable prototypes that are set up so I can share a single URL, either public or password protected, and get pretty close to a version of the product without having to code or use Photoshop. I can simulate transitions and animations, though not perfect, to a degree that an engineer can visually understand and develop.
Annotations
Sometimes you won’t be able to illustrate certain interactions in your wires so you’ll have to do your best to notate it as detailed and eloquently as you can and point it out explicitly on the layout. A rule I like following is that “if you can click or tap on something, annotate it.” Here’s an example: “Password is required when registering a new account. Set input field placeholder as “Password”. Clear the placeholder when field is active. If field is left blank or string entered does not meet password requirements, show error state 1A.” The goal is to word the note so your developer will easily understand what should happen when, in this case, the password field is interacted with.
Storyboards
If clickable prototypes aren’t an option, a simple way to illustrate user flows and interactions is to draw quick storyboards showing, step-by-step, each process in the flow. When producing a movie, storyboards are used to explain the story scene by scene, along with camera placement, panning techniques, and cuts. In the same way, a storyboard in your documentation helps lay out the required steps for a certain process. Like a comic strip, you can set up your storyboard using cells and highlight each step in each cell. Rather than clicking on a prototype to simulate the experience, you’ll be able to get a quick overview of how to get from point A to point B in a specific flow, like how a user shares a video, the onboarding process, or a payment checkout flow, all on a single page in your document.
Prototype
Consider this a luxury that is necessary to have if you have the resources and time to produce them. Prototypes can take on many forms (paper and digital), where the goal is to make them compelling enough to be able to draw feedback/conclusions based upon them. I’ve been lucky in the past to work alongside some engineers that can quickly crank out a working version of certain components or the entire UI in no time. The detail is definitely scaled down in that we’re using non-specified CSS, placeholder images and dummy text. They’re built so we can get a feel for certain interactions such as transitions/speed for a carousel, how dropdown menus should appear, whether buttons are large enough to tap on for mobile, and the like. It’s a quick indicator for us to see if we like it, if we should tweak it, and if we need to think about an alternative solution.
Click-through prototypes are especially beneficial to see the entire architecture of the product, and as an asset to test with real users. Invite a few friends/colleagues, or recruit test subjects that match your target audience, and let them play around with the prototype. See what they’re doing, take notes on their behavior, and survey them to get their reactions. It’s also useful to make a list of specific tasks to test so you can see firsthand if the user would understand what to do or be completely confused. For example, if you’re testing an eCommerce site, you might want to ask the user to search for a certain product, add it to the cart, and complete the checkout process (a core flow that is the revenue driver for your product, and probably the most important process flow you have). If they can’t complete the task, or stumbled along the way, find out what went wrong and make the appropriate corrections to your UI. You probably wouldn’t want launch your site and forget to implement a feature like allowing a user to ship an item to an address other than their billing address.
Do a little prep work before getting into hardcore production. There’s a chance that if you’ve skipped straight to visual design and then realized that the framework needs to be completely changed to accomodate for a critical component/use case you missed, you’ll wish you had taken the time earlier to hammer out those details.
