The future of wireframes?
I have a love hate relationship with wireframes. In the last 10 years they’ve been a part of every web project I’ve worked on. There have been times when I can’t imagine how we would have solved a particular problem without them. Yet there are also times when I’ve been completely exasperated at the amount of time and energy they’ve consumed, seemingly to very little reward.
This frustration has forced me to change the way that I approach wireframes. And as my approach has changed, I’ve been able to extract more and more value from black key lines and grey boxes…
From functional to visual
10 years ago the first wireframes I used were about as functional as you can get – a long list of page elements: static text, dynamic text, input text, radio button and so on. They were universally awful. About the only concession to help people understand how the page worked was to group common functionality into individual tables.
The wireframes were functional rather than visual as they were used to describe how the page should be built. Certainly, when you consider the screen from a developer’s perspective a list of different functional elements is probably quite logical.
However, from a user experience point of view this was a killer. Functional wireframes are incredibly difficult to read – the method of presentation gets in the way of being able to translate the information into a real screen, especially at the review stage.
Looking at this image it seems obvious that wireframes should be visual, however, IA was in it’s infancy ten years ago. Everything was new.
Wireframes also took a long time to produce. Changes to one wireframe often meant updating countless others. Change to the global nav? Certainly. Just one moment whilst I update 120 wireframes with that one.
Understandably, this hampered attempts to create wireframes that more closely represented real life screens. To help get around this, when they did become visual, they also become modular.
The modular approach to wireframes also reflects the reality of building sites. Functionality and snippets of code are built once and then reused over and over again. So why not create wireframes in the same way?
Visual wireframes also started to break down a belief that information architecture can be considered in isolation to information design. The information is the interface. How can the two possibly be separated? Join them together and you start creating wireframes that can be read and understood by everyone on the team, including the client.
Of course, this can raise the problem of clients expecting the final screens to be identical to the visual wireframes. “In the wireframes the submit button is on the right of the drop down, but in the designs it’s below. Why?” This requires careful client management, but it can be largely avoided if the wireframes concentrate on getting the ideas and thinking across, rather than just laying out a page.
Once wireframes are created using information design as a technique rather than just a visual conceit, they can be used to explain how a site will be experienced by the end user. In the example above the different colours represent different areas of content, targeted at different types of users. The client and the team can then get inside the screen and understand how it works and what the priorities are. It’s a very different world from 1999 – a list of functional elements that only be read by the one person – the author of the original wireframe.
As wireframes have evolved, the methods behind creating them have changed too.
Fail fast
Several years ago I can remember working on projects where the wireframes felt as if there were merely a documentation or cataloguing tool. The object was to create as many wireframes as possible, of every screen in the entire site, in big, monolithic and hugely detailed chunks. Rather than exploring different approaches to the information and structure of the site, the emphasis became entirely focused on using all of the time available to build a collection of wireframes, regardless of whether they were the right wireframes.
At Made by Many we practice a very iterative and rapid approach to wireframes. We create the smallest number of wireframes to explore a concept before stopping and reviewing. Does the idea hold up? If so, add on another layer of information and see whether it still stands. If it doesn’t, change direction and explore another route.
As we start off by only doing enough to prove the idea (and no more), the cost of change is so small that you can very easily change direction without having lost time or money. Ideas are allowed to grow or fail fast.
Explore interactions, don’t just specify software
For many years the primary role of wireframes was to specify software. We now use wireframes to investigate and explore how people will interact with a site. Using a ‘just enough’ approach, we often create a series of simple interactive prototypes to try out a variety of approaches to solving a problem. These prototypes can be made in HTML or they can be as simple as a series of Keynote slide for someone to click through.
This is a very different approach to wireframing. Rather than simply documenting where a link goes, the goal is to model and start experiencing what moving around a site feels like as quickly as possible. The prototype can then be tested and the results used to iteratively improve the end solution.
Of course, sites still need to be specified, but wireframes aren’t always the right tool for doing this.
Nobody likes reading wireframes
No matter how much love and attention is poured into a wireframe, they’re cast aside as soon the screens have been designed. Nobody likes reading wireframes, especially when there’s a picture available.
I’ve yet to meet a developer who would choose to build a screen from a wireframe over a Photoshop document, regardless of how many helpful and important details the wireframes may contain. Realizing this is human nature, we now annotating our PSDs rather than wireframes. Why hold the information in a document that’s no one wants to read?
The best before date keeps getting shorter
For a long time wireframes were seen as one a project’s major deliverables. The client was paying for them as part of an agency’s ‘set piece’ best practice. Because of this they were constantly updated throughout the life span of a project, regardless of whether they actually needed to be. I’ve seen perverse instances where a set of wireframes have been updated after the site has been designed, merely to ensure that the wireframes match the finished site. Why update a document that’s never going to be used again?
As more projects are developed using agile methodologies, where the working software is the spec rather than a set of documents, the useful working life of a wireframe is getting shorter and shorter.
The right approach
In a previous life at a big ‘old style’ new media agency, there often seemed to be a one tool fits all approach to projects. This applied to information architecture too – there was a set way of creating and delivering wireframes, regardless of the individual needs of the client.
In contrast, we’re now lucky to have a wide range of tools and techniques that allow us to approach a problem from the best angle. A sketch, a grey wireframe or a full on keynote prototype. These tools allow us to develop a solution in iterations, slowly adding on more detail as the solution becomes closer to a design that can be built.
Whilst there’s a natural progression from sketch to a detailed wireframe, it’s important to never feel constrained by the life cycle of a project. A sketch can be done at any time (and by anyone), regardless of where you are in the process.
Wireframes aren’t the keystone
In the same way that the guild of stonemasons kept the secret of building arches to themselves, wireframes shouldn’t be the preserve of a select group of information architects. As wireframes have become more visual (and more useful) the number of people able to contribute to their development has increased. This isn’t just a list of designers and developers, it’s also clients and business analysts who are becoming more and more involved with the process.
We often involve all of these people in collaborative sessions around a whiteboard to gradually ‘build’ the interface of a site. It’s a different way of working that involves people in a very different way to help create a better service. It’s also a way of working that’s slowly demystifying information architecture, changing the way that we interact with it and, ultimately, who creates it.
The designer as information architect
As wireframes have developed the role and skill set of information architects have developed too. The most effective wireframes are now created by people who can see how a site fits together as a series of connected interactions. Who see the information as the interface, and understand that these two can’t be separated but yet can be affected by time and place.
The more that I appreciate these skills, the more that I believe that wireframes can (and should) be created by designers.
The best sites are those where there’s a seamless divide between the look, the content and the experience. Being able to model an interaction and understand how someone moves through a site are crucial skills in this trilogy. It’s time designers stepped up to the plate and claimed wireframes as their own.
55 comments
Awesome post. I was looking for some information like that this past week. Thank you :)
Great article. I am developing a wireframing tool and posts like this help a lot to see the user’s perspective.
Nice article. I’ve been trying to promote that an IA/UX person and the Designer should collaborate early akin to art director and copywriter in advertising. Collaborate on a solution, have the designer create the main visuals, and the IA can compliment it with annotation, functional specs, and detailed wireframe breakouts for navigation, interaction, user flow, etc. Usually I find they want to work in an 1-2 step, wireframes as a deliverable to both clients and designers.
Great article Isaac. We share a similar perspective on the ideal use of wireframes.
I’d be interested in getting your feedback on our online collaborative wireframing tool ProtoShare. It’s designed to facilitate sharing, collaboration, and many of the workflows that you describe. For example, getting the designers, clients, etc. involved early so they can collaborate on the evolution of your interactive wireframes and design work.
If I set up an account (no software to download) for you would you be willing to take a look and let me know your thoughts?
Fantastic. We’ve run in to just about all of these issues with wireframes. Really helpful.
Thanks for all the great feedback and comments.
@Chris Absolutely. I think that’s one point that I didn’t stress enough – the best wireframes are nearly always the result of collaboration between different skill sets (both as part of the review process and crucially at the idea generation phase too).
@Josh Thanks, I’d definitely be interested to take a look. I’m on twitter @bobbyc if you want to send me a direct message with an account.
Thanks for the post — it tackles some issues I’ve been turning over and over in my mind for some time. It is interesting for me to see how Made By Many is thinking about design. Over the past year I have gone from the world of the interactive agency to mission-critical client-server software and have been learning through trial-and-error which web app design techniques from my toolkit translate to the world of OS-tethered programs. Thanks for your perspective on sussing out interactivity via diagramming. I’d love to read an even deeper exploration of methods from you.
Isn’t one of the aims of wireframes to prevent having to create full designs and focus on the functionality?
Clients prefer photoshoped designs but if they have those the biggest danger is they focus on the details fo the design, not what the site does. Also creating wireframes are supposed to be quick compared to ‘shopping up pages.
You’ll also still need to illustrate how things work unless you can build a annotated prototype.
This was a great introduction to the (albeit short) history of wireframes over the past decade, as well as your personal insight into the best approach going forward.
I really appreciate thoughtful posts like this, which add new thought to the IxD space. Thanks.
A problem with wireframes is that they are too precise for the early stages of design. There’s a fair bit of research on the value of sketching: it is not that designers can get by without detail at the first stages but that too much detail actively gets in the way. There are parallels in other areas of creativity: the mathematician Jacques Hadamard, in ‘On the Psychology of Invention in the Field of Mathematics’, notes how eminent mathematicians typically begin their speculations through visual images which in his words are ‘vague enough to lead me without misleading me’.
Another problem is that wireframes tend to constrain the designer’s imagination to particular rectilinear layouts. The ideal would be a real sketch tool that was quick, looked provisional, and could be built up with more detail as the design progressed.
When she was at Apple in 1992 Yin Yin Wong wrote a nice paper: ‘Rough and ready prototypes: lessons from graphic design’ (http://portal.acm.org/citation.cfm?id=1125094)
http://portal.acm.org/citation.cfm?id=1125094
Fantastic post. Thanks!
I`m torn.
While I understand the point and gist of this article, and while I understand the need and desire to convey a more holistic picture to the team and clients so that they may receive a better interpreted vision, I think that the purpose of wireframes, which is depict function, navigation and information is the very strength of the wireframes without the flesh on the bones.
I find that although clients want to see pretty picture and have their senses tantalized by design, it is too distracting from the main point which is to highlight form and value add by way of the bare minimum.
If we can accomplish this task by bringing value to our clients with only the bare minimum, not only are we being successful with our wireframes, but how much more happy will our cients be when they see the bigger, designed picture with a true understanding of what went into it in the first place.
I still believe there is more value by speaking on the frames to give clients the full understanding of what it is that we`re doing, and then giving them the aesthetic prototype as a follow up.
I do however agree that in several cases, wireframes can truly be a waste of time.
Interesting insight into the history of wireframing, especially for those of us that haven’t lived it. :-)
Nevertheless, I personally see a great interest lately in clickable wireframes. The line between sketches, wireframes and prototypes is getting thiner and thiner. Depending on the current needs, people build paper prototypes that users finger click on, digital prototypes in dedicated tools or non-standard tools, and of course coded prototypes.
It would be nice to think about how much is the need driving the tools or the other way around. For me, prototyping in PowerPoint is a sign that people have a need but don’t have a proper tool to fill that need.
This is mainly one of the reasons why I decided to build this prototyping tool called FlairBuilder. It basically lets you create highly interactive wireframes and prototypes. You can achieve the same level of interactivity as with coded prototypes but all in a non-coding fashion.
If you’d like to give it quick try, there is an online demo available at http://flairbuilder.com/demo
http://flairbuilder.com/demo
Thanks once again for your great blog post. Definitely a pleasant reading!
Cheers,
Cristian
Great article! Thanks for sharing your thoughts. You are a good writer.
“Who see the information as the interface, and understand that these two can’t be separated but yet can be affected by time and place.”
This quote reminds me of my my own work: http://www.designmolecule.com
http://www.designmolecule.com
As someone who is both a Designer and an IA, I find the red and blue circle diagram strange. I feel like I have watched the opposite happen since I first started working in the area of IA back in 1996, its first infancy.
Thanks for a great post!
I share Stewart’s comment, arguing that my wireframes communicate a specific function: hierachy and structure relative to it’s adjacent elements?
Clients can quite easily fall into the ‘final version’ mindset. If it’s clear where page elements will be placed and structured then we can progress with prototypes and designs?
Are you suggesting changing wireframing as we know it to ‘protoframes’?
In the early days of web development, when designers were the complete owners and the ones responsible for the outcome and performance of websites/ web applications, Information architecture and Usability ( +User Models, testing etc.) were in their nacent stages.
However, when websites started failing to deliver messages they were supposed to, started to repel users and most importantly had no participation from the end-user, it was ascertained that the whole development of the end product should go through a wireframe preparation(prototyping?) and then development.
This kind of a process would not only give the client/developers a chance of reviewing the possibilities/limitations of the proposed layout (to the designers) but also give the client a chance to choose amongst or question things in what the designer proposed.
However, as this came into practice, it was realized that this kind of a process has a huge cost and not everyone can manage it, and so, small companies who were low on funds shirked the idea of such a lengthy process and followed certain conventions to boil down to certain common layouts (a.k.a Templates) which were shown to the more than impressed client, one of them approved and converted to the actual page.
What the above resulted in, was that most of the sites looked the same and user had little or no recall value for a site that he visited.
Web designers/ usability specialists have a major role to play in today’s era as a lot of the web is user-interaction intensive and requires to be not only visually appealing to the user but also to be easily understood in order to be used properly and preferred over emerging competitors everyday.
Simply put, prototyping and wireframing as a tool is a great advantage to developers and designers as a team where iterative development to web-based applications (Agile method of development) is followed and this is slowly taking over as the most popular technique too, as it is beneficial to almost everyone related to the site; the developers, the Client and the end- users.
Great post. I’ve seen wireframes migrate from being more about the ‘wire’ — just sketches — to being more and more refined and used far beyond their use-by date, as you say.
In my experience, clients really like hand-drawn wireframes. There’s something designer-y and attractive about them, and they feel like they can be more involved in the creative process, rather than being presented with something that looks refined and already ‘locked in’.
So I go with hand-drawn first, capturing all the main ideas and ‘will-it-fly’ tests, then progress to more finished Visio drawings… but not too finished!
I’m about to let go altogether, and go straight to online prototyping – it’s the way of the future.
Hey Isaac,
Great post, I just wish I could get some of that through to the agency I’m at at the moment. Constantly updating wireframes throughout the development process without revision notes. Sometimes updating to reflect changes in requirements sometimes to match the development. What’s most frustrating about that is that I have to re-read the things in their entirety to find the changes for myself.
I guess all the above debate about Online or paper, functional/non-functional prototypes will end once softwares like Axure find their way to most of the coders and programmers.
Also, one thing I feel many are waiting for is Adobe Catalyst. It is being expected to be one of the best proto-typing tools for photoshop designers. Converting layers and groups to functional objects, providing a complete an clean (great) preview of the behavior of the app.
Fingers crossed..
Feel free to check out iplotz.com, which goes a long way to help in creating a navigable wireframe prototype, with coillaboration and task management features built in as well.
@Cristian Pascu Re your comment “For me, prototyping in PowerPoint is a sign that people have a need but don’t have a proper tool to fill that need.”
The irony of PowerPoint is that it’s actually better at doing wireframes / clickable prototypes than presentations. And if you’re a mac user you should really be using Keynote. A superb modeling tool that’s rapid, low-fidelity but has ‘just enough’ polish and creates lightweight files for printing and sharing.
Isaac,
This is a fantastic post, and I’ve forwarded the link to the the iD team with some comments:
It questions the status-quo and presents some truly original thinking and alternatives that all have a very client-centric approach. I’m not saying that this is necessarily what would be needed internally to deliver a project, but externally (and for pitches, in particular) I can really see the value.
I’m drawn to the idea of annotating mock-ups/designs in order to show what does what. I’m sure this would be especially useful in situations where clients don’t really understand what wireframes are.
Acknowledging that flexibility is critical to delivering a client-centric piece of work. The ability to use a variety of techniques (not always saying “this is a wireframe, and it is what you get”) is certain to impress.
Again, very well done.
This helps our industry be better.
@iboy
I have found Powerpoint / Keynote occasionally useful to demonstrate quick interactions, but for large scale work it should be avoided.
The door is still open (though being pushed by things such as Axure) for a tool that helps us create modular, interactive ‘wireframes’.
This needs to facilitate collaboration between those that create the structure, those who fill it with stuff, and those who are actually going to use it.
Great post, Isaac. I felt a shiver down my spine looking back at those LSE wireframes. I don’t think they were useful for anyone – client, designers or developers.
I wish I could get people to understand the “don’t update something you;re not going to use any more” maxim. It’s so simple, but so much time gets wasted on spurious accuracy like that.
Brilliant post Isaac, have read it twice just to make sure I took it all in.
Personally, I’m forever struggling with the utility of wireframes and the level of fidelity required. I guess it depends on who they are aimed at, the type of client, designer, developer, etc.
I also know from bitter experience that clients will often sign off functionality on a wireframe only to come back and change said functionality when they are presented with the visual designs later in the process. Sadly this seems to happen all too often, regardless of the fidelity of the wireframes. Traditionally wireframes were viewed as less precious and therefore more likely to invite change, whereas the visual design was seen as more precious and fixed. It seems this trend may be reversing.
I don’t think the wireframe is dead just yet, but certainly the days of static wireframes as a sole representation for a website or product are numbered. More materials are needed to truly represent the interactions, copy, visual hierarchy and functionality.
I would disagree with Higgs on the usefulness of the LSE wireframes, but sadly we never really got as far as seeing them through the entire process. Then again, I am biased :-)
Cheers Isaac, great post…
Fantastic post! I have to say it was not only enlighting to read about the history of wireframes from a web perspective, but also encouraging to evaluate the relevance those same approaches have in other non-web environments.
In my opinion, both Design and IA are modality agnostic, so learning from the web’s past and from how those techniques are being used in other mediums help identify where other modalities might be and where they might be heading in the future (embedded devices, speech/gesture recognition, touchscreens, mind control, etc.)
There’s a whole number of different arguments here about what wireframes are for but Isaac’s fundamental point is that you need the right kind of wireframe for the right purpose. Who are they meant to inform? How do they help the designer reach a solution?
I’ve just spent the afternoon listening to Isaac present a few dozen wireframes to a design and development team (all done in keynote, btw). Isaac created them firstly to identify how interactions worked in detail for a site with enormous complexity contained in just three key screens/pages with dynamic states; and secondly to enable the developers to refine their estimates for user stories for the first four iterations of an agile project. They were not for client sign off (although the client’s part of the team and was in the meeting). The client signs off on the look and feel and the finished software, not on the wireframes and that’s one reason we don’t have to keep updating them unnecessarily.
These were not the first or only wireframes made on this project. As Gillian says, wireframes encourage a designer to go into too much detail too early on. That’s absolutely the case and I’ve seen many so-called information architects and implementation designers painstakingly defining detailed functionality and content before they’ve thought through how the big interactions work and how you give meaning to the transitions within a user journey.
At MxM we use really quick, simple Keynote click-throughs to model flows and transitions between activities, content and brands/providers. We create user journeys involving key interactions to explain our vision for a site, and what we call sketch wireframes (actually painstakingly hand-drawn but apparently rough) to help clients understand how that vision might look as a web page. These precede detail wireframes; they are the equivalent of classic sketch models, sections and plans.
Agile has been one big driver for changing design practice; the other has been the move from a web of static pages to a web of tools and dynamic content. This has at last taken design out of the hands of librarians and logicians and put it back into the hands of designers who can think in terms of three dimensions (x, y and time), create mental models that represent systems to users usefully and put some love and energy into the experience.
Really great article. Very timely – I’ve been using much more visual / functional wireframes to walk the customer through a process and spot any gaps in the workflow / forms. Even used actual text rather than lorem ipsum’ing it. Given how little time the customer has, they’ve appreciated the amount of thought put into it now (from customer perspective, low/med/high fidelity buildup can seem like you didn’t think through it at the low fidelity stage) and ability to review in one meeting vs. reviewing low/med/high fidelity wireframes. They’ve been able to give us much more thoughtful feedback than if it had lorem ipsum and general blocks. We’ve set expectations by clarifying that these are just sketches and we want feedback before we build, as well as showing things in black and white. So far so good.
Great post Isaac!
Really enjoyed reading through it.
When it comes to wireframes there aren’t really a correct/incorrect way of making them. As long as we remember that they are design document which need to be used as a communication tool then we usually end up with the right results.
Unfortunately it seems that there are no standards for wireframes or for the software used to design them. I’m optimistic that this might change in the next 2-3 years, however, everyone seems to be making wireframes using their ‘own style’ nowadays we might end up goingin the wrong direction!
Either, great post! Looking forward to the next one
“The more that I appreciate these skills, the more that I believe that wireframes can (and should) be created by designers.” wireframing is aobut designing… so yes it must be done by designers… Now it depends what you mean by “designers”. If it’s graphic designers I do not agree with you. It should not only be created by designers.
- Design serves (most of the time) business, it’s important that business analysts defined the earliest wireframes/business rules of the interface to be sure that the product will respect the busines plan
- On the other hand WF that will help implementing the development should definitly be done by graphic designers.
Wireframing is a process that involve different parties in the product cycle.
Interesting article but I’ve been listening to too many podcasts and reading too many articles recently w/ this idea that wireframing is a dieing art and that designers should be able to handle this.
In my 10 years as an IA I have met very few if not any graphic designers that have the patience or the desire to think about all the permutations, usability issues, strategic needs, etc of interaction design. I agree that graphic designers should place more focus on these things but they simply don’t want to and IMO shouldn’t have to. This is where wireframing comes into the picture.
I agree though that way too much time is wasted on wireframing and sometimes just seen as a billable deliverable. New software(apps), ideas, and research need to be done to produce a more efficient and effective final product.
The old thinking is that client’s get confused by them and only want to see pretty pictures, I just don’t buy it. This was true 5 years ago when the client was not as in touch as they are now w/ web dev projects. It creates a sense of comfort that we have done our due diligence in capturing everything and we have put thought into every single page on the site.
Iteration creative design is just too expensive as well as clients focus solely on how it looks and not on how it functions.
IA’s need to become better at designing and designers need to become more about function but until that time long live wireframes.
You’re right Chris, most graphic designers don’t have the skills or the inclination to understand interaction design.
However, the ability to be able to understand the usability and strategic needs of interaction design is a vital part of being a web designer.
There’s a key difference between the two: graphic designers who focus on the look and feel, and web designers who see the site as a complete picture balancing the needs of the business, the brand and the user.
My sincerest regrets if you’ve only had an opportunity to work with the former and not the latter!
Here is related research, which demonstrates that realistic prototyping is detrimental to usefulness/usability of final product.
“Naive Realism: Misplaced Faith in Realistic Displays,” by Harvey Smallman and Mark St John.
citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.85.4519&rep=rep1&type=pdf
Enjoy, Oleh Kovalchuke
Hello Isaac,
[rant]
The future of wireframes is the following:
1) They are becoming and will continue to evolve into rapid prototyping tools
2) They will become more and more integrated into software development methodologies and documentation.
3) They will become more standardized similar to the diagrams produced by architecture and engineering firms.
Axure and MindManager Pro are examples of these trends above.
I completely disagree with you regarding designers stepping up to the plate and claiming wireframes as their own. Any black-turtlenecked, navel-gazing, Coldplay-listening graphic designer who tries to tell me that they “own” the wireframes is going to get cold-cocked.
IA’s are essential because they understand (or they should) design language and understand (or they should) development language. They are also an advocate for the user. A good IA understands what an ampersand is, knows how Ajax or Drupal works, and constantly reminds everyone that the user just wants to be able to order something in half-sizes.
And what are wireframes? Everyone needs to get off their high horse and realize that wireframes may be essential but they are also absolutely disposable. They are the paper instructions in an Airfix plastic model kit or the blueprints for an architecture or a subdivision plan. They are schematics that help the designers, developers, writers, producers and the client all figure out exactly what we are building and how we are going to built it.
The exploring interactions process that you describe sounds incredibly labor intensive and expensive.
We’d all love to design the next-generation can opener, paper clip or build a better mouse trap. But it’s an attitude that does little but add churn to projects and add expense to clients.
For example – ecommerce functionality. After 10-odd years of internet development, there are well-established trends, interaction patterns and best practices to ecommerce. There is no need to redesign the shopping cart experience. Unless your client is Amazon, and your project’s got a budget in the millions, it’s not worth it. Use the best off the shelf solution you can find.
The fact that more and more companies are turning to CMS software and other packaged solutions such as WordpPress for their web development needs illustrates that Information Architecture/Interaction Design as a practice badly lags behind software development paradigms.
In software, it’s all about modular development, standardized platforms, protocols and efficiency. But us IA/UX people are still engaging in “how many angel’s can dance on the tip of a wireframe” debates. We as a practice can’t decide on a standard size/style etc. for wireframes, and seemingly will build them in and software program that tickles our fancy (OmnigraffleIllustratorInDesignPhotoshopPowerPointVisioAxure)
It is absolutely silly for me as an IA to have to create wireframes from scratch for developing a SharePoint site. I should be able to just grab a SharePoint shapes collection in Visio and start plugging in modules. And those modules are exactly the same as any other IA working with SharePoint would use. And all our documents are standardized so that they can be read from one agency to another without having to guess what some IA/UX’s idiosyncratic box and arrow doodles meant.
Personally, I’d like to see IA/UX establish standards similar to the International Building Code or the ISO. It’s about time our industry grew up and adopted some.
[/rant]
- Rob Fitzgibbon
Great post, sums up a lot of useful thoughts :)
I’ve met many graphic designers and information architects, who for one reason or another avoid each others skill areas like the plague.
It’s great to see this changing, I met a Grad Student doing Interaction Design from Berkley this year, I was really impressed at both the critical thinking, and graphic design ability.
The next generation of interaction designers are such an amazing hybrid, they’re gonna blow our minds!
I would have really liked your approach on what tools you use to create wireframes – I stepped away from visio a few years ago and actually wireframe in flash or html.
This allows the wireframes to show interaction and can throw up all those little feedback points (loading screens, data entry) you might have missed.
Also regarding ‘traditional’ wireframes – I have never ever given a box layout to a designer and got boxes back – this is why they are designers- they take all the functional requirements and twist it their way – if your getting ‘designed’ wireframes back then you frankly need better educated designers.
What tool do you suggest to create quick visual wire frames?
I love the tip on annotating PSDs. Great way to preserve flow of QA downstream.
“this is why they are designers- they take all the functional requirements and twist it their way – if your getting ‘designed’ wireframes back then you frankly need better educated designers.”
no doubt with it
Great article!
We have combined a great list on wireframing tools available. Hope it will help everyone make the best choice in less time! http://ciohappyhour.com/ultimate-wireframing-toolbox/
http://ciohappyhour.com/ultimate-wireframing-toolbox/
really great post, thanks
Great article.
As someone who has moved in an organization where decisions take time and changes have to be discussed with a lot of people, the value of wire-frames in the design and decision making process can not be underestimated. It allows for forward movement of projects before you start fighting over the design details.
Cheers for the tip on using presentation software to mock up the wire-frames, thinking this will save a lot of time in showing interaction and user paths.
I think for future, most gonna need ajax/javascript, load a site in a time and access all the content directly on one page…
i used to make a lot of lo-fi wireframes when doing IA for clients, but found – as you suggested – that they often had a hard time fully understanding the concepts i was trying to communicate. i recently started doing copywriting for some of these same types of people and now submit copy recommendations and drafts in full-color mockups based off of the existing site templates. i’ve found that the clients are much more receptive (and enthused) when they see the copy flowed and integrated in a realistic way.
and now that google docs supports wireframing, i think you’ll see clients, writers and designers getting preliminary concepts fleshed out much more quickly.
Isaac, I think the purpose of IA is lost on you. When you are combining design and IA you get page mockups. For a simple website, page mockups are the site. But assuming we are talking about a website that does more than provide static information, then page mockups are just as important, I agree.
But, IA serves a purpose that cannot be or better not forced to be achieved by page mockups. IA shows positioning of information/data relative to the page and relative to each other and how their layout serves the maximum benefit for the business, while also serving any non-functional requirements such as legal, accessibility etc.
Where I worked with IA, they also served to show the ad placement that conforms to requirements, while making maximum use of real estate without interfering with other information presented on the page.
IA needs to be clean, showing clearly marked real estates, with dimensions and data to be presented within that area. Nothing more or less. Adding colour to it, is useful for the designers but not so much for the engineers.
This site becomes a lots of information nice site also good dear keep it up.
Great topic and discussion.
I’d like to add that since the iterations in the software development process (and web-design/development) shortens the client expect some results much sooner. And a wireframe-prototype is a tangible result that gives all parties an understanding of what is going to be delivered (not an exact version, but an understanding). In a rapid development (like Scrum) this wireframe-prototype serves as a visual requirements “document” that could be easily understood by the client and the developers (doesn’t matter what technology they use later), which a great benefit, since nobody wants to write one or has the time.
Also there is an additional benefit of the prototype side. Sometimes the client needs to convey the idea to investors or someone else he reports to. And the visual and interactive prototype gives him the right tool to do so. In my experience the wireframe-prototype helped to identify a lot of small requirements (and settle on ideas) in much shorter timeframe than it would be through some plain documents or even mockups of the screens.
Though it will not be the right tool for all projects, especially of a smaller size.
Roman
Wow, this really is an extensive amount of information. Hard getting my head around it. Cheers for putting all of that together for us.
The next step for a IA is to be able to do user test with high fidelity prototypes without the need of a programmer. I use http://www.justinmind.com and it works great for me.
http://www.justinmind.com
Very nice article.
We are working on a product to ease the wireframing.
Thanks for this post! Fantastic!
Interesting post – I am bookmarking this straight away.
Thanks
Thanks for informing me about this wireframe issues and the recommendations on it. I used to have wireframes but often I have a problem with them but while reading your article, it seems that you have a good suggestion on how to deal in such an issue for a wireframe.
Very well written. Informative and interesting as well. Well visualized and presented. Do stay in touch and keep posting.
Set your own life time more simple get the mortgage loans and everything you want.