Michael Gaigg: Über UI/UX Design

11Feb0

Download: User-centered Design Menu

Posted by Michael Gaigg

User-centered Design Menu

User-centered Design Menu

Welcome back!

This time I literally have a special treat for you: the User-centered Design (UCD) menu. It's like a menu that your clients can choose from and range from inexpensive ($) to rather expensive ($$$$).

Tip: Please digest slowly and most importantly: ENJOY!

Download: UCD Menu (PDF)

Entrees

Every Proposal is the entrance to something great.

Paper Prototyping $$

Hand-drafted mockups and sketches, carefully selected and laid out, sautéed with your ideas.

UX Storyboarding $

A portion of your end-users and their needs
topped with their stories and actual problems.

Heuristic Evaluation $

Draft designs, wireframes or fully implemented systems
evaluated by a choice of 2-3 hand-picked experts.

Survey $

Freshly picked set of questions, sliced to identify
your users and their needs, served with lots of insights.

Main Courses

Let us delight your users with our house specialties.

Rapid Prototyping $$$

Lightly functional demos or prototypes,
served in high or low fidelity, grilled to perfection.

Usability Testing $$$

Home-made end-user observations that feed
right into the next design iteration, served by 3-5 users.

Focus Group $$$

Choice of nutritional opinions and beliefs,
shared and discussed by a group of people.

Field Study $$$$

Real end-user behavior observations collected by
following people in their daily job and environment.

Card Sorting $$$

Delicious index cards sprinkled with individual
concepts, tossed into meaningful piles, served hot.

Server Log & Search Log Analysis $$

Crisp log statistics piled high with insights of
user’s navigation and search behavior. Very tasty!

Chef’s recommendation:

Make the User a stakeholder!
Involving the user early and throughout the cooking process will improve the experience and usability of your app and save you and your client money.

18% gratuity added to projects of 250k or more.

Please ask your server for the recommended selection of user-centered design methods that suits your project.

7May0

Video: Map App UI Design

Posted by Michael Gaigg

Here is the video from the tech session I held at the Esri DevSummit 2013 in Palm Springs, CA.

The session teaches participants best practices for reviewing, conceptualizing, designing and building user-centered mapping applications in a competitive business environment. Methods, techniques and tools for improving the user experience and designing useful and appealing front-end interfaces will be discussed.

26Apr0

Top 10 Design Influencers

Posted by Michael Gaigg

Design Influencers

Design Influencers

Designing user interfaces isn't about sexy graphics, shiny buttons or slick navigation (alone).

It's about taking care of the influential factors that make or break the success of a web application or website.

It's a delicate balance of user needs and business requirements, deeply understood and carefully melted into a design that is loved by all stakeholders (the end-user included 😉 )

The sum of all the design influencers are the constraints that will box your design decisions. That's not a limitation, it's liberation!

The Design Influencers are:

User Needs

Whatever it is that you are planning to build, it needs to be useful to somebody and has to solve a real-world problem. This end-user need is the reason of existence, it's the meaning life.

Context

In which context will your users access the site? Is it through mobile devices on the road? Then a shopping cart will be less important than driving directions or store hours and screen elements need to be more prominent.
Do users typically enter your site through search? Then your landing pages need to convey who you are and what you do because users won't have seen your fancy homepage (and probably never will).

Culture

Even though cultural difference across the globe become really important if you build an international site, I rather mean business or sociological culture, i.e. if you plan on building an intranet site but the company's culture doesn't encourage to report failure or spending time helping other employees, then a forum probably isn't the right choice to offer.

Business Needs

While your client is ideally well informed about their end-user's needs, they also have to run a business, satisfy stakeholders, fulfill legal mandates etc. And that's when compromising your perfect usability is sometimes necessary and important.

Technology

What's the available technology? Very often the vendor or client platform of choice dictates the choice of technology, e.g. a Microsoft shop will prefer .NET and Silverlight (oh, long time I haven't mentioned Silverlight so I mention it again) or Flex.

Market Opportunities

If something isn't viable or possible today that doesn't mean it won't be in a year. So think ahead and design your site accordingly, i.e. extensible, modular, maintainable.
What I've found is that sometimes it's worth including an "upsale" item into your mockups, something that the client hasn't explicitly asked for but may open their eyes and hopefully wallets 😉 Mostly you may defer these items to a later phase but it gives everybody a long-term vision and as a side-effect supports designs that are extensible.

Cost

It's been said that anything can be done if you only have enough time and money, but the real world doesn't spin like that. Your design is constrained by a budget - and that's a good thing because it forces you to stay realistic finding the right balance between innovation and familiarity.

Sponsor

If the main sponsor is Esri (my current employer) I better make sure that there is a map on the interface. What sounds like a designer's nightmare is the name of the game.

Lifespan

How long will your design need to stand the test of time? Is it 1 year or 10? A demo doesn't need to be as polished or thought-out as a content-management system that will take over the client's communication platform. It is the classical "let's get it done" versus "let's think about this a last time". I've written a more detailed article about Lifespan as an important Design Decision.

Compliancy

Accessibility is a law and therefore cannot be removed from the equation. Your fancy design elements might just not be (or too expensive to be) compliant with the law. Acquire knowledge about accessibility laws (e.g. section 508 in the US), their implementation specifics and know how that translates into your design.

26Oct0

Stop the Rotating Banner Sliders

Posted by Michael Gaigg

Stop

Stop

I'm not a big fan of the (auto-)rotating banner carousels but I have never been really able to articulate why. So I looked beyond my personal taste horizon and found two excellent points of view by my colleagues Neal Dinoff and Art Zippel.

Analytics

Neal Dinoff (Esri Marketing Analytics Manger) offers some quantitative insights:

Most people visit a website with a specific objective. They scan the homepage for any link they believe will get them closer to accomplishing their objective. Few stay on a homepage long enough to view a slideshow. Using the CrazyEgg analysis of click timing on the Esri.com homepage, the majority of visitors click a homepage link within 5 seconds. Our homepage slides rotate every 7 seconds. That means most visitors to Esri.com never see the second and third slide in rotation. At a conference I recently attended, IBM’s web metrics analyst confirmed their site had the same problem.

and Neal continues talking about organizational motivations of including carousels and explains that

Organizations like homepage slideshows because it's a way of placating everyone who desperately believes their special interest deserves/requires homepage presence. From the user's perspective, they are generally worthless. They don't solve a user problem or meet a user need. Homepage slideshows are usually the opposite of user-centered design.

User-centered Design

Arthur Zippel recently shared an article with a video (5 minutes) talking about how typefaces directly affect readability. As a result Art started looking at autorotating banners from the behavioral side and whether similar effects would apply and add to distraction and overall loss of comprehension:

Because my primary focus here at Esri is the website I'm curious if there is any correlation with the findings in their very specific study and comprehension. We know that website visitors scan content when they are on a web page even when they are on a desktop with no fear of crashing their chair into their coffee cup or being pulled over by the office texting police. We know that distractions play a large role in attention, and that attention plays a large role in comprehension. I think autorotation banners make it more difficult for users to focus on page content because they create a distraction away from page content.

Knowing this, it is worth considering that if, one of the primary reasons for autorotation banners are a desire to manage minimal screen real estate, then is it the most effective solution? From a user-experience perspective, it think the widespread use of autorotation banners is interesting. Based on specific content on a page (link) a user indicates a desire to see additional specific content only to be presented with a distraction (autorotation banner), this doesn't seem like a completely successful experience. And with Halloween coming up, might I say it could even border on diabolical and horrific 😉 Remember, this is an intentional action on the point of those who manage websites.

I am constantly reminded that a widespread, common, popular practice by very large companies has absolutely no intrinsic correlation to UCD best practices. If you believe that companies always conduct valid testing for what they put on a website and that what they deploy is transferable to all other companies and their goals, then I have a bridge for sale.

Solutions

  • Build a meaningful site structure and navigation architecture.
  • Provide relevant headers and content.
  • Use and show links that speak to the user's intention for visiting the site.
  • Spare the huge banner images in favor of smaller, more focused teaser pics.
  • Avoid thinking in organizational terms aka we need to satisfy manager XYZ and put up a nice banner image about his cause.
  • Stop thinking about what could be interesting to your users but rather identify the context in which your target audience looks for something on your page and how they arrived (through search engine, direct mailing, etc.)

Tim Ash offers even more reasons: Rotating Banners? Just Say No!

What are your Thoughts/Experiences?

10Jul0

Lifespan is an important Design Decision

Posted by Michael Gaigg

Mayan mahem

Mayan mahem

The lifespan of a planned application or website is an important (and often overlooked) requirements influencer. Many questions come to mind that appear to be technical in nature but have to be understood by the designer to optimize their design decisions on capabilities and known limitations of the target technology. Designs can never truly be technology agnostic and in my opinion if they are, then this fact will create gaps between design and implementation later on. So you better be aware of them.

Typical Questions to ask:

  • Will the app be likely be superseded by something else within the next 6 months?
  • Is another known technology catching up and soon more prominent than our current target technology?
  • Do we rely on third-party tools/plugins that need to be maintained or maybe will render our application unmaintainable?

Especially the last question bares high risk of failure. If you rely on a JavaScript's front-end framework - like we all do - say, jQuery UI, chances are that our designs will a) be limited and b) sometime be stuck in the middle once a major redesign hits us. If the redesign happens before the end of the planned/anticipated lifespan of our app, cost and effort to upgrade might not be feasible and thus we cannot upgrade to the latest versions anymore. The End.

Scalability

Amount for various cases where your design needs to be flexible enough to handle changes over time. These can include:

  • Administration: more objects (users, items) are added over time. Does the app provide pagination? Search? How easy can they be plugged in?
  • Load: processing times increase. How will the system display delays in page refreshes? Download times?
  • Client requests: more functionality needs to be added. Is the design flexible enough to accommodate another button or menu item? Etc.
  • i18n: multi-language support needed? Now? Later? Maybe?
  • Accessibility: is it worth the effort?
  • Support for MVP (minimal viable product) and incremental improvements?

In many ways the Maya calendar and it's associated 2012 phenomenon are a good example for design decisions based on lifespan. Who cared back then that after 5125 years the calendar would need to be reset (or cannot handle more combinations), like many software systems didn't take into consideration what is now known as the Y2K or Millennium bug which was caused by the practice of abbreviating a four-digit year to two digits for pure storage consideration, which nowadays in our abundance world of storage is really hard to follow. But hey, it costed an estimated remediatioin of $416.- in today's currency world-wide.

Lesson

Take into consideration the lifespan of your app when designing it. Any negligence is careless design and may result in increased cost or even an unmaintainable or unusable product later on.

What are your experiences with lifespan?

19Mar0

The 4 Questions of Strategy

Posted by Michael Gaigg

4 steps of strategy

Just described 'strategy' to a consultant and thought to share my awesome whiteboard drawing 😉

The 4 questions of defining strategy are:

  1. Where am I now?
  2. Where do I want to go?
  3. How do I get there?
  4. How do I define success?

The success criteria is crucial. It's the metric for any decision you need to take along the way, it will help you determine which design is 'better'.

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.

10Nov0

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!

27Jul0

Save the Users [Video]

Posted by Michael Gaigg

1000's of designers are standing by to assist you... LOL

Thanks to Frank for pointing me to this video link.

Tagged as: , No Comments
12Apr0

Implications of the Inability of Users to Search Effectively

Posted by Michael Gaigg

Jakob Nielsen outlines in his latest alertbox newsletter (http://www.useit.com/alertbox/search-skills.html) the inability of users to search effectively.

Findings

My colleague Neal Dinoff, Esri Usability Lab Manager, summarized the article and outlined Jakob Nielsen's core findings:

  • People (even highly educated people) have remarkably poor search skills.
  • Once they head down a keyword path, no matter how fruitless, they seldom change their search strategy
  • Users will enter search terms into any open text field with no understanding of whether they are searching the whole site, the World Wide Web, or only a discreet section of the site.
  • Users are overconfident in the reliability of results.
  • Almost no one uses Advanced Search. When they do, they use it incorrectly.

Lessons

Neal continues to conclude lessons for our search design:

  • Don't assume that advanced search will help your website; you might build such features, but people will use them only in exceptional cases.
  • Spend the vast majority of your resources on improving regular search (simple search).
  • Design for the way the world is, not the way we wish it were. This means accepting search dominance, and trying to help users with poor research skills.

Implications

I believe more implications can be deducted:

  • Curate (make sense of) content (!!!):
    • Aggregate (most relevant in one location)
    • Distill (more simplistic)
    • Elevate (identify and describe trends/insights)
    • Mashup (create new points of view based on multiple sources)
  • Every page is a potential landing page, so help user to:
    • Locate themselves (titles)
    • Provide context (the bigger picture)
    • Find the content/functions they were originally looking for
    • Navigate further (well thought-through navigation architecture + good links + meaningful footer links)
  • Create pages so that they can be found through:
    • Search Engine Optimization (metatags, headings, etc.)
    • Write in the language of your users, that’s how they will search

What are your Experiences?

Page 1 of 3123