Michael Gaigg: Über UI/UX Design

22Nov0

Wireframing as an Indicator for Problems in your Project Structure

Posted by Michael Gaigg

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.

19Dec0

Web Content Accessiblity Guidelines (WCAG) 2.0: Overview and Structure

Posted by Michael Gaigg

Overview

Last week the W3C announced the publishing of the Web Content Accessibility Guidelines (WCAG) 2.0 as a final Web Standard "W3C Recommendation". This is good news for many reasons:

  • Guidelines are more specific, e.g. specifying contrast ratio or time-based actions in seconds.
  • Success Criteria are written in a technology neutral fashion.
  • Success Criteria are written as testable statements.
  • Past killer arguments like "Javascript is forbidden" are now included as a technique to enhance accessiblity.
  • Gathering 'implementation experience' is now part of the W3C Process.
  • Guidelines include requirements related to informing users of data entry errors.
WCAG 2.0 Overview showing Principles, Guidelines, and Success Criteria (Level A, Level AA, Level AAA).

WCAG 2.0 Overview showing Principles, Guidelines, and Success Criteria (Level A, Level AA, Level AAA).

But what I personally like the best is the revamped structure called layers of guidance:

Structure

The four principles of Web accessibility: perceivable, operable, understandable, and robust.

The four principles of Web accessibility: perceivable, operable, understandable, and robust.

The WCAG 2.0 define a logical hierarchy of accessibility guidelines called layers of guidance. All of these layers work together to provide guidance on how to make content more accessible.

Principles

The foundation is built on four principles that are essential for anyone to access and use Web content, i.e. every Web content must be:

  1. Perceivable
  2. Operable
  3. Understandable
  4. Robust

These principles are the four pillars of Web accessibility and describe at a high level what can be done to assist users with varying needs to successfully access your content.

Guidelines

The 12 WCAG 2.0 Guidelines provide basic goals for creating accessible content.

The 12 WCAG 2.0 Guidelines provide basic goals for creating accessible content.

The 12 guidelines are basic goals that authors of Web content should work toward in order to create accessible content. None of them are testable and are only meant as a framework of overall objectives. The guidelines are:

  • 1.1 Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.
  • 1.2 Provide alternatives for time-based media.
  • 1.3 Create content that can be presented in different ways (for example simpler layout) without losing information or structure.
  • 1.4 Make it easier for users to see and hear content including separating foreground from background.
  • 2.1 Make all functionality available from a keyboard.
  • 2.2 Provide users enough time to read and use content.
  • 2.3 Do not design content in a way that is known to cause seizures.
  • 2.4 Provide ways to help users navigate, find content, and determine where they are.
  • 3.1 Make text content readable and understandable.
  • 3.2 Make Web pages appear and operate in predictable ways.
  • 3.3 Help users avoid and correct mistakes.
  • 4.1 Maximize compatibility with current and future user agents, including assistive technologies.

Success Criteria

WCAG 2.0 Success criteria shown in three column: column 1 (red) are Level A, column 2 (yellow) are Level AA, column 3 (green) are Level AAA.

WCAG 2.0 Success criteria shown in three column: column 1 (red) are Level A, column 2 (yellow) are Level AA, column 3 (green) are Level AAA.

Now, the success criteria is where the meat is. For each Guideline, testable success criteria are provided. Every Web content or series of Web content (complete web page or series of connected pages) can be tested and evaluated against these criteria and further assigned a true/false (equals pass or fail) value.
These success criteria are further divided into three levels of conformance, meaning satisfying all the requirements of a given standard, guideline or specification:

  • Level A (lowest; minimum level of conformance)
  • Level AA
  • Level AAA (highest)

The notion of conformance is so important that I will discuss it in a separate blog entry.

Sufficient and Advisory Techniques

Up until now all the principles, guidelines, and success criteria are written in a technology neutral fashion. That's great but what now? The Working Group has identified and published examples for HTML implementations that should serve as examples and tutorials and are kept in the living document called Techniques for WCAG 2.0. This document explains a variety of techniques on how to implement the given guideline for each success criteria. The list is not complete and will be expanded as new techniques are discovered.

The techniques fall into two categories:

  • Sufficient techniques: considered to be sufficient to meet a success criteria.
  • Advisory techniques: enhance accessibility, but did not qualify as sufficient techniques.

Most Success Criteria have multiple sufficient techniques listed. Any of the listed sufficient techniques can be used to meet the Success Criterion. Also there may be other techniques which are not documented by the working group that could also meet the Success Criterion. This is especially true for content that is not HTML.

Resume & Criticism

I'm really excited about the WCAG 2.0, their clear structure and promising, almost marketing-like wording. I also like the amount of effort taken to document examples, techniques and common failures.
What I miss is the programmer perspective that outlines each element with its associated success criteria and code samples, e.g. how can I make tables accessible, what about links, captcha, maps, etc.? I think this work is up to us and I will continue to tackle this issue by grouping, summarizing and compiling elements so I can publish them on this blog.

What are your opinions on WCAG 2.0?