WIREFRAME WEDNESDAY Avatar

Notes

How To Develop an Effective Prototype

I’m a born planner. I take much more pleasure in creating a to do list than I do in actually completing the items I’ve painstakingly color-coded and arranged in order of importance. My downfall as a planner? I tend to get caught up in the small details before the bigger picture has been decided.

Every time we move, which has been a lot over the past two years, I immediately begin to envision the new space in my head as it would be in my dreams: repainted kitchen cabinets, warm colors and a collection of my favorite (yet to be purchased) framed prints in the place of stark, white walls, charming pieces of vintage furniture combined with some modern pieces to make my husband happy, a little orange teapot on the stove…yes, I envision the teapot. But before I’ve taken a step back to look at our new home- deciding what furniture will actually fit in the rooms and how it should be arranged to make the most of our space- or to look at my wish list- deciding whether it’s worth the time and effort to achieve each item and creating a timeline for doing so- I’m off buying prints, performing daily searches on craigslist for vintage furniture, and spearheading a never-ending online pursuit for the perfect orange teapot…it’s very elusive. After all, isn’t the horse supposed to walk behind the cart, nudging it along down the street with it’s snout?

Well I can tell you what that method has gotten me thus far: a stack of four vintage chairs in our attic waiting to be repainted and reupholstered, a kitchen sans cabinet doors (they’re keeping the chairs company) and at least four unframed prints lying around without a home. And I can tell you that using the same method certainly won’t lead to efficiency in web development projects either.

A much more effective method is our grayscreen prototyping process, established long before I crossed the Newfangled threshold as an employee (in fact, it has a good ten years on me). Consequently, there’s already a wealth of information on our website about why we prototype and how we prototype, so there’s not much to elaborate on there. However, within the process of the prototype lies nuances that can determine whether it’s destined for greatness- a well planned, effective website that meets the client’s expectations- or doomed to fail- a big ol’ mess.

The goal of our prototypes is to thoroughly represent the architecture of the planned site- specifically the structure, content, and functionality. After all, not only will the developer and designer be using the prototype as a guide for their work in later stages, but the prototype is used to determine the scope of the project in functional, interactive terms as well. As a general rule, when it comes to functionality, the more specific the better. If the client wants forms that expand when the title is clicked, this should be represented in the prototype. If they’re expecting a scroll feature that showcases their products, it needs to be represented in the prototype.

In one of our more complicated prototypes, clicking on a collection title resulted in the pop-up window shown above. With this prototype, it was important that the client be able to accurately see what the customer would experience as they navigated the site in order to make decisions about functionality. Of equal importance was specifying how those agreed upon pieces of functionality would work on the site so the developer and designer could do their jobs well.

To the extent that it is beneficial, we want the client to be able to click through the prototype and experience, as closely as possible, how the website will actually work once built. But, not only is it important for us to have this expectation ourselves, it’s of equal importance for us to communicate this expectation to our clients and make sure they have it as well. They need to understand that when it comes to the prototype, design aside, what you see is what you get. Once the prototype is approved, any additions threaten not only the development schedule but the budget as well. The last thing a client wants to hear is, “Well, we could have included that on the website, but it wasn’t specified in the prototype, so adding it means pushing back your important deadline” or worse “…it wasn’t specified in the prototype, so we’ll have to add it as an upgrade after go live at additional cost.” However, there are aspects of a prototype that we intentionally make less specific.

While our prototypes will certainly fully represent the structure, content, and functionality of a website, they will not speak to elements such as color, graphics, or typography. It is precisely because we want clients to focus on the former that our prototypes are intentionally design-agnostic. In fact, if you look at the prototype expecting to be blown away by design, you’ll probably be a little underwhelmed to say the least. I like gray as much as the next person, maybe more, but I wouldn’t consider shades of gray to be a very exciting palette for a website. But the shades of gray allow us to draw the attention of our clients to the elements that matter during this phase - and keep their attention from those that don’t. We use the same basic font across the board- only occasionally adjusting the size and weight to represent how items will relate to one another on the page when appropriate- shades of gray as the color palette as referenced earlier, and dummy text wherever allowable. Introducing stylized fonts or color at this phase may cause the client to get attached to certain aspects of how the prototype looks instead of focusing on how it works. Furthermore, being too specific with some of these elements can even be problematic when it comes to actually building the site.

I mentioned that we use dummy text wherever allowable, a sign to the developer that the client should ultimately have control over the actual content. Straying from this convention and entering specific text on prototype pages, such as actual page titles in lieu of something more generic like “Product Detail Page,” may send the wrong message to the developer. Does the client want the titles to be hardcoded? Is this page different than a standard product page in some way? While these specific questions can be answered by a simple phone call, this may not always be the case. Regardless, the prototype is a means of communication between all involved parties- the client, the project manager, the developer, and the designer- so shouldn’t we be trying to use it to enhance that conversation and not introduce more confusion?

Even a small detail like using more detailed page titles instead of generic ones can cause confusion. As a general rule, if there isn’t a good reason for being specific with elements of the prototype, keep it generic.

It’s important to note that there aren’t necessarily hard and fast rules when it comes to developing a prototype. The way you choose to handle certain elements may be determined by the client rather than any set of rules as to when or when not to be specific. For instance, in our prototypes, areas designated as open content areas have a great deal of flexibility with regards to the formatting that’s possible through our NewfangledCMS; images and files can be uploaded and bullet lists and hyperlinks can be created. Typically, we would write a small amount of “lorem ipsum” text with a note to the developer that a certain area is open content. However, some clients may get derailed by the length of text in these areas or the absence of bulleted lists if their content calls for them. In this case, it may be better to include some bulleted lists in the prototype so that the client is able to focus on more pertinent aspects of the prototype while keeping the note to the developer to prevent confusion.

"It’s all about showing a client how things will work", claims Lauren Walstrum in her article and raises the overall question: How specific should a prototype be?

Notes

How we are going to redesign HotGloo (Part3) | HotGloo Blog

A few weeks ago we started our mini series on our redesign process for HotGloo 3.0. Last post was all about the research phase (Part2), followed by developing a strategy and coming up with a site structure laid out in a site map. Part3 is now all about wireframing.

Step6: The Wireframe Process

After breaking down the structure for the whole website in a site map we started to wireframe the new site. We agreed on splitting the process into two big chunks: the actual website and the account panel. Two complete different yet overlapping parts of HotGloo 3.0.

Marketing Site

The marketing site is the actual website communicating the application. Since we asked ourselves questions a visitor could ask of the website beforehand and clustered them into different interest areas, we had quite a vague picture of the page structure in our head. It was really important for us to introduce the editor in a very prominent way on the new landing page. The first time visitor should be able to understand what we are offering and how the offer looks like within a couple of seconds. He should also be able to get in touch really easy and find all the relevant informations clustered in areas.

The whole structure for the new site was divided by different interest areas. I’ve illustrated this step by highlighting the different interest areas we are using on the new landing page:

  • Navigation
  • Experience
  • Call to Action
  • Information
  • Opinion



Account Panel

The account panel was a big challenge. We wanted to improve the over all user experience by developing a completely new panel, providing a better overview and an easy way to sort and group projects and people. We came up with the idea of designing a “Dashboard” including the “Activity Radar”. The activity radar is displaying all project relevant informations in a hierarchical order starting with the latest activity. We have different informations packed into the activity radar such as: Who opened a project and when did they open it? Who created the project and when? Who sent a note? When did they send it? What did they send? The ability to access a certain note with one click and much more.

Since account panels always differ regarding the current user state, we designed the whole account panel in an interactive approach. We laid out different user states for Owners, Reviewers, Editors – giving us the ability to testdrive the whole functionality of the new account panel, plus it helped us a lot to keep an overview of error and help messages, we needed to add and also to iterate on various account functions, like changing the account url, user information, up/downgrade functions etc.

Finally we exported the whole project to pdf and did a manual walkthrough to find out if we were missing some really important informations.

The benefits we experienced from wireframing the complete website upfront were:

  • Getting a feeling of how the new site is going to behave.
  • Working in teams and delivering feedback whilst the project is evolving helps to define things upfront where they can be changed quickly.
  • Working on the copy upfront and experience how it behaves and how it differs depending on where you actually put it on the site.
  • The wireframe can be used during the whole project workflow and function as a reference model when you need to explore something in detail or need to sign off something.
  • Iterations during the concept phase saves a lot of time and money, because you can quickly update the wireframe and don’t need to change the code nor wreck up the design.
  • Communicating clear and precise specifications to the designers.
  • Helpful for the coding process afterwards because the user states were already defined, error messages and help messages in place plus the note function works like a charm if there are still questions about certain pages. You will exactly know what the person on the other end is referring to and can respond very easy.

Blogpost I released today over at the HotGloo Blog. Illustrates the wireframing workflow we’ve gone through when redesigning our app.

Notes

5 Steps to Building a Successful Site Architecture | ClickZ

I have come across many website development projects that seem to focus too much on the visual aspects of their website before they put any thought into the structure and information flow. By just inserting information design, sometimes called information architecture at the beginning of your process, you can dramatically change your website’s performance. The benefits of a successful site architecture will not only increase visitor engagement but it will help you attract more of the right visitors. This process will also lead to higher conversions.

Step 1 - Identify Keywords

This first step of identifying high-performing keywords is essential if you wish to drive the right traffic to your site. Take the time to perform a thorough keyword research study from the beginning. It’s a given that you will be using branded keywords on your site, but more importantly look for keywords that your target audience might use to find you. Use a couple of keyword research tools like Keyword Discovery, WordStream, or Wordtracker, along with the Google Keyword Tool to help you gather data on each keyword. Some things to look for and determine are:

Relevancy. How relevant are the keywords to your business and do you have (or will have) relevant content on your site for that keyword?

Specific or long-tail keywords. Very specific search phrases will attract people who are toward the end of their buying cycle and who are ready to convert. For instance, if someone uses the search query “laser printer,” that would suggest they are beginning their research process and haven’t decided on one yet. On the other hand, if they search using the term “HP Laserjet PRO P1102,” that would suggest they know what they want and are ready to buy.

Competition. Find out how competitive the keywords are. Highly competitive keywords will be harder to rank for and may cost more to use.

Search volume. Keywords that have a high search volume represent a popular search term that many people are likely to use. Compare similar terms and see which is the most popular.

As you go through a keyword research study, you will learn more about potential visitors, what they might be looking for, and their wants and needs.

Step 2 - Map the Keyword Space

Categories will emerge from the keyword research, identifying different subsets of your products or services, or information that your potential customers would find useful. Those keyword groupings or categories will help you in identifying relevant pages of content you will want to build into your structure.

As you map the keywords you plan to use to relevant landing pages, you create a fluid connection to content that your visitors are likely to be looking for. It also helps you to perform a kind of gap analysis to identify subpages you might have missed.

Step 3 - Develop Your Site Architecture

The next step is to build out the architecture of your site. Most people refer to this as building a site map. A site map is basically a hierarchical representation of your site and all of its levels and pages. As you mapped your keywords into logical categories, you have already started this process. Continue to build out the rest of the site structure and make sure you include all of the information your target audience and each persona may be searching for.

Richard Baxter presents some very interesting arguments about how deep your site map should go. He makes a case that a flatter site architecture will be best for usability since it will take less clicks to get to the deepest level. A very good tip to consider as you build out the structure of your site.

Step 4 - Wireframe Prototyping

Now that you have a solid structure that outlines your site’s content that is mapped to relevant keywords, you should start to develop your wireframe for each page. A wireframe is a simple representation of the content and navigation for a page on your site. It is not a sitemap. It takes each page on the sitemap and blocks out the placement of content and navigation as seen below.

If you wish to take this a step further, then you can convert your wireframe into a “clickable prototype,” which is a website that incorporates the wireframe with clickable navigation and links to get a feel for how the website will behave and operate.

This is a good best practice, especially for large sites to work out the information flow and usability issues. You can even conduct user testing with a clickable prototype to learn where the problem areas might be before you start programming and coding the site. There are many tools to help you with this process. One that I have used is ProtoShare. It allows you to develop a sitemap, wireframe, and clickable prototype in the cloud and allow your team to work on these elements in an online collaborative environment.

Step 5 - Content Development

The final step is to build into the wireframe the actual content for each page. To bring this full circle, you should make sure the content uses the keywords that you have mapped for each page. Use the keywords in the body copy, text links, video and image tags, etc. This is all a part of SEO best practices. But, more importantly, it bridges the searcher expectation to relevant content on your site. So when your visitors arrive they will feel they have landed at the right place. As a result, you will find that you have more engaged visitors that will be more likely to convert.

Once this process is done, you should plan to add a visual skin to the site that is in harmony with your logo and other branding elements. A mistake many people make is to begin their process with the visual elements first as they design their home page. It is best to look at your site holistically and work out the information flow ahead of time.

I have used this simple process over the past 12 years with a tremendous amount of success. It will help you get into the minds of your audience and anticipate their needs. When they finally land on your site, they will feel right at home since you have taken the time to lay out the information just for them. They will reward you with higher conversions, lower bounce rates, and undoubtedly word-of-mouth praise through social media channels. A win-win for all involved.

Excellent article by Ron Jones who is illustrating his “practice proved” five step process to a successful site architecture.

Notes

How Collaboration Improves Information Architecture » Usability » Design Festival

Sometimes it’s easier to do everything yourself instead of collaborating, isn’t it? If you’re an information architect, there are some compelling reasons to call all the shots:

  • The project starts with you, so you get to make all the initial decisions yourself. No one else on the project has that liberty.
  • You have firm start and end dates, after which you can move on to other work. Think of all the projects you could get through!
  • Everyone is looking to you as the specialist, which means you should be able to come up with the right answers and not involve others. Plus, you save your co-​​workers time by not involving them in all the initial project meetings.

But wait, isn’t this sounding a little too good to be true? Or maybe you’re thinking it seems pretty risky! You’d be right in either case.

The fallout from making IA decisions in a vacuum can be further reaching than you might suspect. The truth is that collaboration, solicited or not, is bound to happen once your work is sent to design. Quality designers won’t just regurgitate your wireframes, they’ll interpret them; furthermore, in the process of explaining your wireframes to the designer you’ll no doubt come up with new ideas or improvements.

Now you’re in a tricky situation, because changing an approved wireframe increases scope creep, and moving forward with the already approved wireframes would lead to what you now realize is a subpar solution. It will be a stressful moment for the whole team, but not as stressful as it happening during development.

That’s just one example of a whole host of issues that can crop up later in a project when there’s tunnel vision early on. Let’s look at some ways to prevent this and ensure you have great products.

Share Discovery Information

After the first few stakeholder and customer interviews, take the time to run some thoughts by your team. Their questions will help you identify holes in your own understanding, and shape your ongoing research. Different members can be involved at different levels, but everyone from the content strategist to the developer needs to understand the whys behind the project before they start their work.

Talk It Through

Contact a few colleagues who are either on your project or in your field, and meet with them as you work through interface and experience decisions. Remember: your job is not to have all the answers, but to ask the right questions. The answers to those questions lead you to the right solutions. As you explain a crippling problem to a colleague, you might just have an “Aha!” moment that gets you past your block.

Practice Makes Perfect

Consider making your big reveal before you actually make your big reveal. Practicing for your stuffed animals is handy, but presenting to your team is even better. Concepts or explanations that sound great in your head may be less eloquent coming out of your mouth. If you thought through the big picture and philosophy that has driven your decisions, your presentation will be compelling and make sense. If you are unprepared or your decisions are haphazard, you’ll end up dragging your client and team through a mire of tedious details until their eyes cross. You might even resort to convoluted industry lingo! If you’ve collaborated all along, by the time your actual presentation comes around any member of your team should be able to give it (but you still need to!).

All these generous people lend you their time and brain power, so make sure you return the favor. The client will sense the consistency and unity of your team, and their testimonial will show it.

Nice read by Emily Smith, who speaks up for collaboration in order to improve IA decisions.

Notes

How Collaboration Improves Information Architecture » Usability » Design Festival

Sometimes it’s easier to do everything yourself instead of collaborating, isn’t it? If you’re an information architect, there are some compelling reasons to call all the shots:

  • The project starts with you, so you get to make all the initial decisions yourself. No one else on the project has that liberty.
  • You have firm start and end dates, after which you can move on to other work. Think of all the projects you could get through!
  • Everyone is looking to you as the specialist, which means you should be able to come up with the right answers and not involve others. Plus, you save your co-​​workers time by not involving them in all the initial project meetings.

But wait, isn’t this sounding a little too good to be true? Or maybe you’re thinking it seems pretty risky! You’d be right in either case.

The fallout from making IA decisions in a vacuum can be further reaching than you might suspect. The truth is that collaboration, solicited or not, is bound to happen once your work is sent to design. Quality designers won’t just regurgitate your wireframes, they’ll interpret them; furthermore, in the process of explaining your wireframes to the designer you’ll no doubt come up with new ideas or improvements.

Now you’re in a tricky situation, because changing an approved wireframe increases scope creep, and moving forward with the already approved wireframes would lead to what you now realize is a subpar solution. It will be a stressful moment for the whole team, but not as stressful as it happening during development.

That’s just one example of a whole host of issues that can crop up later in a project when there’s tunnel vision early on. Let’s look at some ways to prevent this and ensure you have great products.

Share Discovery Information

After the first few stakeholder and customer interviews, take the time to run some thoughts by your team. Their questions will help you identify holes in your own understanding, and shape your ongoing research. Different members can be involved at different levels, but everyone from the content strategist to the developer needs to understand the whys behind the project before they start their work.

Talk It Through

Contact a few colleagues who are either on your project or in your field, and meet with them as you work through interface and experience decisions. Remember: your job is not to have all the answers, but to ask the right questions. The answers to those questions lead you to the right solutions. As you explain a crippling problem to a colleague, you might just have an “Aha!” moment that gets you past your block.

Practice Makes Perfect

Consider making your big reveal before you actually make your big reveal. Practicing for your stuffed animals is handy, but presenting to your team is even better. Concepts or explanations that sound great in your head may be less eloquent coming out of your mouth. If you thought through the big picture and philosophy that has driven your decisions, your presentation will be compelling and make sense. If you are unprepared or your decisions are haphazard, you’ll end up dragging your client and team through a mire of tedious details until their eyes cross. You might even resort to convoluted industry lingo! If you’ve collaborated all along, by the time your actual presentation comes around any member of your team should be able to give it (but you still need to!).

All these generous people lend you their time and brain power, so make sure you return the favor. The client will sense the consistency and unity of your team, and their testimonial will show it.

Nice read by Emily Smith, who speaks up for collaboration in order to improve IA decisions.

Notes

3 Obstacles when Presenting Wireframes » UX, Usability » Design Festival

Aside from laying the groundwork for design, wireframes open up dialogue, establish project direction, refine scope, and create a satisfying sense that progress is being made. They won’t do any of these things well without the right preparation, though. Here are some obstacles to keep an eye out for when you’re getting ready for your next presentation:
  • The Problem of Abstraction

    Some people are abstraction geniuses, but for the rest of us it’s mental gymnastics. For example, I used to work with a product designer who made high end tools that looked like they came from outer space.

    During his paper sketching phases, it would be impossible for me to get a feel for the final product. The 3-​​d renderings were easier to digest, but nothing compared to holding the final product. It was always interesting to see where I was off on my assumptions about how the tool would work, feel, weigh, and look.

    One of his renderings vs. the final product, used with permission
  • Similarly, as soon as any type of mockup or sketch of your web site is presented, each person who sees it begins constructing a different vision in their head of how the final product should look and feel. Assumptions and heuristics allow us all to function with efficiency in life. You, your clients, and team members are all employing these mental tools during the project. This is perfectly reasonable behavior, but it creates risk for unmet expectations. We have the ability to lessen this burden, though, and I’m going to flesh out specific ways to do this in my upcoming posts.

  • The Power of Suggestion

    • A means of persuasion. Your wireframes and the way you present them are a powerful tool of influence that steers the whole project. If your solution is slightly under-​​baked but you’re a great salesperson, you may be able to push through to approval (possibly against the best interests of the project). On the other hand, you might have a great solution but be unskilled at selling it with confidence and enthusiasm and so it isn’t as well received. Thankfully, we have a way to help minimize this problem.
    • Information as an antidote. The least stressful documents to make and present are based on careful and thorough information-​​gathering. This won’t be statistically significant but it will lead to insights that can be shared with everyone and will take the conversation beyond personal opinion. That way, even when you are highly trusted by your clients (and most persuasive), they will be equipped to ask critical questions. If wireframe meetings are characterized by agreement without discussion, or conversely if you feel like you’re working too hard to sell them, then problems are likely to pop up down the road.

  • The Difficulty with Feedback

    Clients get a bad rap for offering unhelpful or heavy-​​handed feedback. While that’s true in some cases, I’ve found it’s often a lack of guidance and leadership from us that leaves clients scrambling to offer useful critique. Each client personality and skill set is unique but here are some general purpose questions to help guide feedback next time you are getting ready to present wireframes:

    • Does your client/​team know why you’re having this meeting? Starting a meeting out with this simple recap does wonders.
    • Have you explained what a wireframe is to this client before?
    • Do they know what a wireframe is not meant to be? Are they expecting to see visual design? If you’re not sure, it’s helpful to show them a past example of a wireframe next to a screenshot of the final product.
    • Have you given them specific examples of what kind of feedback is appropriate and what isn’t? e.g. “The XYZ program is gaining importance and should probably have more emphasis” focuses on the goals of the site and is appropriate. “Can we make the XYZ tab bold and purple so it stands out more?” focuses on the mechanics of the visual design and is not appropriate.
    • Have you explained to them what role their feedback will play?

  • via designfestival.com

    In this article Emily Smith raises a couple of interesting questions you should ask yourself before presenting wireframes to clients.

    Notes

    Wireframes – Worth Their Weight In Gold | Viget Inspire

    I will never start from scratch in Photoshop again. Seriously.*


    Stacks of Wireframes

    (*Okay, maybe that’s hyperbole, but I bet I’ll do it less frequently).

    Like a lot of folks, my standard web design workflow started by opening a new file in Photoshop (or your design program of choice) and getting a basic guide structure put into place. I generally started by designing the header region of the site because of its obvious importance in laying the groundwork for the visual direction. I then would fill in the primary navigation items and start resolving details like the feature area and the rest of the homepage content. By the time I had hit the footer I was ready to at least start thinking about how I was going to build out the page.

    All that’s changed now.

    Before interning at Viget, I had no idea what benefit could come from wireframing a site (nor any real clue what UX designers actually do). I think this sentiment is shared by lots of people and is the topic of many debates. Are wireframes really worth the time and effort? Why?

    Absolutely - as long as you’re doing it “right.”

    For me, the biggest shift was understanding the actual goal of wireframing. In reality, I needed to be thinking in terms of content. I thought a wireframe was simply a dumbed-down version of a comp, filled with boxes, X’s, and lorem ipsum copy. That’s because I was thinking about it from a visual designer’s perspective. I was already thinking in pixels, styled horizontal rules, and type choices.

    The Problem With NOT Wireframing

    Like many other young, inexperienced, or otherwise unenlightened designers I ended up letting my visual design solution try to inform the content on the site. (e.g. “This heading looks best when there are only 24 characters - can we change the copy to accommodate?”; “We need to keep blog titles to one line only.”; or “Can we come up with a third section of copy on the About section so this 3-column layout will work?”) As a visual designer, it took me some time to realize that while my design would be the first thing that people notice, it’s NOT the reason that users are visiting the site. I needed to find more respect for the content I was designing for - not the other way around.

    Another problem I found myself struggling with was “forgetting” a piece of necessary information and (because I was so committed to my design) making compromises in its implementation or inclusion. Yet another instance of design informing content.

    So What?

    Like any other approach or workflow there is a continuum of what makes sense to include in any given project. Not every site will need a detailed content inventory, site map, or dedicated taxonomy system for tagging and classifying data (but big projects probably will). Likewise, not every project will need every page comped as a unique PSD file. But, by putting even a cursory effort into wireframing and UX considerations, I believe that I will save time in the long run.

    Wearing Different Hats

    I now try to compartmentalize my process in such a way that I spend some time thinking about what content needs to be represented across the whole site, what content will be represented on each page, and what the relative hierarchy of that information is on a page-by-page basis. This can be done quickly on a whiteboard and translated into detailed sketches or refined interactive models in Omnigraffle - or not. It all depends what deliverables you’d like (or need) to create and how much time you’d like to spend.

    My Happy Place

    I like to have detailed sketches to design from. Starting on a whiteboard and translating onto paper makes me feel empowered when it’s time to put on my “visual designer hat” and start working with pixels to create the actual design. I feel like a chunk of my brain that would normally be multitasking is allowed to focus solely on being creative. For me, that’s a great feeling.

    Give it a Try

    I’m sure people will always continue to be varied in their feelings about or approaches to wireframing. But, if you fall into the same camp that I did and never thought about splitting your process - give it a try. You too may end up changing your tune.

    Call to action article by wireframes evangelist Ethan Geyer on why he finally started to wireframe.

    Notes

    Wireframing for web apps | The Contrast Blog

    blog0

    The goal of preparing wireframes is to solve design challenges regarding layout, and priority. This is usually done in wireframes through experimenting with layouts and the application of contrast, similarity and some other principles.

    By applying the Gestalt principles to your components, you can quickly prepare concepts. The whole point of working at this fidelity is the speed at which you can explore ideas with a reasonable degree of precision. Over the years I’ve learned some useful ways to keep things fast, useful and timely. I’m loathe to write a “7 top tips for wireframing” but when working with less experienced designers I find the following themes occur frequently.

    Everything means something

    Every colour, every line, every shadow, every gradient. If your atomic unit of wireframes is a rectangle, with solid lines, a colored background and a drop shadow you’re communicating a lot, whether you intended to or not. These artefacts can be carried through to design, without anyone ever thinking why they make senes. Everything has to mean something.

    Consistency

    One nice thing about sketching, is that it defaults to same colour and font everywhere (i.e. you have to swap markers or change your handwriting for a difference). A frequent issue I see with wireframes is numerous different shades of a colour, or line weights, or font faces, all included without thought. This makes the wireframe more confusing to understand, as I wonder “Did he deliberately change font here? Is that label bigger because it’s more important?” etc. To avoid this, I encourage students to use a limited color set (3-5 grays), 2 fonts, default HTML components, and little else. This might result in “dull” wireframes, but bear in mind all wireframes end up in the trash anyway. They’re not what counts, you’re not delivering a PDF for visitors to “ooh” and “aah” at, you’re desigining software for them to use. A sexy wireframe is a waste of everyones time in the project.

    A second point worth noting here is where you lay your baseline. Starting with black text, means you can only get bigger and bolder, resulting in a Deep Purple style wireframe with everything louder than everything else. Starting with gray text, allows you to go darker and lighter. As Ryan Singer said, in a moment of Linguistic Relativity, HTML doesn’t offer a tag, but maybe it needs one.

    Speed and exploration

    The purpose of low fidelity design, is not to polish and refine, but to explore the solution space. Initially it often appears there are many solutions to a design challenge. Only by exploring a few of them, and laying them out in front of you can you decide which will work best. Cennyd Bowles describes how chess players face a similar challenge. Early in the game there are a lot of choices. Some you can rule out by instinct or experience. The remainder you mentally explore to see how they play. Naïve designers will fall in love with their first idea and cling to it for dear life. Andy Rutledge describes this phenomena an Lord Of the Rings inspired essay title My Precious
    If you can’t produce concepts quickly, then you’re working at the wrong fidelity. If your wire-framing serves only to deliver a grayscale version of what you’ve already decided you’re building then you’re wasting everyones time.

    Real copy, Real data

    The biggest mistakes I’ve seen made in projects (including my own) comes from the designers not seeing real content up front. If you’re including a photo gallery, you have to see the photos before you can decide whether to include it, make it a primary feature or fight against it. Similarly If you’re designing a data driven dashboard, you need to know the data looks like. Dummy data leads you into a world where headings never wrap, text can justify without looking absurd, photo dimensions and orientations are always convenient, and numbers always fit in their little boxes. The path to UI hell is sign posted “Lorem Ipsum”.

    Know your technology

    blog5

    A great design can be a terrible solution. If your design includes custom HTML components, novelty size buttons and dropdowns and ajax powered live search, it’s worth remembering that every project has a budget. If you know HTML/CSS/JS, which you should, and you’ve seen what it takes to test a page on IE6/7/8/9 Safari, Chrome and Firefox, you’ll think twice about what wizardry you’ll put in your wireframes. It might just a little component, and it might even be already available in jQuery UI, but remember, there are no small changes. I’m not saying that you should never include advanced interactions in wireframes, I’m saying you need to know the cost of what you’re doing. For Hipmunk it’s worth investing weeks, even months of work into the best possible calendar picker, as it’s the guts of the interaction. In that case the trade-off is worth it. It’s when I see a fancy date picker for date of birth, or a very precise Javascript powered time picker that I think the designer should first talk to the developer.

    Whatever works

    blog6

    An obvious point here, but the goal is great delivery not great deliverables. No one marvels at great deliverables except other UX designers, and even then they’re only interested when the end result was solid. If you’ve sketched something on a whiteboard that you’re confident is a good feasible solution, that has real data in it and everyone in the project knows what precisely what you mean then there is zero value in re-creating your whiteboard as a wireframe. Don’t be a slave to deliverables.

    These are lessons learned both through trial and error, and from lecturing on the subject and seeing materials students present. If you have others, I’d be happy to hear them. In the meantime here’s some good reading in the area, thanks for reading.

    • Gestalt Principles – Andy Rutledge wrote a great series on the basics of design. 1, 2, 3, 4, and 5.
    • Good design fasterLeah Buley has had this as her mantra for years now. Here’s a slidedeck and a podcast where she explains it.
    • Sketching User ExperiencesBill Buxton wrote an excellent book a couple of years ago, that covers some of the topics here. It’s a great read, and not just for designers.

    Follow @destraynor and @contrast on Twitter, Join the discussion on Hacker News.

    Interesting article from Des Traynor of Contrast on the wireframing process with web apps. The Contrast crew did also give a great talk at Future of Web Apps in Dublin last year, when I attended, so make sure to check out there work.

    Notes

    The Niehaus Wireframe Technique » Closed Loop Marketing Blog

    When developing website projects there is often a disconnect between the target audience’s needs and priorities, the hypotheses to be deduced from them, actual implementation, and the crucial question of whether it is possible to specifically plan ahead for conversion, or merely improve it later. The Niehaus wireframe concept presented here provides a possible answer to these disparities.

    [Note: this is a translated guest post written by Matthias Henrici, a usability expert and senior consultant for Web Arts AG. See the original German-language version here >]

    In May, 2010 at the Conversion Conference in San Jose, California, designer Sandra Niehaus (co-author of the book “Web Design for ROI”) presented an exciting wireframe concept that has since been used successfully by various conversion optimization practitioners in the course of website relaunch or design. In honor of the inventor, this type of wireframing has been termed a “Niehaus wireframe” by many CRO specialists.

    In her presentation, Niehaus pointed out that although normal wireframes are useful for the purpose of orientating the organization systems of a website and for communicating the basic principles and structure of the content, they nevertheless have tremendous weak points. The weak points are: focus, relevance and conversion optimization. Sandra suggested that wireframes be given a conversion strategy component beyond that of mere structure.

    This conversion strategy component can be divided into:

    • Target audience relevance (Pareto principle)
    • Object relevance (perceptual psychology)
    • Organization of content and structure

    Specifically regarding object relevance, Niehaus proposed grading page elements in order of importance and then assigning specific shades of gray to each. The most important element would be given the darkest shade of gray and all the others correspondingly lighter shades. According to Niehaus the result would then be a wireframe consisting of various gray areas that could be better structured according to their relevance in the run-up to a website relaunch or design.

    The special quality of a Niehaus wireframe becomes particularly apparent if one sets certain rules, such as restricting the use of calls-to-action to a maximum of two. At this moment one is acting not only as a designer and concept creator, but above all as a strategist compelled to think more about target audience clustering, the quality of representation, and product variety; one is forced to be relevant.

    A minor weakness of the Niehaus wireframe, namely that it does not really deal specifically with future content, forces you as a result to fill the gaps with additional wireframing. Logically, it makes sense to look more closely at the target audiences before creating the Niehaus wireframe because relevance basically depends on what customers expect and focus on.

    As a result the proposal was made to create the wireframing in three stages as a matter of principle:

    Übersicht

    Stage 1: Create a Pareto wireframe (target audience)

    Stage 2: Create a Niehaus wireframe (relevance)

    Stage 3: Combine into a final storyboard wireframe

    1) Pareto wireframe

    The Pareto principle (also known as the 80/20 rule) describes the principle whereby the application of 20% of all possible solutions is sufficient to achieve 80% of the potential.

    What does that mean in terms of wireframes? The idea is based on the use of existing target audience definitions, which are taken from prior studies such as Sinus milieus, forecasts, or even exploratory typologies in order to roughly formulate and describe in smaller “working” units the basic elements, tools, user aids, navigation, and content requirements for each system template.

    Personas

    Figure 1: Exploratory personas

    Without any priority weighting, this could become hundreds of elements or objects; they need to be prioritized according to the Pareto principle. In order to achieve prioritization, in the second step the various target audiences are assigned value creation potentials (Figure 2) and in the third step all the personas are allocated the corresponding relevance values (Figure 3).

    Wertschoepfung
    Figure 2: Value creation


    pareto
    Figure 3: Pareto wireframe

    Here is an example: you should not clutter up 100% of the area of a start page with tools, objects and elements; or, if you have 100 arbitrary elements, they should not each be assigned exactly 1% of the space on the page. It is firstly necessary to introduce a kind of “5% hurdle” to obtain a place in the “tool parliament”.

    So, if the various personas are assigned relevance values, they then pass on this relevance to the various tools and thus the prioritization of the tools changes. There are, of course, mandatory elements which must be included irrespective of relevance value, such as the link to the imprint or certain SEO elements, without which the page could not function. SEO tools are not, however, necessarily relevant for the user.

    Already at this point, the result removes unnecessary tools that are not relevant for the core target audience. This can mean, for example, that the social media plug-in or ad banner much loved by the Marketing department could be banished if it turns out that only a small percentage of the target audiences actually uses them. In the marketplace of attention, there is not sufficient space to carry out every experiment.

    2) Niehaus wireframes

    The Niehaus wireframes are initially intended to focus the attention of the designer on the essential elements. Without this ingenious system, unimportant elements quickly mutate into important ones and things that should not be above the fold shoot out of the ground like mushrooms. As Tim Ash so aptly said: “Your website is a growing field, and sooner or later it’s overgrown!”

    Ideally, it is good to use four levels of gray in Niehaus wireframes. Each level denotes a different attention value that is “triggered” in the user:

    • Light gray: All must-have elements such as the logo, meta-navigation, possibly some important content and the main navigation
    • Mid-gray: Tertiary focus. These can include main navigation, contact info, input fields, trust signals, etc.
    • Dark gray: These areas represent the secondary focus. This grayscale is assigned to all elements that are either meant to lead to the primary focus or that provide another important contribution justifying this attention value
    • Black: Primary focus. The direct CTA (call-to-action)

    Legende
    Figure 4: Legend

    With each gray level the quantity, size, or space assigned to the elements declines, for example:  60% of the page becomes light gray, 30% becomes mid-gray, 8% dark gray, 2% black. But be careful! This depends entirely on the previous target audience analyses and the page type. In the case of a landing page, for example (see figure 5) the ratio may be different. It must also be decided whether an element should be positioned above or below the fold.

    The really exciting thing about the Niehaus wireframe is that it could facilitate an early eye tracking simulation. Figure 4 shows that in an eye-tracking test all the elements are indeed focused on according to their importance.


    niehaus_wireframe

    Figure 5: Niehaus wireframe, taking a Frontlineshop.de landing page as an example. The product image is assigned a significantly larger secondary focus.

    Storyboard wireframe

    The storyboard wireframe is actually the “classic” wireframe. It already represents a detailed and carefully executed prototype of the actual website. Here the strategic part of the previous findings is tested with real content and enriched with details.

    boxfresh

    Figure 6: An example of a classic wireframe. Of course there is an abundance of other possible alternatives here, but we cannot demonstrate them all at this point.

    When executed professionally, conceptual weaknesses are again eliminated at this point:

    • Translation issues, for example the typically much longer word structure of the French language can be tested; of course this also applies to all languages with non-Latin letters
    • Content which is non-existent or overpowering can be expanded or reduced
    • Rare system or user dialogs such as B2B partner forms can be worked over and optimized for the last time

    boxfreshfinal

    Figure 7: Final version

    Conclusion: The wireframe concept presented here fills the gap between target audience requirements and prioritization, the hypotheses to be deduced from them, and actual implementation. The Niehaus wireframe helps designers keep track of the user focus and not get carried away by the variety of tools and alternatives. The wireframe concept is ideal for new conceptions, independent landing pages and relaunches.


    by Sandra Niehaus

    Post by Sandra Niehaus. Get to know the Niehaus wireframe technique which seems to be quite handy for new conceptions, independent landing pages and relaunches.

    Notes

    Wireframe Is Worth A Thousand Spreadsheets Wireframing 101 | Articles | Meta Q

    What is a wireframe?

    A wireframe is a diagram of the content, arrangement and hierarchy of elements of a web page or set of pages on a website. Wireframes are typically created in grayscale or with minimal color. They are kept free of design elements (no color palettes, no fancy borders or line styles, no shadows or other design treats.) A set of wireframes will demonstrate how users navigate a website and the flow users take to accomplish key tasks such as downloading a product, or creating a new account.

    Why wireframes?

    • Focus on Structure. Wireframes focus on website structure without the distraction of how the web page design looks. Because wireframes are created with little to no color, with very simple font choices, and a basic design style, it’s much easier to focus on the contents and arrangement of the page.
    • Visualize Ideas. Wireframes help stakeholders see the reality of their ideas. It’s difficult to imagine an idea without seeing how it looks and acts on screen.
    • Define Project Scope. Wireframes are essential for defining a project’s scope - and are often used as part of the project spec. They bring the web team and the client team in sync on what’s being built.
    • Clarify Hierarchy. Wireframes help the design team and client team focus on the hierarchy of items on a page. Should the “call to action” to sign up for the newsletter be more prominent? Is the balance of photo size to copy size correct?
    • Identify Content Needs. Wireframes identify the content a website will need for completion. They’re a great resource for the content team to use when gathering content. It will help them know what sizes (3 paragraphs) and styles (list format, or subheadings) are needed.
    • Refine Content. Wireframes also make it easy to see what content is missing or extraneous on a web page.
    • Promote Discussion. Wireframes promote discussion of design and functional features. Because they’re sketched out and unfinished, it’s easier for clients to visualize changes, adjustments and improvements without being worried about drawing on top of a beautiful web design.
    • Reduce Problems Early. Wireframes reveal design pitfalls that are hard to imagine before creating the actual layout and structure of a site. For example, initial design concepts might not reveal the challenge of requiring three clicks to get to an important piece of content. However, when paging through a wireframe, excessive clicking will become a much more apparent issue, and can quickly be addressed.
    • Keep Process Enjoyable. Wireframes are also just more fun to work with than a spreadsheet of fields that will go into a database.

    Who benefits from the wireframing process?

    Everyone involved in creating a web site benefits from wireframes: designers, developers and clients. Designers use them to create and understand patterns and visual hierarchy when they’re creating their web design compositions. Developers use them to inform the specs of what they’re building. Clients use them as a tool to make sure their website goals are addressed. Wireframes are a great way to help everyone understand the project goals and to build a comprehensive project plan.

    What should clients look for in wireframes?

    • What content is missing? What content doesn’t need to be on the page?
    • Are the most important features clearly visible and easy to spot on the page? (Tip: On first glance of a page, what is the first thing you see?)
    • Do you know what you can do on specific pages?
    • Do you know where you are on the site? Can you figure out how to get to another page of your choice?
    • Is it clear how to do your key actions (such as contact the company, or download a product manual)?

    What should designers look for in wireframes?

    • Do the wireframes capture the appropriate visual hierarchy of each page?
    • What methods are used to identify where a user is on page/site?
    • Is the navigation consistent from page to page?
    • Are common features in appropriate locations (search box, contact button, etc.)?
    • Do the wireframes have consistent visual patterns? (For example: from page to page, are lists of content similar in structure with heading, description and link?)

    What should developers look for in wireframes?

    • Should anything be clarified? Can you build the site from these diagrams?
    • Can you suggest anything to make the structure simpler? (For example: Can the same structure of content fields be used for different content types?)
    • Is there enough specificity? Are the number of items in lists or characters in an excerpt identified?

    What projects need wireframes?

    Wireframes are appropriate for any website bigger than a few pages and with more than one person involved in its creation. Wireframes are especially critical when multiple parties are involved in defining the scope and features of a website (such as a design team, development team and client team). When using a content management system that has custom fields and custom types of content (such as ExpressionEngine or Drupal), wireframes are often a key part of the project requirements process.

    Will my team understand wireframes?

    Yes! Wireframes are much easier for non-programmers to understand than a sitemap of pages or a spreadsheet of fields that will be in the database.

    If you’re worried a non-tech savvy group will have a hard time working with a wireframe, consider showing a smaller number of wireframes first, like only the home page and two or three key interior pages. In addition, when releasing the wireframes, be sure to walk the audience through the wireframes on common user paths to show how people will really be interacting with the site.

    Any other reasons you like to wireframe? What kinds of projects do you create wireframes for? Join in the conversation. Happy Wireframing!

    Nice article on wireframe basics by Susan Snipes. Good read for wireframing newbies or those who are thinking about using the process of wireframing for their next project.