Michael Gaigg: Über UI/UX Design

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?

28Nov0

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

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.

1Aug0

Highlights of Week 30/2011

Posted by Michael Gaigg

30Jun0

Job Posting: User Interface (UI) Engineer at ESRI

Posted by Michael Gaigg

We are actively looking for a full-time User Interface (UI) Engineer here in Professional Services (Applications Development Services) at ESRI.

If you feel qualified and are interested please send me your resume to mgaigg at esri dot com. I'm also happy to answer any kind of question (except payment) you might have.

My job here

A little bit about what you can expect here: In my daily job I consult, design and help implementing customized web applications that are for the most part based on our core mapping products and API's for JavaScript, Flex and Silverlight. Clients range from local and federal government to vertical markets like energy, water, environmental, etc. and reach local, domestic and international audiences - the challenges are never-ending, I promise 😉 You can become part of this group!

Job Description

Use your technical background and innovative visual design skills to simplify complex business processes through the creation of intuitive and visually engaging user interfaces.

Responsibilities

  • Create sophisticated, imaginative, efficient, and visually striking interfaces for front-end solutions
  • Design reusable UI components by utilizing or building UI framework components
  • Develop storyboards, mock-ups, and prototypes to communicate ideas for navigation and interaction models
  • Evaluate requirements and initial mock-ups; make technology recommendations that support optimal construction, maintenance, and performance
  • Translate complex functional and technical requirements into detailed architecture and design prototypes
  • Ensure cross-browser/platform integrity of Web designs
  • Work closely with software developers and software testers to create a working end-to-end solution
  • Define, maintain, implement, and enforce style guides, standards, reusable templates, and best practices for client-side software development
  • Leverage the latest developments in Internet technologies
  • Serve as a technical resource and mentor

Requirements

  • Bachelor’s or master’s in computer science, graphic design, visual design, human factors engineering, interaction design, information architecture, or other relevant field
  • A minimum of five years of experience in user interface design, information architecture, user-centered design methodology, and implementation in complex enterprise environments
  • Significant and proven experience demonstrating innovative UI visual design skills
  • Ability to balance designs with the understanding of technical constraints within a software development environment
  • Highly proficient with cross-browser/platform CSS, HTML, XHTML, and JavaScript; knowledge of browser compatibility issues and their workarounds
  • Extensive experience using JavaScript libraries such as Dojo and jQuery
  • Good understanding of user experience (UX) and user-centered design (UCD)
  • Ability to take a concept from sketch to final implementation
  • Ability and willingness to take ownership of projects and help drive them to effective implementation
  • Exceptional attention to detail, organizational, communication, and presentation skills
  • Passionate about novel user interface design and software development

Recommended Qualifications

  • Experience with GIS/ESRI products and solutions
  • Experience with .NET, C#, Silverlight, and Expression Blend
  • Experience with JSP, Java Web frameworks, Flash, and ActionScript
  • Experience with Linux, PHP, and MySQL
  • Proficiency with Adobe Creative Suite including InDesign, Photoshop, and Illustrator
  • Ability to interface with customers, gather requirements, and implement new solutions

Employment Fraction

Full-time

Work Location

ESRI Headquarters, Redlands, CA

22Jan0

Highlights of Week 03/2010

Posted by Michael Gaigg

Suggested reading:
9Nov0

User-Centered Design (UCD) Methods: Comparison and Overview

Posted by Michael Gaigg

This is the first in a series of blogs describing User-centered Design Methods. My goal is to summarize my experience, insights and findings across multiple literature and compile them into easy and quick to digest pieces for you to consume. I want to encourage you to comment your own experiences and give me feedback on why your company applies certain methods differently or not at all or something else altogether.

I personally don't like the term Usability too much, it's an empty buzz word. It means SOMETHING to everybody but isn't scientific enough to be taken serious. It's often interpreted wrongly and purely misunderstood by most. It's kinda like Psychology, we know it is important to understand fundamental human behavior, their problems and remedies, but I wouldn't pay a dime to go to a Psychologist. But who knows, just as Psychology got its scientific relevance and acknowledgment - partly maybe through the 'invention' of the IQ - hopefully Usability rises up to similar levels (Jeff Sauro offers interesting metrics via SUM (Single Usability Metric).

That's why I like the term User-centered Design. It works wonders with Project Managers and the-like, probably because Design is such an important term in their daily work. And when asked about Usability testing I can conveniently point out that this is only one tool of many in my UCD toolbox. But the really important sales trick is to know which UCD method is best used at what time in the project management cycle.

The following chart compares the most common user-centered design methods, outlines their cost and shows when to use them:

Overview of user-centered design methods

Comparison of User-centerd Design (UCD) Methods
Method Cost Output Sample Size When to Use
Competitive Studies Medium Stat. & Non-Stat. 5 Requirements
Focus Groups High Non-Statistical 6-9 Requirements
Field Studies High Non-Statistical 2-3 Requirements
Heuristic Evaluation Low Statistical 2-3 Design
Paper Prototyping Medium Stat. & Non-Stat. 5 Design
Card Sorting High Statistical 15-20 Design
Participatory Design Low Non-Statistical n/a Design
User Testing Medium Stat. & Non-Stat. 5 Design & Evaluation
Surveys Low Statistical 20+ Requirements & Evaluation
Interviews High Non-Statistical 3-5 Requirements & Evaluation
Server Traffic Log Analysis Low Statistical n/a Evaluation
Search Log Analysis Low Statistical n/a Evaluation

Not long ago, after having completed a full project management cycle (requirements, design, implementation and evaluation) the PM proudly announced to perform a Focus Group with his stakeholders. Showing the ready application, he thought, would surely impress them and lead to valuable feedback for the next milestone. This impulse isn't uncommon but has to be fought before it becomes reality. Does he really want to produce MORE and EXPENSIVE requirements? Because that's the output of Focus Groups. Wouldn't he be better off running 2 iterations of User Testing to reveal usability issues or a Survey to receive input from outside the development environment?

Recommendations

  • Requirements:
    • Competitive Studies
    • Interviews
    • Field Studies
  • Design:
    • Heuristic Evaluation
    • Paper Prototyping
    • User Testing
  • Evaluation:
    • Surveys
    • Server Traffic Log Analysis
    • Search Log Analysis
    • User Testing
  • The Usability effort is NOT proportional to the size of the project. Bigger projects spend less percentage on UCD with same effort. Regardless, as a rule of thumb assign 10% of the projects budget for UCD.
  • Faster iterations of prototype design require less testers

References