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).
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.
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.
I would love to hear about your experiences and especially how you resolved any issues.
This talk was given by Des Traynor at the MIX 2011 and is a must-see for anybody deciding to implement a dashboard or even designing one. It explains the goals of data visualization and the benefits for the business.
While the original talk is about infographics I named this article Dashboard Design because this was my big take-away and I see you guys applying this knowledge mostly to dashboards as well.
Know your Audience
For which role is the dashboard designed for?
Typical roles are:
- strategic view
- focus on long term
- high-level overview
- simple summary
- query driven analysis
- precision required
- emphasis on trends
- emphasis on correlations
- Operations & Logistics
- focus on current status
- issue & event driven
- are things ok?
Know your Domain
What is the area (domain) of your audience?
Domains could be
- Customer/technical Support
What are you trying to answer? Which questions are important?
- Percent change?
- # sales?
Know your Data
Communicate single figure
- context is obvious
- precision is required
- past & future is irrelevant to the user
Can have different states (red, green,...)
Single figure with context
Use to ask:
- How are we doing lately?
- Any problems on the horizon?
Sparklines help (trend up or down?)
Analysis of a period
Use to show:
- ...all the key moments of this month
Line chart needs lots of data points to be good, but then they are really good!
Analysis of a period versus target
Use to ask:
- Did we hit our sales figures?
- Are we fulfilling our quota?
- Is performance ok?
Actual versus target chart; focus on delta! Use bar chart.
Breakdown of a variable
Use to ask:
- What age groups are buying our stuff?
- What countries are we big in?
Pie chart becomes bad when too many entries; sorted bar chart is better; avoid decorating with colors.
Breakdown over time
Use to ask:
- How has the composition changed over the last year?
Line chart is good; stacked bar chart is really difficult to read.
Know your Visuals
Visuals are broken down into two categories: Quantity and Category.
- Lines (length, width), that's the best
- Color intensity (shades of red,...)
- Speed (only useful in motion charts)
- Line type (dashed, dotted,...)
- Color (red, blue, green,...)
- Shape (triangle, rectangle,...)
- Location (map)
Know your Style
Remove the junk (= stuff that doesn't change, e.g. gradients, noise,...). There is no reason to fight for impact, this is not a shiny print population, it's a dashboard.
The process of designing a dashboard should follow these rules (in order of importance):
- They have to say something and be meaningful
- Dashboards & Visuals evolve, i.e. a lot of data is necessary to make sense
- Start with the basics: Rows from the database
- Add insight as you need it: Sorting, comparison,...
- Add a yearly view only after a year has passed 😉
- Include insights and actions
- Consider adding projections