Michael Gaigg: Über UI/UX Design


Windows 8 UX design guidelines

Posted by Michael Gaigg

The Windows 8 UX design guidelines are out. They are part of the Dev Center for Metro style apps and provide some nice learning resources that include

  • Design Principles - Understand the basic principles of great Metro style app design.
  • UX patterns - Learn how to correctly implement common patterns in Metro style apps like navigation, commanding, and touch interactions.
  • UX guidelines - Discover recommendations and requirements for building Metro style apps with the proper look, feel, and user-interaction model.
  • Downloading design assets - Get started designing apps quickly with a portfolio of reusable wireframes, redlines, fonts, and other useful design resources.
  • Assessing usability of apps - Assess your app's design to ensure the user experience is outstanding, and that users will find it useful, usable, and desirable.

New Year’s Resolution: Gift Books (don’t lend them)

Posted by Michael Gaigg

I used to have a rule (you know, a rule helps you solving a problem in your life that you then never have to worry about anymore) that said: never lend a book, always gift it!

I don’t know why or when I stopped applying this rule but my thinking behind it is:

  • You value the book but somebody else values it more at this time
  • Lending it will consume your energy remembering who you lent it to end when
  • The other person constantly feels bad for not returning the book to you up to a point when it becomes real guilt and shame
  • The other person cannot really enjoy the book in fear of marking a page or paragraph or leaving coffee stains

So the solution is: Gift the book! In that way both parties feel good.


Highlights for Week 50/2011

Posted by Michael Gaigg


Highlights for Week 48/2011

Posted by Michael Gaigg


Asking for Feedback

Posted by Michael Gaigg

Generally it's not a good idea to listen to your users; it's better to observe their behavior and actions. When you do ask for feedback though, be careful to not end up with a sack full of new requirements.

Some phrases (from the hilarious video) that I'm only too much familiar with:

  • I'm just throwing things out there
  • You are the author (designer), you know best
  • I am making sense, right?

from Asking for Feedback


Highlights for Week 47/2011

Posted by Michael Gaigg


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.


Happy 3rd Anniversary

Posted by Michael Gaigg

Another year has passed and I cannot tell you how much your feedback means to me: Thanks for sending me all these links, suggestions and ideas. This is what encourages me to keep going - I hope you enjoy it as much as I do :)

Just in case you have missed it, here are some highlights, my personal favorites and some good advise from the past year.

Highlights from last year

Personal Favorites

Good Advise (for free ;) )

Filed under: Good News 1 Comment

World Usability Day 2011

Posted by Michael Gaigg

Today is World Usability Day. Check out online events.

It's about making our world work better!

This is a reminder that we must develop technologies and experiences in a way that serves people first!

Lot's has been said about Steve Jobs and how he was an innovator and leader of easier to use software and hardware. I think he was just somebody that asked the right questions and had the power to translate them into consumer products (well, impressive enough I guess).

The questions we all should ask more often - and we cannot be afraid to ask over and over again if we didn't understand - are WHY and WHAT. Only after figuring these questions out we are able to design, improve and innovate the HOW.

With that: Happy Usability Day!

Page 5 of 23« First...34567...1020...Last »