Measuring Product Experience!

This is one of the best examples I have seen of a government agency measuring the ROI of the products they select to use.

The King County Environmental Purchasing Program in Seattle, WA actually tracks the counties experience with recylced products they have used in place of new products.
http://www.metrokc.gov/procure/green/rdsasph.htm

They have a form that identifies criteria that rate the experience of that product in relation to the cost savings. One of the things that seem to be missing is the longevity of the recycled product in comparison to new products.
http://www.metrokc.gov/procure/green/form.htm

Shopping Carts

Have you noticed how big shopping carts have gotten? I don't mean the web shopping carts, I mean the ones with wheels and plastic handles. The retailers have figured out that if we can't haul it to the checkout line, we may not buy it. So I have been looking at shopping carts in all the stores I have been to recently.
I still can't figure out why Kohl's shopping cart is so unlike the others and I wonder how effective it is. The Kohl's cart is more visually appealling, the childseat is much more like a stroller, but to buy items, you basically just stuff them into the back. I often don't grab one, because they look more like a stroller and I don't have stroller tots. Then, I begin shopping and run out of arms. Hmmmm -maybe I am just not their target consumer or I am comparing the wrong store model to Kohls.
Walmart, Target, and Kmart have Carts with the tiny seat for a child. Marshalls and Kohl's have the Strollers with a tiny cart design.
Now I need to go see what JcPenney and Sears have because I really can't remember. All I do know is that Kohl's is no Marshall's and I don't need a stroller, I need a cart! Shopping days are dwindling......

Jakob's word on weblogs

Jakob has lots of good points and says every blogger should post a photo.

Unfortunately, posting a photo isn't as easy as writing a blurb. I think it is a usability hurdle - it takes time and learning to figure out how to do it. When I find the time and figure out how, I will take his advice.

Usability Test Planning

Usability Testing has work activites that come together before going out to do the study.

- Recruiting (one month in advance - selecting locations than dates and participants
- Travel Planning (one month in advance - in tandem with the recruiting)
- Prototype development and refinement (2-4 weeks in advance depending on the fidelity)
- Task develepoment (2-4 weeks in tandem with the prototype)
- Approvals (2-4 weeks in advance depending on the formality of the study)

These activities are part of the test plan, but the plan also includes the objectives, success criteria, target audience, test methods, test schedule, agenda per individual test session and all of the data collection sheets.

Data collection sheets usually contain a pre- and post-test questionnaire, task sheets and any written materials provided to the participant during normal use of the product. (If a manual has been created and comes standard with the product, the manual should be mentioned and placed near the participant, if they choose to consult it.)

When preparing for a Usability Test the details are important. Confirming participants, Piloting with the task and prototype, and providing thank you gifts are an important part of making a Usabilty test have meaningful results and leave the participants feeling like they were part of something special.

Driving Design

I am juggling a couple of clients right now and it always amazes me how much time i spend shaping how people react to things presented. I have to make sure I know who is coming to a meeting, their possible positions and arguements in any change or innovation. I have to dream up what their perceived risk, issues and concerns are before they see a concept or the design will be eaten alive or squashed before you can even figure out that the change is just the thing the product needed to stay fresh, usable and useful.

The Usability News had an article by Ann Light about the Interact 2005 conference keynote by Bill Buxton.
'As designers, we spend more time designing the organisation and the attitudes of the people around the process,' he said, estimating that only 20% of effort is spent designing the thing itself."

I don't know about what else he said, but I can't wait to read the book.

Reporting contextual inquiry results

Everyone needs see the results of a site visit. What's the best format? As a designer I like to apply what I learned immediately to pre-visit concepts and make them more real so that I will have time to validate and iterate. But the team needs to understand what you did, who you saw, and why this new perspective is more accurate then their previous view of the world.

So a trip report has to include:
--Who you visited
--What you observed
--How the process observed modifies current flow
--How the procedures and language modifies current terminology, field labels and options.
--How the design, screens and hardware should be modified to reflect this new understanding.

Contextual Inquiry in a Medical Setting

I don't know about you, but I have such a hard time not embracing a patient who is in pain or assisting someone who is losing their balance or offering a kind word of encouragement to a caregiver who has been watching their dear one decline to the point of being unable to feed themselves. How do you observe and only observe?

I don't think I can do it. Is it okay to compassionately observe and still reach your hand out to pat a fellow hand. To nod and have your eyes well with tears while the patient stretches and grimaces and tells you how much better they feel.

I find myself wanting to make everyone all better, kiss all the boo-boo's goodbye. How do I improve the product empirically without modifying the actual patient environment?

Task scenarios vs Decision Trees

I use both task scenarios (steps a user takes to accomplish some goal) and decision trees (questions the user or system needs to ask to accomplish the goal). One is task centric and the other is process centric, but both are focused on understanding the goal and how to acheive it. There are too many ways of getting to the same means, you must identify the goal, you must identify the process(es) used to achieve the goal and the tasks within the process. You can work bottom up or top down. Sometimes I watch people work and record their tasks, identifying the formal or informal process they use and the end goal, whether they stated it or not. Sometimes I start with the business stakeholder, understand what they want to acheive, the process by which they might make it most effective and then devise the tasks most effeciently.

Both of theese techniques help you drive effeciency and effectiveness. Neither of these help you be intuitive or consistent. You still need to turn the stories, personas, tasks, scenarios, or decision trees into pictures that make sense and follow rules.

Who cares which techniques or artifacts you create? If you are actually observing, collaborating and working with your users and stakeholders you know you will be designing the right thing.

Your sketches/pictures/mockups/prototypes will tell you if you talked to the right people and have the right goals.

User - Human - Activity Centered Design. What gives?

It seems like everyone is still trying to come up with their own words for how they approach design. Don Norman's "new" stance (http://www.jnd.org/dn.mss/human-centered_desig.html)is that user centered design is not as important as activity centered design. I don't know about you guys, but user centered design never just meant profiles and personas to me. Yes I do make sure I know who the target user is, so that I can understand what GOALS they are accomplishing when they show me the kinds of tasks they are performing. To me the GOAL is the reason for the ACTIVITY and the ACTIVITY is accomplished through a series of TASKS.

For example in a call center a user shows me what she is doing: "I record all of this information when a customer calls". In my analysis, this turns into a design that allows the user to perform the tasks to get the end result. The end result or activity is richer customer information that leads to better customer service on follow up calls. The Goal is better customer service, the Activity is collecting and recalling richer customer information, the task is entering the data and recalling the data. Haven't we all be doing this when we say we are User Centered Designer or Human Centered Designer or User Experience Architects or Usabilty Engineering or whatever.....

This doesn't seem new or different to me - just another way to say the same old thing: users performs tasks, combined tasks are an activity, activities accomplish a user or business goal. If the Goal is worthwhile enough then people will adapt. Is this the point that Don Norman is trying to make? If so, I agree, but I have always accounted for the potential value something new, undreamed of before by the users, as having substantial enough value to the user that they will be willing to learn. I may be just the thing they never knew they could have or needed. I don't believe UCD or HCD ignores innovation if the value can be understood and embraced by the users it was intended for.

Well, he got me thinking and reflecting - maybe that was THE point!

Usability Studies

I am helping to design and test a device that causes a sensation the user can feel when they use this device.

For obvious reasons, our new design prototype won't actually zap or tingle the user during the study, but it leaves a big part of the device responsiveness missing during the usability testing experience.

The users often don't even look at the UI, because they say they are going by how it feels, not by what the numbers are doing on the screen.

So far, some people have really liked the UI, but few were successful with the device. How much of this is because a key success indicator to the user was what they were feeling?

Focus Group or Not?

So the marketing manager sets up our first contact with real users, which I stated would be actual users of the device. Unfortunately, she didn't hear the "in their work environments" part.

Like a good marketing manager she hosts a focus group, complete with dinner and drinks during a training event.

Now I work fast to turn a focus group into a contextual inquiry and design walkthrough session.

I will be bringing the devices, showing screens shots of newly designed GUI for new features, and allowing time for lots of questions and answers. So now a 2 hour focus group has turned into a fact gathering, design walkthrough I will facilitate for 1.5 hours and a focus group for 15 minutes that our Product Marketing Manager will facilitate.

BONUS - I will be attending the training program that covers things every introductory practicioner attends. The agenda includes selection, advanced device programming issues, user management, and case study presentations by attendees (whoo-hooo, now that's what I'm talking about!)

Observations from UPA International Conference in Montreal.

I am at the International UPA Conference in Montreal. Because I am serving as Co-Chair, I get to sneak into all the sessions and take a sneak peak at what is going on.

I stepped in on The jigsaw puzzle of intercultural usability tutorial to see the group had broken into teams for a project, one team was speaking in French and one in English, while the presenter, Lada Gorlenko , had a hint of a Russian accent. The teams then came together and shared their ideas with another. This is just one example of how a tutorial can live of up to it's promise.

The next was the Discovering User Needs: Field Techniques You Can Use tutorial by Ellen Story and Kate Gommoll. What impressed me were the shear number of artifacts covering the walls. Some that they brought with them and some that they were beginning to create during the session. If you ever wanted to see what someone else's profile, persona or storyboard looked like, it was all on display at this session.

Finally, Know Thy Disabilities: Beyond Checklist Standards and Automated Tools for Evaluating the Web tutorial given by Nicole Tolefson and Philip Kragnes struck me because of the blending of science, knowledge and true user experience. Philip is an Adaptive Technologies Specialist, who majored in Cognitive Psychology and just so happens to be blind. So when he talks about adaptive technologies he really gets it.

If you are here at the conference, I hope you are enjoying it as much as I am. If you couldn't make it, please try to join us in 2006.

Success Secrets - Project Kickoffs!

We are kicking off two projects this week, both are working on hardware devices with software interfaces. One of the ways that we successfully transition from the proposal phase to the working phase is a project kickoff.

A project kickoff includes the following:

• Project Summary - products included and purpose
• Project Milestones and Deliverable
• Project Objectives and Success Criteria
• Project Scope - indentify those things Out of Scope also
• Project Assumptions, Constraints and Dependencies
• Project Roles and Responsibilities
• Project Contact List - names, emails, phone numbers of all team members
• Change Management Plan if anything identified in the Project Kickoff doesn't hold true

The power of the Project Kickoff is introducting everyone on the team, getting everyone driving to the same objectives, removing ambiguity of who is responsible for what and putting a method in place to mitigate project changes. The kickoff should be a means to clarify, solidify and assign accountability and collaboration.

Good project planning and UCD philosophies are a measure of the maturity of the organization. Pat yourself and your organization on the back if this is how you start a project!

UCD Proposal Basics

While I am trying to put the finishing touches on one project, I am putting together a proposal for another.

The Background

The hardware (3 separate products that work interactively with one another) will be unchanged, but the software needs to be refactored for a user population with completely different needs. Only 2 of the products have UI. One product is for the user and one product is for the programmer. The first project I participated in was for one target audience, the second project is for an entirely different target audience.

Basics of Proposal - UCD in 3 phases - Research, Design, Validate.

Research
Users have already been studied extensively, so we will be using previous human factors data for that user profile, but will be studying the new target audience.

• Watching initial use of device.
• Watching follow up use of device.
• Watching users be trained on new device.
• Watching follow up sessions with users after they have used the device for some period of time

Design

• Design additional features for existing users based on previous data
• Design for programmers treating existing users based on previous data
• Design for new target audience with new study data
• Design for programmers with new study data

Validate

We will be validating the designs in Europe and the US for all audiences.

The Challenge

The research-design-testing of these 3 products for two different disorders and two primary user types needs to be done by the end of the year.

Whooo-doggie - I like a challenge!

Ad Hoc Interviews

In an attempt to do some product and user research, without seeing real users in action, we brought together a group of folks who observed users and asked them about what they saw.

I started with some opening questions to get them started, but then they generally went on and addressed many of my questions without being asked.

I summarized what they had told me, the positive and negative experiences, the environment in which the device was used, the difference between a new patient and a follow up patient in their use patterns and things they thought the device should do.

We got some great input and some more names of folks even closer to the user, the folks who performed the study with the users. We will go talk to them next.

Sometimes, you start where you can and keep taking steps in the right direction. We hope to be participating in study follow-ups this fall. Then we will actually be in the room with the user and their working device. Up till now, usability had only used demos or prototypes of the product that didn't actually do anything, so the tactile experience was missing in the U testing. Now we can observe them using the real thing, baby steps with impact!

Design Reviews

I went through a UI conceptual design review with system engineering and product planning today.

Here's the challenge:
I had never met either before, so my assumptions about their communication needs were based on their job titles.

• The product planner (marketing) head would want more pictures and storytelling.
• The systems engineer (development) head would want more detail and would point out more flaws.

Luckily, horrible generalizations proved helpful, but of course they weren't right on and I found myself back peddaling and providing more detail for the product planner than expected.

I also learned that some of the original feature requirements given me, did not come from product planning, so some of the concepts seemed pretty far out there. All in all, it turned out well, but it is amazing how each day you learn something you never expected.

Requirements gathering in are not as clean cut as I expected them to be.