1 Notes

Designing your process
Design is an organic process and thus different designers approach wireframing and its translation to visuals or code in different ways. You have to find the process that brings out your own strengths and you are most comfortable with. 
Excerpt on different design processes from Winnie Lim’s article: A Beginners Guide to Wireframing over at Webdesign Tuts+. 

Designing your process

Design is an organic process and thus different designers approach wireframing and its translation to visuals or code in different ways. You have to find the process that brings out your own strengths and you are most comfortable with. 

Excerpt on different design processes from Winnie Lim’s article: A Beginners Guide to Wireframing over at Webdesign Tuts+. 


Lean UX | Epic Bagel

A sketch I found on Jon Bolt’s aka Epic Bagle website illustrating a Lean UX process. Jon also states that Lean UX doesn’t naturally mean less UX but rather the opposite and that there is a strong emphasis on the actual experience designed, rather than UX deliverables.

Read the full article over at epicbagel.com.


Why Mess With Wireframes? | Viget

You may be wondering why, if wireframes don’t show exactly what the site is going to look like, do we bother with them? 

It’s a good question.

Wireframes are so valuable precisely because wireframes ignore questions of visual style that they’re so valuable. 

When we’re designing a page we need to consider several things:

  • How the page fits in with the site as a whole.
  • What content (text, images, video, etc.), links, and interactions we need to meet both user and business goals.
  • How all of these elements (content, links, and widgets) are going to relate to one another.
  • What it’s going to look like.

Wireframes carefully consider the first three points above without worrying about the fourth. It’s in the wireframes that we start to nail down details about context, content, and interaction. With these decisions made visual designers can get to work on a style that speaks to users, reinforces ideas suggested in the wireframes, and makes the page a pleasure to look at..

In addition to helping out visual designers, wireframes also present an opportunity to check in and make sure that the site design is going in the right direction.  Because wireframes don’t get into stylistic details they’re easier to create and much easier to change.  Comps (what visual designers make to show you how the page will finally look) take nearly twice as long to produce as wireframes, meaning they’re essentially twice as expensive.  The same ratios apply to revisions, too.  If we do the math we can see that paying attention to wireframes and revising at this stage is a good way to reduce risk and make sure design time is well spent.

What to Look For

When you’re reviewing wireframes it’s helpful to know what to look for. Since I’ve described what a wireframe is and what they’re trying to convey, you’ve already got a pretty good idea of how to review them, but let’s go over it again. Wireframes should tell you:

  • What content is going to be on the page
  • How the content is organized on the page
  • Which content is most important on the page
  • Where users will go from this page
  • Where this page is on the site
  • How users will move around the site

Phrased as questions, the list above is a good starting point for evaluating wireframes. As you’re looking at wireframes, ask yourself these questions and then ask yourself whether the answer the wireframe gives is the same answer you would give if someone asked you. Some other more detailed questions can also help you review wireframes:

  • Is anything important missing from the page?
  • Is the most important content the first thing you notice?
  • Is there anything on the page that shouldn’t be there?
  • Which content is related and how?
  • Can you get to all of the major sections of the site from here? Should you be able to?
  • Do all of the labels make sense?
  • Do you know what all of the elements on the page are?

Asking these questions should lead down a path to review and evaluate wireframes at the right level of design. Being able to identify problems at this point means that you can get them resolved in the wireframing stage, and you won’t be wasting time in the visual design phase resolving foundational problems.

What Kind of Feedback to Give

When you give feedback on wireframes, it’s the perfect time to point out any of the issues discussed above.  You should also include notes if:

  • Something needs to be higher on the page.
  • Something should jump out at the user more.
  • Something should be in the main content area instead of the sidebar.
  • There’s too much/not enough text or images.
  • Something is missing.
  • Something is confusing.
  • You can’t figure out how you would take a particular action on a page.

While the wireframes themselves do not define style, they will serve as a starting point from which visual designers can begin working. Because of this, you should pay attention to certain visual elements as you’re working on feedback for wireframes.  In many cases visual designers will take relative sizes and weight as cues for what should be more prominent on the page, so it’s good for you to provide feedback on these visual cues.

TJ Ward explains the value of wireframing and what questions you need to ask in the feedback/review process.

Read the full article over at viget.com.


Wireframes Vs. High-Fidelity Prototypes | The Pastry Box Project

Lately, there’s been some concern within the UX community about folks doing crazy things like skipping the critical IA step or ditching wireframes to go straight to hi-fidelity comps. Behind this is an implicit accusation: By choosing to ignore traditional UX methods and deliverables, you’re not really practicing good UX.

So… I think there’s a difference between skipping a phase versus internalizing a phase. As young students, we go through a very formal writing process in order to learn the skills needed to be a good writer; I doubt very seriously that any of us go through that same, explicit process as mature writers. We’ve internalized those things we were taught. I’ve found the same true of my work, where frankly it might appear that I am skipping “steps,” and am going straight to visual design, but I (personally) no longer have the need to expose these steps. Moreover, by going straight to a screen, people (stakeholders and users) are able to experience the IA & IxD by way of something pretty darn close to the final experience. This results in far better feedback than I ever got from abstractions like site maps or wireframes. One caveat, this “internalized” approach doesn’t scale to very large projects where the complexity is much greater (say, a very large site with tens of 1000s of pages). But, for most small web sites and all web apps, this integrated approach has worked great; I’ve traded steps for multiple rounds of iteration, which allows for much more learning and feedback early on.  Of course, the approach I’m describing assumes some prerequisite amount of experience…

Still, some will say that we must tease apart a project into discrete, isolated steps to get proper feedback on just the structure or just the interaction concept or just the look and feel. I say this is rubbish. Human beings don’t think about content separate from presentation separate from structure separate from [fill in the blank]… We experience the world around us as one integrated whole. By insisting that we create these artificial distinctions, we confuse more than help. Take wireframes: We’ve all hear clients ask “Is this what it’s going to look like?” 

Stephen Anderson on why in his opinion high-fidelity prototyping wins over wireframing. Read the full article over at the-pastry-box-project.net


Wireframing for better ecommerce. What and Why? | Tatvic

If you’re a website owner, designer, developer, stakeholder or someone who is involved in to process of designing a website or software, it’s very common to use wireframes. This blog post explains some basics of wireframes, why we should use them, and ways to create wireframes.

What are wireframes?

According to Wikipedia: “A website wireframe, also known as a page schematic or screen blueprint, is a visual guide that represents the skeletal framework of a website. The wireframe depicts the page layout or arrangement of the website’s content, including interface elements and navigational systems, and how they work together.”

Wireframes provide the skeleton of design at elementary level.

What they have:

  • Structure of each page
  • Content organization
  • Process flow

What they lack:

  • Colors
  • Real content
  • Look & feel
  • Design elegance

How do they fit in the design process?

A sample wireframe created in Adobe Fireworks

Wireframes decide the information architecture of the page/website you are going to design. It has flow of processes (shopping. Sign up etc.), page structure and rough look & feel of the end design. Elements on a wireframe are not necessarily to be aligned and be pixel perfect, and don’t require real content. After the wireframe is finalized, prototypes are created using professional tools like Adobe Fireworks, Photoshop etc. These prototypes are pixel perfect mock up, which has real content, colors and elegance. Some designers also use prototyping and designing mock ups as different processes. After mock ups are created, it goes for web development, where HTML and CSS codes are written, database connectivity, plug-ins installation etc. happens. After this, the website is tested again for functionality and it goes live if everything is perfect.

Why wireframe?

Save Time and Resources

Yes, wireframe adds one more layer to the process of designing. But it reduces or removes (removing is the core purpose) iterations. Less or no iterations reduce time, resources, and the most important, money spent.

Save iterations
In any organization, there’s almost everyone involved in taking decision about the design. Right from designers themselves, developers, analysts and SEO specialists, managers, and even investors have some role to play in entire design process. Thus, the design goes through enormous iterations. Follows the non-achievable deadlines to take it live, conflicts between teams, and chaos. Wireframes can be modified quickly and provide simulation of the website. After everyone is agreed upon the design and content organization, it can move to design process where colors other elegance can be added.

Be perfect
It’s not good for a designer to know about the design problems after it’s live or in testing process. By “Design problems”, I do not mean functionality related problems like “Form is not opening”. I mean things like, “The shopping process could have been smaller”, “Why is there no “About us” in the main menu?”

These are issues, which can come up as suggestions before the design process starts, because you are just starting the design process.

Everyone has ideas, but not Photoshop skills.
In some cases, there’ll be a user experience planner, marketer or even a CEO who will have some great ideas for a landing page, newsletter, an ad banner, or even an entire website. They usually cannot work on professional tools like Photoshop and present their ideas. Wireframing is a handy technique that’s available and possible to everyone with ideas to build something. Presenting a design idea will impact better as a tangible form like wireframes rather than just a list.

Kamaksh Gangani on his experience using wireframing in ecommerce projects. Read the full article over at Tatvic.


The Wireframe Dilemma ?

image courtesy of cennydd.co.uk
Cennydd Bowles posted this image over on his blog with the original title: “Why I don’t wireframe much”.

The Wireframe Dilemma ?

image courtesy of cennydd.co.uk

Cennydd Bowles posted this image over on his blog with the original title: “Why I don’t wireframe much”.


Big Brother Prototype Wireframe | Barnabas Nagy

My idea for a new wireframe originated in the frustration of having created great personas and user journeys and not applying them on the prototype. It was so helpful for me to see these newly styled user flows and personas because they helped me visualise my users. However, I quickly forgot about them when I started creating the prototypes. The prototype got simply detached from what I’ve learnt from my personas and user journeys. I thought to myself that there had to be a better way.

Searching for a better way

Then I’ve come across this great essay on personas and scenarios. There was one particular idea that excited me quite a bit. This idea was very simple. The writer of the essay displayed couple of photos where the designer had real-life-size cut outs of the personas next to his desk. Below is a photo from the Essay.

I was like wow! I should always have my personas around to remind me of who I work for. So I printed out my personas on a A4 sheet and sticked it onto my wall in front of me. That felt great. They reminded me to keep them in my mind when creating the website prototype.

Need for Tweaking

The printed out personas were great for a while only until I forgot about them. The outside world and the computer screen are two different worlds. Those who work with a computer daily know what I am talking about. So I thought I should bridge this gap.

The idea

What I did was simply creating a left sidebar for my personas on the prototype! As I have placed them there it looked as if they were always watching me working. So I called this the “Big Brother Prototype”. Here it is, an example for my Big Brother Prototype. You can also view the demo here. The only similar concept I came across is Agile People.

How to do it step by step

Create your prototype in axure but leave a small sidebar for your personas. This sidebar could be around 100px to 200px wide. As you can see on the example above, mine has 150px and a little padding from left and right and from the top. Link your person pictures to your personas. That’s it! You can call it “Personas”, “Big Brothers”, “My Users”, “The Audience”, I called it “The Panel” as they are my judge when creating the prototype. In fact you can use and modify this concept as you like. You can also download the axure source file to get started.


The Big Brother Prototype will constantly remind you that you are creating the prototype for your users. It will help your clients also because it makes it very clear that it’s their users who will be the ultimate judges of the website and not them.

Barnabas Nagy thoughts on tying personas to wireframes. You’ll also find a reworked version of this article over at UXMovement.


You can’t design a User Experience with a wireframe - Stuff in my head

Wireframes are dead. And good riddance too.

I’m not a fan of wireframes. Never have been. And by wireframes I mean flat diagrams of boxes, lines and placeholder elements for UI widgets, forms and media. 

There’s very few scenarios I can think of where a wireframe has managed to express the intent of a design i’m working on to a level that’s useful beyond a loose guide to IA and page topography. 

Wireframes test horribly test like crap. I’m almost ashamed to have made some big (and potentially costly) design decisions on behalf of clients on the basis of the testing from a wireframe. I’m loathed to ever put another wireframe in front of a user again and ask them to engage with it. They’ll muddle through sure - and occasionally it can help identify comprehension issues and help refine flows, but ropey sketches can also do that too and take a lot less time. It’s so dangerous making big assumptions based on the response to a wireframe because it’s so far removed from the actual product you’re designing. So don’t. Test on paper first, talk to people, then build a prototype and test it properly. 

Too many UX designers waste everyone’s time working up wireframes when they should be working on the actual experience. That comes through the value proposition/exchange, the content and messaging, the GUI, the interaction and the stateful nature of software. And the only way to do that is to build functional prototypes with real content in them.

Visual Design must die too

To get to this state we also need to get over this precious notion that early aesthetic is in someway detrimental to the design process. Sure, if you wade in too soon with a polished UI you risk taking the clients eye off the ball with regard to the design problems you’re trying to communicate and fix, but that’s your fault not theirs for not explaining your rationale properly. We must stop thinking that visual design exists as a layer on top of the stuff we make. It’s not, it’s intrinsic - just like the interaction and behavioural facets of our designs. A design doesn’t really start making sense until it’s all in place - even if not to a finished level of fidelity. Colour, typography, texture, hierarchy, disruption, weight, whitespace… (I could go on) are as important (if not more so in some regards) to the IA that holds it together.  

For some that either requires skilling up or working closer with UI designers, Developers or whoever needs to be involved depending on the skillset of the UX designer doing the work but unless we stop designing diagrams of things instead of actual things you’re not designing an experience you’re designing an expensive hypothesis.

"You can’t design a User Experience with a wireframe" is a quite controversy post by Alex Morris on why in his opinion wireframes are pretty useless. Agreed to the extent that you can’t wireframe for experience without focusing on analyzing and structuring upfront. Plus we should always bear in mind that wireframing is just one part of designing for user experience.


Writing Smart Annotations | Boxes and Arrows

One of the most tedious, yet necessary, tasks of an information architect or interaction designer is annotating wireframes.

Now that you’ve figured out the navigation, placed the content, and figured out page flows, it’s time to explain just what exactly that collection of “Lorum ipsum” greeking, HTML widgets, and X-ed out boxes are, how they work, and how they meet the site goals. That’s where annotations come in.

Annotations are brief notes, typically on the side or bottom of a wireframe, that attempt to describe each item on the wireframe. They have a difficult role: to speak for the wireframe’s designer when she isn’t there. In theory, when developers or clients want to know just why that link was placed in that spot, they can read the note on the document and understand not just what the thing does, but also why.

Write for your audience

There are typically five audiences for wireframes: clients (internal or external), developers, visual designers, copywriters, and, most importantly, your future self. All of these have different needs, and addressing them all in the annotations — especially given the small area that annotations typically inhabit on the wireframe — can be difficult.

Clients will want to see that you’ve incorporated the business goals they provided. Developers want to see what they have to support, and how the site or application works (and doesn’t work: don’t forget to document what happens when an error occurs). Designers want to see what visual elements need to be on the page. Copywriters want to see what they need to write. And you — the future you — need to remember why you made that form element a checkbox instead of a radio button.

One way of tailoring your annotations to multiple audiences is by creating a different set of wireframes for each. Some software, like Visio and Dreamweaver, lets you do this through layering. The IA creates a different layer of annotations for each audience, and then prints out, say, the developers’ version for their use.

Personally, I find this method to be too much effort for too little reward. Instead, I separate my annotations into two main sections — content and functionality — and display them both for everyone. Developers will mainly look at the functional notes, copywriters the content ones, and everyone else will pick and chose between both.

Since you have (at most) a long paragraph for each annotation and five audiences to write for, make sure you are applying Strunk and White’s writing guidelines: shorter sentences, clearer thoughts, no jargon.

What to annotate

There’s a tendency among new IAs to annotate everything. Don’t. Instead, be smart about what you put in the wireframe and how. The clearer you make the actual wireframe, the less you will have to explain in annotations.

For example, rather than drawing a gray box with an annotation that says it is the logo, just put the word “logo” on the gray box. For paragraphs of text, use greeking only when the paragraph’s content is obvious. Otherwise, you are better served by writing something like “This is a paragraph introducing this section. This is a paragraph introducing this section.” etc., right in the wireframe.

Things that should be annotated:

  • Any items that are conditional — when and how they should be displayed.
  • Links and buttons — what happens when they are clicked.
  • Anything that, due to space, could not be shown on a wireframe, e.g., every item on a long drop-down menu.
  • Anything with a business, logical, or technical constraint — e.g., the longest possible length of a password field.

  • In short, anything that is not immediately obvious from looking at the wireframe should be documented.

    Show the process

    Annotations have to capture not only what is being displayed (and where and when), but also why. The more you can document your thought process and the decisions you made, the easier it is to explain your work, defend it from criticism, or fix it in case you’ve made a wrong decision.

    Documenting the why is the biggest challenge, especially given the space limitations. But there is a vast difference between an annotation that reads, “Show first 10 new messages” and one that reads, “Due to possible hundreds of new messages, only show the first 10.” In the second version, the reader immediately knows the reasoning behind the decision to only show 10. If there’s a change (“Oh, we’ve cut back the number of messages we’re sending to one per week”), it’s easier to adjust the wireframe appropriately.

    Of course, sometimes the “why” is so obvious there’s no need to document it. There’s no reason to say, “Passwords will be starred out for security reasons.” Duh. Sometimes the reasoning is too complicated to put into an annotation, in which case I usually create a separate, attached document that shows the decision process, usually in flowchart format.

    It’s okay to cross-reference other documents for support. If your business requirements state you can only store two email addresses, reference it (e.g., See Business Requirements, page 30, requirement 3). Even better, quote the requirement directly (e.g., “Only two email addresses can be stored due to estimated server space, as per Technical Specifications, page 13.”). Both of these examples are better than simply noting that only two email addresses can be stored. Three days or three years from now when someone asks why you can only have two email addresses, you’ll know.

    It’s probably not a bad idea to use a small, separate area to note the documentation that affects the wireframe either: business requirements, technical specifications, use cases, etc. For one thing, it shows you’re not working in a vacuum, and lets other team members reference those documents as needed if there are questions.

    If you disagree with any requirement, note that too. Perhaps two email addresses aren’t nearly enough to support how users are going to use the product. In the template I use for wireframes, there is a shaded box for issues and notes. Many times, I note where business or technical constraints have lessened the usability of a product. That way, I can either argue them now, or, if the clients or developers are reluctant to change the requirements, I can bring them up in the future, when complaints come in or another version is planned.

    Another nice thing to note, process-wise, are the changes to the wireframe as you go through revisions. Your wireframe might be labeled “version 2.5,” but how does it differ from version 2.4? On my wireframe template, I have another shaded box where I list all the changes to the document from the previous version. Clients like this: it shows progress and it shows that you are actively addressing issues that have arisen during the project.

    I hate to annotate

    I’d be surprised to find an IA who enjoys spending his time explaining every nuance of his designs. Designing is the interesting part, not annotating. As in telling a joke, explaining takes the fun out of it. But by annotating well, you think better and design better, and a year from now, when you ask yourself, “Why did I do that?” when looking at a past project, you’ll know. And it may help you make better decisions next time.

    Just stumbled upon this article, Dan Saffer wrote in 2003 for Boxes and Arrows. In this article Dan describes the communication/feedback process through annotations and points out the most important questions you need to ask yourself when annotating wireframes.


    20 Effective Examples of Web and Mobile Wireframe Sketches

    A wireframe sketch is the initial hand-drawn design process, using paper and pen/pencil, of what a website design will look like. And to help you get inspiration as well as effective reference points, this article features 20 impressive web and mobile wireframe sketches.

    But first, you might be wondering why the heck you should create a wireframe sketch of your web design. A wireframe sketch is effective in that:

    • You can capture your creative spark and fluidly sketch out your design.
    • You can work with your client without committing anything to code, thus saving yourself time and number of actual design revisions.
    • You get a relatively quick sample that you can show the client and then work off of – think of is as an outline to an essay.

    Basically, creating a wireframe sketch saves you time by reducing the number of revisions you’d need to do, and it helps you stay on track with your design by being a prototype you can work off of.

    Hand-drawn Wireframe Sketches

    A nice touch with this sketch are the visual cues – such as the play button with the triangle and circle – which make the otherwise-stripped-down sketch detailed. You know that the rectangle is a media player rather than just some content to be decided on later.

    The above sketch uses highlighted numbers and zoom-ins nicely, which makes the entire sketch much cleaner and more readable. The column to the right of the sketch has all of the numbered text descriptions of each element, and the zoomed-in elements give more detail without cluttering up the main sketch.

    A complex and detailed sketch that uses illustrations nicely by showing an example of what would be contained in a rectangle and square element. It doesn’t just rely on text or the client visualizing it.

    Another nice use of illustrations. Despite the hand-drawn nature of the sketch, the details – the logo, a vivid splash image at the top – give a concrete prototype of what the final design will look like.

    Another solid illustration example. The arrow-using descriptions on the sides effectively explain technical details, like the width of the page being the width of the browser window.

    A nice grid design sketch. Using perpendicular lines that extend past the design reinforces the grid of the design, especially since hand-drawing a sketch can make a other-wise solid design appear loose and floating.

    A clean and crisp sketch that shows a fairly simple web page design in great detail.

    This design shows that you don’t have to be an artist to draw effective wireframe sketches. The squares are all warped, there’s not much artistic detail in the elements, and the text is crooked in places. Despite all that, you get a clear sense of how the design will look like and what each element will be. Ultimately, it’s about creating a wireframe with your sketch, not a finished stylized design.

    Another example of a grid design. Though the lines aren’t straight or there aren’t lines reinforcing the grid design, the elements are close enough together that you understand that the tables will be parallel to each other.

    Digital Wireframe Sketches

    A sketch of a mobile calendar. It’s not only detailed but wisely illustrates a pop-up when you select an element. This way, you can see how the design will function as well as how it will look.

    This homepage design gives you a clear idea of how the big elements – image, block of text – will look like without wasting time on “lorem ipsum” text and sample images.

    A grid design sketch that reinforces itself with vertical bars. You can see how each element will line up and where it’s located relative to other elements.

    This spare bare-bones sketch shows that, like with the hand-drawn sketches, you don’t need to be a digital artist wiz to create an effective wireframe sketch. A few squares, rectangles, lines, and pieces of text are enough to show how the design will be.

    Another example of a spare bare-bones sketch, this time showing a design that’s more complex. As long as the elements are where they need to be, different shades of grey are used to differentiate elements, and some simple text describes what each thing does (when needed), then you’re good to go.

    The home page wireframe sketch of a social network that was shown in the previous sketch (which was the main/activity screen).

    Color is effectively used in this e-commerce sketch. The light blue illustrates what are buttons, and the rest of the rectangles in the sketch are either for text input or selectors.

    This sketch almost-finalizes all the essential elements (like buttons) while not wasting time on colors, background, and other styling whoseawhatsits.

    Shades of grey are used effectively here to differentiate images from the background, and the blocks of text give you a clear idea of how the real content and web page will look like.

    This sketch goes so far as to style the text, buttons, and other elements while not wasting time on colors, the background, and sample images. This shows that by completing the 20% of elements that are most important – while ignoring styling the 80% that isn’t – you can get a almost-complete picture of the design with only a wireframe sketch.

    Like with the above sketch, this wireframe sketch also focuses on styling only the 20% of essential elements while ignoring the rest. You get a very clear picture of what the final web page will look like without the sketch needing to add colors, backgrounds, and the rest.

    Oleg Mokhov compiled a collection of hand drawn and digital wireframes for your inspiration.