Michael Gaigg: Über UI/UX Design

30Sep0

Integrating Prototyping Into Your Projects

Posted by Michael Gaigg

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.
Prototyping in the context of your project

Figure 1: Prototyping in the context of your project.

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:

  1. Low-fidelity prototyping (paper / digital sketch)

    1. Create paper prototypes or digital sketches
    2. Design navigation architecture (workflow)
      1. Review with client
      2. User testing (optional)
      3. Iterate (until happy)
      4. Revise into 2
  2. Medium-fidelity prototyping (simple HTML)

    1. Simple HTML prototyping (maybe even black and white)
    2. Proof basic workflow and important interactions
      1. Review with client
      2. Iterate
      3. Revise into 3
  3. High-fidelity prototyping (Enhanced HTML)
    1. Enhance HTML prototype (links and basic functionality)
    2. Settle on design (including corporate design, basic artwork)
      1. Review with client
      2. Iterate
      3. Revise into 4
  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?

28Aug0

Presentation: Wiki – the right tool for my organization?

Posted by Michael Gaigg

Finally I got my head around posting a presentation I gave last March. The title is "Wiki - the right tool for my organization?" and had the purpose of introducing the concept of a wiki to a group that was about to install a wiki within their department.

Background: About three years ago I went through the effort of evaluating existing wiki platforms, installing/hosting it for our department and keeping it alive for the next two years before it got sacked. I'm here to tell you why it didn't work out in the end.

Characteristics

I jump right into the characteristics (the slide "Characteristics" is duplicated in the presentation on purpose) because I found understanding them key to a successful implementation. That's why once more I want to emphasize on the issues that need to be met in order to successfully implement a wiki, for example if your company has no culture of sharing content or employees are reluctant to give up ownership of their code, a wiki is most likely not the ideal collaboration tool.

These are the characteristics of a wiki:

  • Perpetual work in progress
  • No one owns the content
  • No specific organization (hyperlinks)
  • Anyone can edit other people’s work
  • Discussion area for each page
  • Version control: list of all changes made to a page

Critical Success Factors (aka truth about a wiki)

Only implement a wiki if you feel comfortable you can meet the following critical success factors:

  • Only 10% contribute; only 1% on a regular basis.
  • Obey the characteristics of a wiki
  • Power to the people
    • Trust the user
    • Authority to change something
    • Refuse defined structures

My previous experience taught me that implementing a wiki into your organization is doomed to fail if one is not aware of their importance and therefore

  • overestimates the reach and participation,
  • neglects the characteristics of a wiki,
  • or doesn't want or cannot give power to the people.

The truth is, only 10% of users contribute to a wiki and only 1% on a regular basis. If you have 100 employees you can expect between 1 to 10 of them to contribute and the rest to consume - which in turn will lead to lesser contribution and lesser consumption over time. Wikipedia works well because there are millions of users where 1% is still significant number to keep up quality content.
The argument of mandatory (or even monitored) participation runs directly against the characteristics of a wiki, is counter-productive and will result in your wiki failing.

Choosing a wiki: What to consider

Obviously there are many criteria and features that will directly affect your choice. I recommend Comparison of wiki software as a starting point for finding the right software but I wouldn't be surprised if you ended up with MediaWiki which is the used by wikipedia for one simple reason (besides its free usage under the GPL license and its huge community): the MediaWiki syntax is widely used and makes actually sense to learn - because it is wikipedia 😉

Criteria

  • Cost (open source license)
  • Programming language (PHP, C#, Java)
  • Data backend (File system or DB)
  • Extensibility & user community

Features

  • WYSIWYG editing & Syntax
  • Version control & Discussions
  • Permissions & Security

Keys to get a wiki going

Once you've decided to go ahead and install a wiki, what can be done to make it successful?

  • Find dedicated helpers
  • Partner with groups/people related to your mission
  • Offer structural templates for new pages
  • Add some content to major categories
  • Do lots of marketing
  • If possible, offer training

Do you work with wikis?

What are your experiences? Do you use a wiki in your company? How do you use it?

10Dec0

Design Guidelines: Breadcrumbs

Posted by Michael Gaigg

Hansel and Gretel using breadcrumbs to find their way home.

Hansel and Gretel using breadcrumbs to find their way home.

Nobody wants to get eaten by a wicked witch and neither do Hansel and Gretel in the tale Hänsel und Gretel by the Brothers Grimm. That's why the kids, as they are taken into the forest, leave little breadcrumbs behind so they can find their way home. I love the story (especially when the witch climbs into the oven to be baked) and the fact that Hansel and Gretel find their way home and see that the evil stepmother has died and everybody can live happily ever after.

Even though the metaphor of Hansel and Gretel is probably the origin of the term Breadcrumbs it is flawed because breadcrumbs do not represent the actual path the user has taken to any given page, but instead the optimal path from the homepage to the current page in the hierarchy.

Fairytale aside, here is how Breadcrumbs should be designed and implemented:

Design Guidelines for Breadcrumbs

  1. Display breadcrumbs horizontally
  2. Progress from the highest level to the lowest, one step at a time
  3. Start with the homepage and end with the current page
  4. Apply a simple text link for each level (except the current page)
  5. Separator between levels is simple and one-character (usually “>”)
  6. Levels show the site hierarchy – not the user’s history

Code Sample / Template

End result:
Example Breadcrumbs

<div class="breadcrumbs">
<a href="#">Home</a>
<span>></spanv
<a href="#">Topic</a>
<span>></span>
<a href="#">Sub Topic</a>
<span>></span>
<strong>Node</strong>
</div>


div.breadcrumbs {
background: url(bg-breadcrumb.png);
overflow: hidden;
margin: 0;
padding: 0;
height: 2.8em;
line-height: 2.8em;
color: #666;
}
div.breadcrumbs a, div.breadcrumbs strong, div.breadcrumbs span {
float: left;
overflow: hidden;
height: 2.8em;
padding: 0 1em;
font-style: normal;
}
div.breadcrumbs span {
background: url(bg-breadcrumb-arrow.png) no-repeat left center;
overflow: hidden;
padding: 0 0 0 1em;
width: 0px;
filter: alpha(opacity=40);
opacity: 0.4;
}

download bg-breadcrumb.png | download bg-breadcrumb-arrow.png

References