Well it’s day 3. And day 2 was a blur as it tends to be. Day 3 starts a little later with my frist session being on UX Tools. I’m curious to see what they will  cover in regards to new quick UX tool technology. While I wait and since there is no one around to talk to directly I figured I would share a little bit about what some of the planned events are today.

I plan on making it over to Nokia and trying out the new Lumia 900. I’m curious to see how this windows phone 7 device performs and why I may switch from the ever present IPHONE to this new device (pending on hands on today.).

Now out of my head and let’s see what techniques are illustrated…

Soucy – Usable Iterface

Rosenstien – Salesforce

summers – Paypal

 

 Focus Group:

• Formality doesn’t have to be a necessity
• You don’t have to be hidden
• Group can happen at any time ( I like the guerrilla usability approach)
• Individual assignments can be made

 

Site Study / Field Research

• Essentially ethnographic, in person research, immersion in the world.

Eye Tracking 

Baseline cost is extremely high 10-20k for a machine (3k rental) – this is from a previous conversation I have had. Used with other research methods I think it would be sweet.

Unmoderated Testing

A boatload of tools in this field. I’ve tried a few, but still prefer to do quick Guerilla usability testing due to REAL world time constraints. This is all about Practical & Rapid UX.

High Fidelity Prototypes

Everything looks great on paper
Iterative testing can’t teach you flow.

 

My Conclusion Based Upon My Experience

So I wanted to add my two cents into some of the usability testing research methods above.

No matter which technique you use, the best UX person uses the right tool for the right job. You may need to use high fidelity prototyping for business sign off. You may want to build more interactive prototypes (I recommend this if you are have a lot of behavioral interaction). You might not have a huge budget so testing tools like eye tracking and field research are not going to be cost effective. In the end it is better to do something than nothing.

A lot of times people ask me what I do for testing? I prefer a mix of in person, field research, prototyping, rapid iteration, and task based questioning. I love springing a new interface on an unaware tester. Controlling what the task is you are trying to test though is the key to getting “real” feedback instead of generalized.

You want to look for patterns in your testing techniques and see where overlap in results happen. This gives you some power and validity to the decisions you have made, or may need to change. Knowing what technique to use when and why is what experience helps you determine. You just need to jump in and get building. Throw out the methods that work for you and always try new techniques.

Remember as a User Experience designer technology changes fast. We constantly have to update our skills and knowledge and not necessarily blanket testing with old methods. New interfaces and new designs are going to happen. Learn what the weakness and strengths are of each method in relation to your product.

 

Up Next CSS 4 – The Future!

A very nice collection of CSS spec writing people on this panel. This should be an interesting panel.

flexbox – should have browser support by years end. This means we have a few years before we can use this as a standards.
grid -
new filters: Don’t confuse this with IE filter

@supports -

Fallbacks are still going to be hard without using modernizer – one recommended strategy for the future.  Nice to know that CSS 3 is marketing term only based after CSS2.  In case you want to help you can right use case tests to help get the tests valdiated.

http://www.w3.org/TR/CSS/

http://wiki.csswg.org/test – This is if you want to submit a test suite – for the CSS spec. This will help to get more of the spec into real world browsers.

CSS Pre-processors
“We are looking at pre-processors for re-routes to see what we can improve in the tech.” – Atkins

• Variables
• Nesting
• Mixins

Candidate Recommendations & Shift that causes confusion to dev. (good insight here into the process)

• Edits, Changes, Errata Process requires change back to working draft.
• Module issues that are not truly ready for candidate recommendations – CSS 3 text module & type setting placement, CSS ruby module,

Why are the specs so complex?

The specs are designed for the implementor. The spec audience is for the browser implementors – the developer would be the 2nd audience. This explains why a lot of the spec becomes extremely confusing and why you need to seek out – true usage scenarios to development. This was interesting because of a question asked in the room.

How many people have found ready the CSS spec? About 100 people rasied hand.

How may people have found what they need? –  about 10 people with hands still up.

That sounds like a problem that could be solved – Couldn’t there be a tighter connection been demonstration and the spec?