Wireframing as an Indicator for Problems in your Project Structure
Usually I recommend 2 rounds of wireframes (more rounds are ok during proposals).
If you still cannot move on after 3 rounds of wireframes this is typically a good indicator that your project has some sort of underlying problem that you should detect and address right now.
Typical Problem Areas
From my observation problems can arise in many different forms. The simple identification of such is half the rent to address them (and I will leave the resolution up to you here).
No real user need
Every project should have been initiated by a user need. Many times that isn't the case and that is when it becomes difficult to defend a design to new requests, just because pretty much everything sounds like a great idea. So how can one
- measure the usefulness of the overall site?
- accept/deny new ideas or requirements?
- define the importance of requirements and their conceptual representation?
- design the visual hierarchy without clear or shifting priorities?
That's tough, it's like going fishing without campfire. Educated guesses are more important and also difficult than ever. Define a story that follows a vision that makes sense.
Too many cooks in the kitchen
Is there a sense that every time you step into a design meeting the wind has changed 180 degrees? Indicators for a deeper problem are when the team cannot settle on a wireframe because of
- conflicting opinions
- never-ending subjective feedback
- scope creep
- YADRN (yet another design review needed)
- executive seagull effect
- design by committee
Try to make the best out if by asking lots of questions, a little evangelizing, prioritizing feedback, and plenty of skilled design balance.
Poorly defined requirements
Every requirement should serve the purpose of the site, i.e. the user need(s) that drive the vision and right of existence of the endeavor. Maybe your requirements need refinement because they are
- too vague
- missing a definition of WHY they are needed
- defined by committee rather than thoughtful (and curated) selection
Mockups will help you identify missing requirements or surface items that don't make sense anymore in the big picture.
Undecided project manager
Decisions have to be made, priorities have to be set, deadlines need to be met, requirements satisfied. Somebody has to sail the ship and make decisions. You know the project has a managerial problem when design decisions cannot be taken because of
- new requirements popping up like mushrooms
- another 360 (as the wind blows)
- lack of authority given to the designer
Find somebody that can make executive decisions or make the decision for yourself (I know, nobody likes to piss off their PM, but pick your battles).
Problematic client
Issues with the client aren't uncommon, and not always is the client the problem, but certainly some clients can be more challenging than others. Find ways to finalize your designs and move on when
- requests about the HOW increase
- nitpicking increases
- conceptual designs are dissected to the dot on the i
- changing their mind on a daily basis
Go back to the roots, ask questions about WHAT and WHY you are doing this. Ask specifically what you can do to finalize any given slide, let them tell you and move on.
Missing domain knowledge
Not everybody can be a subject matter expert, but somebody has to and this somebody needs to be available to clarify and consult. You know you are missing a SME when the mockups
- tell an incomplete story
- can't hold up to critical questions
- an actual expert doesn't understand the mockups
Involve domain experts early, listen to their advise and take it seriously.
Bad designer
Last but not least, the problem could be the designer himself. Sometimes the designer didn't have the time to get his head around the complexity of the project, he or she is
- missing the holistic view of the system
- is missing crucial information to design well
- is facing impediments that weren't solved in time
- got hung up on a failed design and didn't want to start over
- fell in love with a design and can't let go
- is purely not capable of designing/communicating well
Have peer-reviews, offer a mental break, mentor the designer in his/her creative blockage or inability to get their head around the subject. Create a culture of failure where it is ok to accept a u-turn and throw away a design in favor of a potentially better one.
Your Experiences?
I would love to hear about your experiences and especially how you resolved any issues.
Highlights of Week 30/2011
- How To Create a Slick Features Table in HTML & CSS (by Chris Spooner) - very slick
- 10 Absentee UX Features on Top e-Commerce Sites (by Paul Bryan) - co-shopping? en espanol?
- 6 tips to create better one-page websites (by Kendra Gaines)
- 10 Unmissable TED Videos For Designers (by Alvaris Falcon) - love TED, and you should too
- 20 jQuery Tutorials Teaching Super Cool Visual Effects (by Chris Spooner) - that's why you must love jQuery
- Requirements-Driven Software Development Must Die (by Fred Beecher) - nice approach with really good arguments, but with any workflow it seems just a little bit off
- 70+ Awesome Tumblr themes (by Cameron Chapman) - got tumblr? get a theme - and a life
...and follow me on tumblr - Examples of Sites where localStorage should or is being used (by Chris Coyier) - localStorage is to HTML5 what isolated storage is to Silverlight
- jQuery plugin: Chosen (by Harvest) - go check it out, nothing else to say
- Freelance Web Development: 9 Tips for Better Project Management (by Kelli Shaver) - you do freelance work? enhance your productivity with these tips, very nice!
Highlights of Week 08/2010
Wow, what a week with truly amazing content which once more shows me how many talented and dedicated people are on the web. Thanks all for sharing your knowledge!!
- Vancouver Olympics Web sites are inaccessible to disabled people (by Joe Clark) - hope at least the website of the Special Olympics will be... Joe, wanna check?
- The Comprehensive Guide to Saving Images for the Web (by Joshua Johnson) - now this I call an essential read!
- E-Commerce Design Resources: The Ultimate Round-Up (by Cameron Chapman) - now this I call ultimate read!
- Life, Below 600px (by Paddy Donnelly) - or, "giving the fold the finger".
- Information Gathering: a Roundup of UX Applications (by James Costa) - James reviews 4 really useful UX applications. Great overview!
- 14 Questions To Ask Your Clients Before and After a Project (by Joel Reyes) - always good to be reminded of the basics.
- Design considerations for article lists (by Anders Toxboe) - Do's and don'ts of article lists are essential knowledge for every designer. Get a hang of it.
- 10 Essential Chrome Extensions for Web Developers (by Samuel Axon) - Firebug Lite, IE Tab, Resolution test and others, a must-see.
- Best Practices for Hints and Validation in Web Forms (by Kean Richmond) - Users hate forms but they are the only way to interact with an application so you better invest some more thought as did Kean.
- The Anatomy of Web Design (by Nishant Kothary) - "Smarter hires, more resources, more time, fewer managers, rational stakeholders, less overhead, stronger leadership, and sensible project management are intrinsic to creating great designs—but they cannot take the place of a strong mission and sense of purpose."
Integrating Prototyping Into Your Projects
This article was inspired by Integrating Prototyping Into Your Design Process - Using appropriate fidelity for the situation by Fred Beecher which I extend by the following:
Prototyping needs to be iterative throughout the project!
Goal of Prototyping
Prototyping is not only a design tool but a research and communication tool as well.
- It should assist in optimizing the main task (top tasks) and validating its/their efficiency.
- Furthermore this should not add cost to the project but reduce project expenses while increasing ROI.
So the goal is to use different levels of prototype fidelity to incrementally identify and enhance the user's task(s).
Ideally this happens linear (increase visual fidelity as you add functional fidelity) but typically it is bent to either side (see Figure 1) where more emphasize on
- visual fidelity can be beneficial for marketing purposes or
- functional fidelity can assist earlier user feedback trough user testing.
Integration into your project
Regardless of the project approach you take it will boil down into the fundamental project management phases of Requirements, Design, Implementation (and possibly others). Prototyping should not be solely perceived as a method useful during Design, it is essential during all 3 (or more) phases starting as early as Requirements phase.
I suggest the following approach:
-
Low-fidelity prototyping (paper / digital sketch)
- Create paper prototypes or digital sketches
- Design navigation architecture (workflow)
- Review with client
- User testing (optional)
- Iterate (until happy)
- Revise into 2
-
Medium-fidelity prototyping (simple HTML)
- Simple HTML prototyping (maybe even black and white)
- Proof basic workflow and important interactions
- Review with client
- Iterate
- Revise into 3
- High-fidelity prototyping (Enhanced HTML)
- Enhance HTML prototype (links and basic functionality)
- Settle on design (including corporate design, basic artwork)
- Review with client
- Iterate
- Revise into 4
- Start 'real' implementation
Implementation Effort
Each prototype (digital sketch, simple HTML, advanced HTML based on simple) should not take more than 40 hours of pure development (not calculating initial meetings and communication and possible variations based on project size) plus 80 hours reviews and iterating with client. Sounds impossible? Think twice. It is so much easier to modify a sketch than programming HTML. The 'real' implementation will be built upon a solid code foundation with a grown-up design already - voila!
Can I skip a prototype?
Yes, obviously you can. But it comes with a cost later on because you miss crucial information from the earlier phase and it is more expensive to implement modifications.
Technical considerations
The argument I hear most often is that 'prototypes' are wasted time/money because they get trashed anyway. This is absolutely not true! Identifying problems early almost always saves money later on, you don't find anything out until you start showing it to people, enhancing the quality of the product will help money flow into your pocket once deployed and most important, prototypes don't necessarily need to and should not be trashed.
Low fidelity prototypes can be more than just ‘paper’, this could be digital wireframes that look like sketches, e.g. Microsoft offers software that tie sketches (SketchFlow) directly into UI design (Expression Blend) and subsequently into development (Visual Studio) - check out the WebsiteSpark Program for almost free licenses.
Don't bend too much!
Danger! Don't bend the curve from Figure 1 too much otherwise you end up with
- a highly functional 'prototype' but without design, i.e. without visual clues whether your client/users will like it (buy it) and without validation that you got your information architecture right OR
- a highly visual 'prototype' that looks sharp, sexy and slick but cannot be used and lack usability ("we just installed the app and now our users complain they [...]" - substitute the appropriate phrase for yourself
Proof-of-concept
Creating medium- to high-fidelity prototypes can be considered proof-of-concept and can be beneficial to or sometimes even required by your project. Looking at Figure 1 that would mean to move their respective dots from Design/Implementation to an earlier phase.
What are your experiences?
Do you use / re-use multiple prototypes within your projects? Do your project structures support prototyping? To which extent?




