Tuesday, June 28, 2005

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.

Monday, June 20, 2005

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!

Monday, June 13, 2005

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!

Thursday, June 09, 2005

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!

Tuesday, June 07, 2005

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.

ShareThis