Ryan Singer on Web Application Craftsmanship
via viddler.com
Very interesting talk by Ryan Singer from 37Signals at the FOWD 2007 on WebApplication Interfacedesign & Usability.
Wireframe Wednesday |
The ultimate Wireframe Archive |
Very interesting talk by Ryan Singer from 37Signals at the FOWD 2007 on WebApplication Interfacedesign & Usability.
Prototyping is key to any successful design. Paper prototyping is usually the first step, but does it fit into a world where mobile devices are king? Yes, but not using the conventional method. Combine the physicality of the device and the power of paper prototyping and you have a solution that’s fit for the new era of computing.
Paper prototyping is a key component of the user-centered design (UCD) process and is a popular method among designers. The characteristics of paper prototyping lends itself to the iterative approach that is so valuable in the UCD process.
The basic premise of this method is that a paper prototype of a feature’s UI is crafted and then given to a user who will attempt to complete a task or a scenario. Evaluators record and analyze the results from these sessions, which are then used to create another prototype.
Designed for a simpler time
The method is great for designing UIs for desktop computers as the user’s fingers mimic the input of a mouse. Therefore, paper prototyping mobile touchscreen UIs would surely be perfect, right? No! It would make sense, but there are many more factors that need to be considered when designing and evaluating mobile touchscreen UIs.
When interacting with desktop computers, users will usually be in a “controlled” environment, in the comfort of their own homes or offices. Mobile devices can be used in the queue at Starbucks or simply when walking in the street, and therefore lack the luxury of that “controlled” world. These devices can be used in any environment and held in several different ways, and these are two key reasons as to why the standard paper prototyping method doesn’t lend itself to mobile devices. The hardware is as important as the software when it comes to mobile devices, and those that understand its strengths and constraints will create better overall solutions. Therefore, incorporating the physical device into the early prototyping stages is vital.
How to paper prototype
In the July/August 2009 edition of Interactions magazine, three academics from the School of Informatics at Indiana University suggested a technique that incorporated paper prototyping and the physical device—in their case, an iPhone.
Their method had several stages:
- Create the paper prototype.
- Digitize each screen by photographing or scanning.
- After importing, resize each image to fit the device’s screen.
- Save the resized images in a file format supported by the mobile device.
- Organize all the screen images into the correct order for the scenario.
- Upload the images to the mobile device.
- Explain to the user how to navigate through the scenario. In their case, swiping through the set of images on the iPhone.
The “Paper in Screen” method was a success for the Indiana University academics as it not only raised “issues on interface labels, content organization, and affordance,” but also facilitated “discussion on the overall utility of the application for realistic mobile scenarios of usage.”
During a recent academic assignment, I decided to implement the ‘Paper in Screen’ method, but chose to add an additional step to increase interactivity as well as return different types of issues.
Using iWeb to create the links
After importing and resizing the images, I opened up Apple’s iWeb application. I set the webpage size to the iPhone’s resolution and then gave each image a separate page. Following this, I placed links on top of the buttons on my paper prototype which when clicked would send the user to another page. I then uploaded this to the Internet, and downloaded one of the many full-screen browsers for the iPhone. This allowed me to hide all the browser’s chrome and show only the prototype images. During this assignment, I was unable to find a solution that would store the HTML files locally and act correctly as a prototype. Due to this issue, this method requires an Internet connection, preferably Wi-Fi, however a decent 3G connection was more than satisfactory.
Final thoughts
A user working through the scenario using the prototype in a full-screen browser.
This method allowed the user to interact with the prototype like they would with any other iPhone app—minus the animation—and me to test the prototype in real world environments. Conventional paper prototypes restrict users, requiring them to follow the specific order of screens set out by the designer. By making the prototype more interactive, you allow the user to deviate and make mistakes without requiring intervention from the designer. No intervention means the user will feel in control and relaxed, hopefully yielding more realistic results.
Merely adding one additional step to this method can change the types of evaluations and results you receive from paper prototyping yet still retain the inherent advantages found with the technique such as no coding involved, fast and cheap to mockup interfaces, as well as encouraging creativity from other designers and more importantly, the users.
Article about paper prototyping featured on UX Booth, written by Thomas Davies.
Prototyping is the process of building a model of a system. In terms of an information system, prototypes are employed to help system designers build an information system that intuitive and easy to manipulate for end users. Prototyping is an iterative process that is part of the analysis phase of the systems development life cycle.
During the requirements determination portion of the systems analysis phase, system analysts gather information about the organization’s current procedures and business processes related the proposed information system. In addition, they study the current information system, if there is one, and conduct user interviews and collect documentation. This helps the analysts develop an initial set of system requirements.
A prototype is an original type, form, or instance of something serving as a typical example, basis, or standard for other things of the same category. The word derives from the Greek (prototypon), “primitive form”, neutral of (prototypos), “original, primitive”, from protos, “first” and typos, “impression”.
In semantics, prototypes or proto instances combine the most representative attributes of a category. Prototypes are typical instances of a category that serve as benchmarks against which the surrounding, less representative instances are categorized (see Prototype Theory).
In many fields, there is great uncertainty as to whether a new design will actually do what is desired. New designs often have unexpected problems. A prototype is often used as part of the product design process to allow engineers and designers the ability to explore design alternatives, test theories and confirm performance prior to starting production of a new product. Engineers use their experience to tailor the prototype according to the specific unknowns still present in the intended design. For example, some prototypes are used to confirm and verify consumer interest in a proposed design whereas other prototypes will attempt to verify the performance or suitability of a specific design approach.
In general, an iterative series of prototypes will be designed, constructed and tested as the final design emerges and is prepared for production. With rare exceptions, multiple iterations of prototypes are used to progressively refine the design. A common strategy is to design, test, evaluate and then modify the design based on analysis of the prototype.
In many products it is common to assign the prototype iterations Greek letters. For example, a first iteration prototype may be called an “Alpha” prototype. Often this iteration is not expected to perform as intended and some amount of failures or issues are anticipated. Subsequent prot otyping iterations (Beta, Gamma, etc.) will be expected to resolve issues and perform closer to the final production intent.
In many product development organizations, prototyping specialists are employed – individuals with specialized skills and training in general fabrication techniques that can help bridge between theoretical designs and the fabrication of prototypes.
There is no general agreement on what constitutes a “prototype” and the word is often used interchangeably with the word “model” which can cause confusion. In general, “prototypes” fall into four basic categories:
Proof-of-Principle Prototype (Model) (also called a breadboard). This type of prototype is used to test some aspect of the intended design without attempting to exactly simulate the visual appearance, choice of materials or intended manufacturing process. Such prototypes can be used to “prove” out a potential design approach such as range of motion, mechanics, sensors, architecture, etc. These types of models are often used to identify which design options will not work, or where further development and testing is necessary.
Form Study Prototype (Model). This type of prototype will allow designers to explore the basic size, look and feel of a product without simulating the actual function or exact visual appearance of the product. They can help assess ergonomic factors and provide insight into visual aspects of the product’s final form. Form Study Prototypes are often hand-carved or machined models from easily sculpted, inexpensive materials (e.g., urethane foam), without representing the intended color, finish, or texture. Due to the materials used, these models are intended for internal decision making and are generally not durable enough or suitable for use by representative users or consumers.
Visual Prototype (Model) will capture the intended design aesthetic and simulate the appearance, color and surface textures of the intended product but will not actually embody the function(s) of the final product. These models will be suitable for use in market research, executive reviews and approval, packaging mock-ups, and photo shoots for sales literature.
Functional Prototype (Model) (also called a working prototype) will, to the greatest extent practical, attempt to simulate the final design, aesthetics, materials and functionality of the intended design. The functional prototype may be reduced in size (scaled down) in order to reduce costs. The construction of a fully working full-scale prototype and the ultimate test of concept, is the engineers’ final check for design flaws and allows last-minute improvements to be made before larger production runs are ordered.
In general, prototypes will differ from the final production variant in three fundamental ways:
Materials. Production materials may require manufacturing processes involving higher capital costs than what is practical for prototyping. Instead, engineers or prototyping specialists will attempt to substitute materials with properties that simulate the intended final material.
Processes. Often expensive and time consuming unique tooling is required to fabricate a custom design. Prototypes will often compromise by using more flexible processes.
Lower fidelity. Final production designs often require extensive effort to capture high volume manufacturing detail. Such detail is generally unwarranted for prototypes as some refinement to the design is to be expected. Often prototypes are built using very limited engineering detail as compared to final production intent.
Engineers and prototyping specialists seek to understand the limitations of prototypes to exactly simulate the characteristics of their intended design. A degree of skill and experience is necessary to effectively use prototyping as a design verification tool.
It is important to realize that by their very definition, prototypes will represent some compromise from the final production design. Due to differences in materials, processes and design fidelity, it is possible that a prototype may fail to perform acceptably whereas the production design may have been sound. A counter-intuitive idea is that prototypes may actually perform acceptably whereas the production design may be flawed since prototyping materials and processes may occasionally outperform their production counterparts.
In general, it can be expected that individual prototype costs will be substantially greater than the final production costs due to inefficiencies in materials and processes. Prototypes are also used to revise the design for the purposes of reducing costs through optimization and refinement.
It is possible to use prototype testing to reduce the risk that a design may not perform acceptably, however prototypes generally cannot eliminate all risk. There are pragmatic and practical limitations to the ability of a prototype to match the intended final performance of the product and some allowances and engineering judgement are often required before moving forward with a production design.
Building the full design is often expensive and can be time-consuming, especially when repeated several times—building the full design, figuring out what the problems are and how to solve them, then building another full design. As an alternative, “rapid-prototyping” or “rapid application development” techniques are used for the initial prototypes, which implement part, but not all, of the complete design. This allows designers and manufacturers to rapidly and inexpensively test the parts of the design that are most likely to have problems, solve those problems, and then build the full design.
This counter-intuitive idea —that the quickest way to build something is, first to build something else— is shared by scaffolding and the telescope rule.
With the recent advances in computer modeling it is becoming practical to eliminate the creation of a physical prototype (except possibly at greatly reduced scales for promotional purposes), instead modeling all aspects of the final product as a computer model. An example of such a development can be seen in the Boeing 787 Dreamliner, in which the first full sized physical realization is made on the series production line. Computer modeling is now being extensively used in automotive design, both for form (in the styling and aerodynamics of the vehicle) and in function — especially for improving vehicle crashworthiness and in weight reduction to improve mileage.
Nice article on prototyping from Webaxes, which gives an overview on prototyping from a product development point of view.
All of the printable sketching templates that you will find below have all been designed specifically for web designers. Each of the sketching templates have an imprint of a web browser (they either use Safari, Chrome or Firefox) just waiting for you to wireframe or sketch your next design project.
Each template is slightly different, most have various grid sizes, others are either blank or lined and some of them have allowed space to accommodate some note-taking.
Below the free templates you will find a small selection of notepads and sketchpads (sorry, they are not free, pretty cheap though), again designed with the imprint of a web browser and all cool enough to merit a mention.
The Web Design Sketchbook features a series of design and layout brainstorming pages with full browser chrome and grids to better plan how your site will look and operate when it is finished. It features thumbnail, detail and full page sizes for more efficient brain storming and detail development.
You can view the printable templates below:
Each box from Paper Browsers templates are proportionally scaled to 1024x768px screen resolution to put you right into perspective. Each screen is subdivided into width sections (800, 960, 1024) to give you sense of approximations. It is a great tool to get you started with those creative concepts.
You have a choice of five various templates, you can preview and download them below:
Nice collection of printable wireframe templates curated by speckyboy.com.
Ah, the wireframe. The bread-and-butter of the UX designer. The IA’s best friend. And possibly, the bane of your existence. It all depends on how you view them.
Wireframes are an indispensable tool for design thinking—a digital sketch pad—ready to be drawn and erased, scrapped or resurrected at any moment. A working documentation used to establish the language, content, and structure of interactions users will have with the product. They are a fundamental part of the design process and vary in fidelity depending on how dogmatic your beliefs about their purpose.
The UX community is certainly divided on this point. There are those who will defend the lo-fi wireframe to the death, swearing off high fidelity wireframes as visual candy and premature over-designing and emphasizing the importance of not getting “design” mixed in with Information Architecture and functionality at this stage.
And then there are those who swear by the hi-fi wireframe. Their argument being that these artifacts are the easiest way to get a client/user to understand the full context in which a product or service is to be interacted with and function.
However, the truth is neither of these implementations (nor any variation in-between) is the be-all, end-all way to wireframe. As with anything we do in designing the user experience, it all comes down to context. What do you need to accomplish with the wireframes? Who is the audience? Are you over-designing when you should be more focused on the pure interaction and user task flow? And, conversely, should you be providing more of an authentic experience for the user to have familiarity and leverage their experiences with similarly designed elements?
There is no right way to wireframe. You must understand the context and the requirements for the project and move ahead accordingly. Know that regardless of the fidelity of the wireframe, it is still simply a tool in the design process that you can utilize to quickly get feedback, prove out your design decisions and help you make a better product.
Interesting post by Joshua Brewer on the everlasting battle between those who prefer lo-fi vs. high-fi wireframing.
If you develop web sites you're probably pretty familiar with the wireframe, and if you're a user experience designer you're probably rolling your eyes at yet another post about what a wireframe is and what it's good for. If, on the other hand, you're not involved in the mucky details of site design and development, wireframes may seem a little mysterious. If that's you, you're not alone. The fact is wireframes are commonly misunderstood by stakeholders, especially when they're new to the web. I regularly have to explain to clients what a wireframe is, how we use wireframes, and sometimes, why they should pay attention to them. If you're new to wireframes, I'm here to get you up to speed on what a wireframe is and how to read one. If you already know all about them, maybe you can use this post to educate your stakeholders.
A staple of user experience work, a wireframe is a skeleton of a page. It shows the priority and the organization of things on the screen and how users will get to other parts of the site. Wireframes range in fidelity from quick sketches on a whiteboard to detailed computer renderings. While wireframes will vary in their level of detail, they generally reflect the designer's ideas about the placement of elements on the page, the labeling of elements, site navigation, and how the user will interact with the site.
Typically, UX designers ignore questions of style and "look" when creating wireframes. A wireframe will give you sense of elements' placement on the page and relative to each other and which items will get stronger visual treatment, but it won't speak to color, graphics, spacing, or typography. UX designers typically leave those kinds of details to the visual designers so they can focus on other aspects of the page. Visual designers can then take the wireframes and work out all of the glossy details to create a design comp.
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:
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.
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:
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:
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.
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:
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.
Wireframes are an important part of web page design because they document decisions about content, content organization, content priority, and navigation without concerning themselves with visual styles. They present an opportunity to make sure the project is going in the right direction. Giving good feedback during the wireframing stage of a project will ensure that your visual design time will be used efficiently and to its greatest advantage.
Great post by TJ Ward on the purpose of wireframing from a stakeholders point of view. Starting off by explaining what a wireframe is and what it does he also points out how a client can focus on asking the right questions.
t’s much cheaper to change a website early on in the development process than it is to make changes later on. Building prototypes – draft versions of your website – is a good way of nipping problems in the bud and getting things right first time around.
At Super User Studio – a user experience design consultancy that offers research, strategy, design and evaluation services to leading online brands – we consider prototyping an essential part of web design. In this tutorial, we’ll walk you through the process from start to finish.
Over the past year we’ve worked with the educational site, Teachers TV, to refine its registration process, introduce new elements to its site and produce the strategy and design for My Viewing Log – a tool that enables you to record how Teachers TV videos impact on your classroom practice.
Before you begin the prototyping process, you’ll need to work on research and strategy for the project. You’ll also need to have worked on the initial information architecture, to map out the world of the product you’re designing and vital user pathways through that world. There’s a range of UX tools and techniques to support your preparation for prototyping, but they won’t all be necessary for every project. The idea is to deploy those that will sufficiently support your understanding of business objectives and user needs, and which you deem most appropriate for your project.
At Super User Studio, before we start prototyping we usually give attention to things like: client brief; business requirements; heuristic evaluation; usability testing; user research; audience analysis or personas; competitor analysis; best of breed review; content/data requirements; features requirements; sitemap; user scenarios; task flows; and user journeys.
TechniquesYour end prototype should be a fairly refined and testable representation of the product. There are several techniques you can use to reach this point, which again will be project-dependent. For example, if you’re working on a fairly simple web application, you may decide to go straight to an interactive prototyping tool such as Axure or iPlotz. With this approach, you’ll consider the information, navigation and interaction design at the same time. However, content-driven websites usually require separate focus on information and navigation design through the use of wireframes. This enables you to work on presenting the information in a way that facilitates user understanding, before you think about how the product has to function.
Remember, your approach should be prescriptive and you may not tackle the prototype in a linear way. Ultimately, your goal is to reach a solution that combines decisions on navigation, information, interface and interaction design, while fulfilling business requirements and user needs.
The simplest way to get started is to use the humble pen and paper. First, refer back to the list of features and content requirements gathered when undertaking your research and strategy. Then sketch out the rough areas of content for each of the major templates or screens of the product. You can do this by dividing the page into rectangles, then label each area to indicate what content or data it represents. The most important purpose of these sketches is to get your team thinking about the experience you want the user to have of the product. It’s an exercise that can be shared with clients and users too, and revisions can be made speedily.
Super User Studio often workshops with stakeholders, using paper, scissors, whiteboards, flip charts, index cards and Post-It notes to produce these early prototypes. Some may move straight to interactive prototyping from here. Others will use the sketching exercise as a means of eliminating more obvious solutions, before digitising the sketches and thinking more deeply about the product’s information space.
For those projects that require independent consideration of information design, there’s the process of wireframing. Much like your early sketches, wireframes are page layouts that illustrate the information space of the product and depict how that information is presented to a user. Getting started on wireframes involves pulling together your sketches, any workshop notes, user research, strategy, content ideas and feedback into a skeletal format. Your first wireframes should be low-fidelity, as it’s important to gradually build detail into them. In other words, you shouldn’t be too concerned about working with specific data or content initially, nor making them look like the finished product. Instead, your focus will be on considering what basic features are to be presented on a page, their relative importance or hierarchy and the behaviour of that information in line with user needs.
Different user-experience professionals will use different tools to produce their wireframes. At Super User Studio, we use Adobe InDesign because we find it fast to use and you can set up a library of reusable components. You can find some components for your project here. Building an asset library ensures you use consistent design solutions across your wireframes. With InDesign, you can also create a lovely, ordered bunch of PDFs to present to clients.
This brings us to the issue of the wireframe’s audience. As well as being an important part of the design process, wireframes have generally become part of the client-facing process too. With this in mind, it’s crucial you keep documentation well organised. At Super User Studio, we refer back to previous IA diagrams to ensure titling and enumeration is carried through consistently. Sometimes, we’ll use subtle shading and contrast to differentiate key elements of a page to promote understanding of the layout. We also provide concise annotations, which we’ll look at later. It’s important to ensure that your varied mix of stakeholders is communicated with effectively.
Ideally, your low-fi wireframes will be reviewed by all key stakeholders, including your project team, clients and users. Before you show them to clients, however, be sure to inform them of the purpose of these greyscale depictions of their product. They may not be used to viewing wireframes, so it’s important to explain that they don’t represent the end layout of the product. Instead, their purpose is to encourage discussion, deeper thought and iteration. At the same time, you’ll need to be prepared to absorb feedback and not get too attached to any early assumptions you’ve made about layout. Dan Brown has a good take on this in his book Communicating Design: “Very rarely, if ever, is design work accepted on the first pass, and sometimes you can only hope to be ‘wrong in the right direction.”
High fidelityOnce you’ve compiled your feedback and made the necessary amendments to your wireframes, you may decide to move on to interactive prototyping. This again will be dependent on the product you’re designing. Developing your wireframes further will give you the benefit of applying greater thought to the layout of information and the ability to move away from familiar structures to something that’s more bespoke for the product and its users.
To move on to high-fidelity wireframes, you’ll need some specific data or content in place. In an ideal world, you’ll have all the signed-off content for the product you’re working on, but in the real world this isn’t always possible. Sample content or data where relevant may be all you need for some projects, especially when you’ve given thought to the overall content or data requirements at the beginning. Having an overview of the product’s content or data requirements and access to actual content in places should give you what you need to produce a sustainable design solution.
This is also a good point to review any competitor research you may have undertaken. This will enable you to assess how competitors tackle any similar data or content challenges and to consider how your client’s product can distinguish itself from them. Re-introduce yourself to the key users of the product too, by reviewing your user research. Reminding yourself of how and when an archetypal user might interact with the product, for example, will directly influence your interface design decisions.
There are lots of resources out there to support the development of your wireframes: try looking up uipatternfactory.com. Alternatively, see how others approach their wireframes at wireframes.tumblr.com.
Annotating wireframesAs your wireframes become richer in detail, you’ll feel the need to annotate. Annotating your wireframes will ensure your information and navigation design decisions are documented and traceable. They should also communicate these decisions to stakeholders as clearly as possible.
Everyone has their own way of annotating. We use number stamps on the wireframe that correspond to notes made in the margin or at the bottom of the page. We prefer to keep annotations on the same page as the wireframes where possible, to aid readability and quick interpretation. It goes without saying that your notes should be as unambiguous and jargon-free as possible.
Just as you put yourself into the mindset of the users when creating the wireframes, it’s the stakeholders’ shoes you need to step into when annotating them.
Designers will need to know the varying visual styles required for a component. Developers will need to know the functionality behind that component, where its information is sourced or how that information behaves. The client will be keeping their eye on how your decisions are fulfilling business requirements. We often colour-code our annotations to highlight who they’re most relevant to. Alternatively, you could try splitting up your annotations into different categories. Whatever your approach, keep it as uncomplicated as possible.
As well as enumerating and titling each wireframe, you may wish to include a brief description of the page. This is particularly important when one web page or screen has multiple states of interaction depicted across multiple wireframes. For example, you could describe a user’s stage in a task flow like a registration process, what key tasks they can perform on that page or even which business requirements are being met at that point.
There’s no need to make annotations on every design decision, though. You’ll only end up diminishing the efficacy of the wireframes if you over-annotate them. Stick to notes on the unobvious or the conditional, such as:
- Navigation & links – where do they link to?
- Functional explanations – how a form behaves with and without Ajax functionality or process rules
- Information sources – unobvious aggregated content
- Changes in the user interface – how the interface alters dependent on information already submitted by the user or particular user type
- Conflicts against requirements – when you’ve made a decision that conflicts with a business, technical or user requirement
- Content or data explanations – what information needs to be contained within a dropdown and reference to where that information can be accessed
- Reference to previous documentation – a note about how other IA or user experience documents (such as personas, user scenarios or task flows) have affected your decision-making
If you do refer to previously delivered documentation, make sure you once again present those documents with the wireframes. We usually redeliver any user profiles or personas we’ve created anyway. This brings you and all stakeholders to common ground when discussing the wireframes. Inevitably there will be differences of opinion, but by keeping primary users and their needs in mind, everyone can ensure that user expectations are equally balanced with business objectives.
Most importantly, think about how these annotations can support your design process. Crucially, by making notes about the reasons for certain decisions, you’ll be able to consider whether any later requests for changes are really feasible. Including some form of version history within your annotations will also help you keep track of the changes you’ve made so far. There’s not always sufficient space to do this fully, so we tend to include just the last set of changes within the wireframes and keep a fuller record within a separate document. Wireframing tools to consider include Visio, Omnigraffle, Adobe Illustrator and Adobe InDesign.
Interactive prototypingInteractive prototypes are working simulations of a product. They take your task flows, sketches and wireframes into a 2D realm and enable you to consider the interaction behind components. Interactive prototyping is a process in itself. It enables you to test and revise the user interface, refining the user’s interaction with functionality and perfecting their experience as you iterate. For the first time, stakeholders start to see their product take shape.
As Garry Samett, head of digital content, Teachers TV, testifies: “When Super User Studio designed our registration process, having a ‘working’ prototype gave reassurance, especially to non-tech savvy stakeholders. They could see how it all worked early enough in the process to raise issues before coding had started. This saved us loads of time and pain.”
Not all projects will require interactive prototyping. If there’s limited interactivity, you may wish to produce interactive PDFs from your wireframes, but developing a full prototype is unlikely to be necessary. Interactive prototypes are useful for projects that involve either single or multiple areas of complex interactivity. They’re also useful when those areas of interactivity are particularly crucial to fulfilling business or user requirements.
For example, it’s difficult to truly think about the interactivity of a web application or social media site using static wireframes. One component of a page or screen could have multiple stages of interaction behind it, as could many other components on the same page or screen.
You could wireframe out each of these processes, but it won’t really give you sufficient clarity to consider how the interactions could be improved. For such projects, interactive prototypes will support your testing of the behaviour of the components and explore how the user’s experience can be enhanced.
Again, there are many tools you can use for interactive prototyping. Your choice of tool may depend on the complexity of the interaction involved and just how much interaction design you think the project warrants. At Super User Studio, we use Axure, as it can handle quite complex interactions such as mimicking Ajax functionality. It’s not as simple to use as Balsamiq, for example, nor does it have the nice interface of iPlotz, but it does enable you to produce a functional specification to accompany the interactive prototypes. While the users testing the product will not be concerned with functional specifications, your development team will be. The spec offered by Axure needs editing and formatting, but effectively brings together all the annotations you make while creating the interactive prototype. In our experience, annotations on interactive prototypes can be overlooked, so delivering a specification document often goes down well with developers and clients alike.
Your approach to interactive prototyping may be low-fidelity or high-fidelity. This will inevitably be dependent upon the project, its budget, timeline, complexity and so on. However, if you intend to test the prototypes with users, it’s important to allocate time to make them as user-friendly in their presentation as you can. Paying close attention to things such as grid structure, spacing, linking convention and typographical hierarchy will boost the user’s apprehension of the interactive prototype. More importantly, your users will spend less time querying elements of the interface that you’re simply not testing.
To support your development of interactive prototypes in Axure, check out the pattern libraries offered at www.axlib.org and acleandesign.com.
If there is one core insight we’d like to reflect upon in this tutorial, it’s how this entire process is about communication. By focusing on issues of interface and interaction design before visual design, you’re allowing yourself to focus on how the product can more effectively communicate its message to users. You’re focusing on opening up channels of communication with your client and the project team. You’re also inviting communication with users to better understand how the product can meet their requirements to craft the best possible user experience.
About the authorName Odette Colyer
Company Super User Studio
Site www.superuserstudio.com
Projects Teachers TV, The Guardian, BBC
What do you wish you were better at? Press-ups: no amount of chicken gives me enough strength to do them
One of the best written articles on prototyping that I've stumbled upon recently. Odette Colyer from Super User Studio lays out wireframing experiences from a very user centric perspective and why high-fidelity prototyping doesn't always makes sense.
What’s A Wireframe?
Wireframes and site maps are the tried and true tools of information architects and user experience designers. Wireframes represent a simple black and white, plain vanilla version of the proposed site. Each individual wireframe serves as a blueprint or schematic of a design template, and shows how navigation, content and images will all work together.
How Wireframes Are UsedWireframes are great for visual communication, solving design problems and building team consensus. People will understand what you’re trying to say better and faster with pictures. It helps them see how things are connected, whether or not something is missing and how changes to one thing may impact something else. An agency creative director once asked me what I found compelling about working in plain old black and white. With all due respect, I told her that what I love most about wireframes is they help teams focus clearly on content and functionality. Just the facts, ma’am. No graphic design – just placeholders for navigation, content, and notes on system behavior. Plus despite what she may think, it’s a very creative exercise.
From a timing and cost perspective, wireframes help designers work through a variety of site layouts before they commit a full team of resources to the project. This can save clients big bucks. Just like you wouldn’t build or renovate a house without a clear blueprint, you shouldn’t build or redesign a web site or web application without wireframes. But wireframes are only one step in a larger process of first understanding business goals, user needs and site requirements. Before you even touch a wireframe you need a clear understanding of what it is you want to build. And that’s what sketching is for.
In Information Architecture: Blueprints for the Web, Christina Wodtke and Austin Govella state “Information Architecture is good thinking written down”. More specifically, wireframes represent good team thinking written down. They simply cannot be done in a vacuum. So before you start cranking them out in your favorite software program, grab your sketchbook and get everyone involved in the project together, either on the phone or in person. People think visually and respond much faster to visual images. Capturing good team thinking into a visual diagram takes skill, patience and perseverance. The trick is to nail the requirements early on from all project stakeholders.
Good article on the wireframe process by Mary Shaw. Mary is also providing some hints and best practices for a successful concept workflow.
People swear by their design processes. Rachel Glaves insists on sketching by hand; Dan Brown urges extensive wireframing; while Ryan Singer goes straight to HTML. Heated debates arise at conferences as advocates staunchly defend their favorite techniques.
With all of these different methods to choose from, should you be sketching, wireframing, mocking-up, or prototyping? The answer, simply put, is yes you should.
Design methods are not mutually exclusive. Rather, each method exists on a continuum of fidelity, ranging from low fidelity sketches to high fidelity HTML prototypes. Each method is well-suited for a particular phase of the design process, with one level of fidelity often leading into the next.
The Design Funnel
In his book “Sketching User Experiences,” Bill Buxton portrays the design process as a cycle of elaboration and reduction. The goal of the elaboration phase is to generate as many different ideas as possible, while the reduction phase is meant to select one of those ideas and carefully refine it.
Laseau’s overlapping funnels (as portrayed in Sketching User Experiences) indicate the dual nature of design as elaboration followed by reduction.
Rinse and Repeat
While it does typify the design process as a whole, in practice the elaboration and reduction process must be continuously repeated time and again throughout the course of design. From information architecture, to visual design, to the functional prototype, each stage must be explored in full, then lovingly honed down to a precise solution.
The design funnel illustrates the repetition of the elaboration/reduction cycle from low fidelity to high fidelity, converging into the final concept (inspired by Stuart Pugh’s funnel).
From sketching to prototyping. From low to high fidelity. Informative article about the concept and design process of a webproject by Tyler Tate for UX Booth.
Wireframing and website prototyping tools allow you to take full control of your website architecture without hiring a web designer. You can build a faithful draft of what your website layout will look like without detailing color, graphics and specific design elements. In this MasterNewMedia guide you will find the best wireframing and website prototyping tools under $150 to start sketching out your site right away.
Photo credit: Yasuhisa HasegawaA website wireframe is defined by Wikipedia as such:
A website wireframe is a basic visual guide used in interface design to suggest the structure of a website and relationships between its pages. A webpage wireframe is a similar illustration of the layout of fundamental elements in the interface.Wireframes are a significant step in simplifying the design of your site, because a wirerame mockup allows you to reduce design rendering and production time while also freeing you time to focus on what is really important to have on your site.
Another remarkable advantage of wireframing and website prototyping tools is also that they are available in different price tags and flavors to fully adapt to your budget.
You can already find a guide published on MasterNewMedia on free wireframing tools and another one will be published in the next few weeks on top-notch wireframing software.
Instead, this very guide is devoted to all those publishers who want to get their hands dirty with wireframes for a reasonable price. In fact, here you will find a selection of website prototyping tools that cost under $150 per month (well below in most cases).
To help you select and identify the best wireframing solution for your specific needs, I have then compared and selected a number of tools (both web--based and software applications).
Here below, you will find an interactive mindmap and a set of comparative tables and mini-reviews to make your evaluation as simple as possible.
Here the criteria I have used for this comparison:
- Software type: Downloadable / web-based tool (if downloadable, the operating system supported is specified).
GUI symbol library: Free, readily-available buttons, scroll bars, menus and other objects to draw wireframes. Interactive wireframes: Clickable mockups that simulate the navigation between web pages. Real-time collaboration: Interaction with customers and collaborators and receive live feedback. Export formats: Supported formats to export wireframes projects. Starting price: First price level available.
Freshly compiled list of wireframing tools by Robin Good and Daniele Bazzano.
Communication Activist, Usability Geek,
Internet Enthusiast and iA Lover
How Wireframe Wednesday comes to life?
1. What?
Wireframe Wednesday is a blog tribute to wireframing and should function as some sort of archive for everything related to wireframing, prototyping, information architecture and usability. Everyone, who is interested can speak up and contribute!
2. Why?
There has been a real flooding of blog posts and articles on these topics recently, so we decided to found the Wireframe Wednesday site and gather all this valuable information in one place.
3. How?
Every article, snippet, video, podcast, screencast, review or other contribution to the topic of wireframes should be tagged with:
* #wiwe
* #wfwd
* #wireframewednesday
We will scan websites, blogs, Digg, Delicious, You Tube, Vimeo, Twitter...for valuable articles, repost them here and if possible, put a trackback to the sites of origin.
