Tools for Planning User Interaction Research

I'm over half way done with my HCI class now and I have been trying to come up with solid topics to update you like I promised. The class has been very informative in my opinion, so I was frustrated when I couldn't find the words to express what I have learned so far. I think this is because HCI is part common sense, although not always obvious, part art of presentation, and part analysis, and while I'm learning about each, I don't have enough experience to pull everything together. I'll get there.

What I have finally found is support for determining how to test if a project is on the right track for users. My class spent a significant amount of time learning about task analysis and prototyping, but our readings amounted to details of each tool or process we could use. What I have wanted ever since is a chart or map to tell me which one I should use at what point in the development process and what information I can expect to gain from each, and now I have finally found exactly what I want!

Adaptive Path's blog had a post that linked to a writeup on user experience research methods which gives great descriptions about the categories of methods and when to use each. Most importantly though, there are charts!

The first is a graph that plots methods based on data source, approach, and also shows through which context users will experience the product. I love this because I can easily see what techniques we use now, where they fall on the chart, and what other methods we may want to use to balance the information we get.






The second is a graph based off of the first that tells what questions methods will answer based on their plot point of the first graph. This will make it so easy to figure out which method to use based on our situation or a problem we are trying to solve.






The last chart ties in the "when" factor. Different methods are used at different parts of development and this chart makes it simple to reference throughout the phase.










I have posted the charts in the order they are described in the referenced document, but now that I have read through the explanations, I will probably use them in a different order. Of course each can be used individually, but in most cases I see my self starting with the second one to find a method to answer a question. I imagine I will then reference the first to see what tools we are already using in those categories or get ideas for new methods. I imagine the third chart would be most useful for planning out user testing that will be done for a project. This way we can gather important input at key points in the process as well as plan for them upfront.

I can't say that the user input we get at work will drastically increase, but at least now we have tools to be prepared and back up the need with what information we can gain and how the company will benefit from it. Here's to displaying information in an easy way to digest!

Human Computer Interaction

This week I started my first Human Computer Interaction (HCI) course through Iowa State's distance education programs. The course is actually a psych class called "The Cognitive Psychology of HCI". This is my test to see how working and going to school mesh for me and to see if I'm interested enough in the area to complete a graduate certificate or full degree.

I have decided to post interesting things I learn to spread the news. The class is based around distance collaboration, so we have a wiki with personal information that will also be used for our team project. We also use a discussion board so that off-campus students like me can participate. One of the "open forum" posts by a student included a link to the site of a Mozilla developer about usability deemed the 10 Commandments of Usability. It's all good, but some quotes I particularly enjoyed are

• "Users aren’t dumb. They just have better things to do with their lives than memorizing the internal data model of our screwy software."
• "The job of the UI designer is to provide what the users need, not what the users say they need."
• "The science of design can tell us that interface foo is X% more efficient than interface bar, but bar is Y% more learnable than foo. Choosing between foo and bar — that’s where the science ends and the art begins."
• "When we blame the user, we teach them that technology is perfect and that the errors are their own. Because technology is hard to use, we are teaching a generation to be afraid of technology. We are teaching a generation to believe in their own stupidity. This is a sin, too."

Google Docs and Blogger Work Together

I noticed a while ago that Google Docs had new features. They have several more announcements now, but I'm talking about way back when they added the ability to publish to your blog. They currently support Blogger, BlogHarbor, BlogWare, LiveJournal, SquareSpace, WordPress, and any site that uses the Blogger, MetaWeblog, or MovaleType API. I use Blogger and have been fine with typing in the text area they provide, but this could be helpful if you publish with several other people on a blog and don't want them to see your work in progress. In my case this would be more useful to hide how long it can take me to finish a post that I start. So I finally tested this feature out on a recent post to a green blog that I contribute to. It's nothing fantastic, but it worked. I do have two complaints. The first is that the settings ask if you would like to include the document title when posting (if possible). I selected this option and expected that since I use Blogger, this would be possible. Apparently not. Hopefully this will change, but it is annoying for now. The second gripe I have is adding tags to your post. This was also mentioned during the publishing process, but there wasn't a way to add them without going in to Blogger and editing the post. I'm trying this method once more with this post, but I think I'll stick with Blogger until they make a more compelling reason to switch.