January 20, 2008
But, what really is important is that the analyst (interaction designer, business analyst, and developers) understand "how" the user works. That's actual usage of their tools. If I ask you how you work, or put you in a focus group with others who do similar jobs, I will get a different perspective than if I just go to your workplace and watch what you do. Many of us actually have very little ability to describe our jobs very well, as strange as that seems. Try it out. Keep a journal for a week and record everything you do. You'll be amazed (not to mention annoyed) about how different those perspectives were.
Putting the analyst in the users' offices really is important. Observation will beat focus groups every time. We are way too easy to get reality and desires confused.
Again, this does not diminsh the need for the user's invovlement in the design. But spend the time on the "interesting" or complex tasks, and use the expert observation to design the mundane task completion. Usage-centered design is the way to go.
More to be said on this, buf for now, let's think about a better way to design.
January 16, 2008
The sessions I attended included Larry Constantine's "Interaction Design in an Agile World", which was a very good all-day talk on how to integrate user interface design into the Agile development processes. It's not easy, but it can be done. Luke Wroblewski of Yahoo talked about good form design, and brought a lot of research to back up his findings. We'll definitely use some of that in our product design.
Probably the thing that stands out the most to me is the fact that so many of the companies represented there had specific "Interaction Designers" who had the specific job of researching, specifying, prototyping and testing user interface design. This, of course, is a much different job than my own Interactive Graphic Design team, who focus on the look and usability of portions of our client sites. Currently, our business analysts are doing some of this work, but it really is a specialized area.
Our users have traditionally been the administration user, one we can train, and one that sticks around to know the software very well. The true end user (our clients' users), are a different type of user. We don't have the luxury of training them on the software, and they may only interact with us once or twice. We HAVE to be usable, and yes, even delightful.
ActiveAdmissions has some specialized controls such as the online application and guidance counselor functions. ActiveAlumni has its directory and authentication controls. Both products share a multitude of controls, however. Each control can be customized based on the user's needs. For example, an alumni spotlight content item may consist of an uploaded photograph, person's name, their degree, their current job and the year graduated. Another client may want to add in their favorite memory. The system can handle any number of fields for any of the controls.
Datatel consultants work with the client on best practices, but always want the client to put their own "touch" on their website so it is different from other institutions. Working together with solutions consultants, creative consultants and User Interface developers, the sites come together in a beautiful way. When tightly integrated with data from Colleague, things go well.
All of this orchestration takes a lot of work, and a lot of pieces need to fit tightly together. Software development works hard to make it all happen under the covers, and we continue to improve the product and services.
Thanks to a great team in Buffalo and Fairfax, this is a true "user experience" process that keeps getting better.
I spent Saturday at Niagara-on-the-Lake just across the border, at the mouth of the Niagara River as it hits Lake Ontario. It's a quaint, beautiful town, lots of tourists. The "vacation mode" started as we crossed the border. The Canadian customs officer was pleasant, asking their typical "Where were you born?" quesion. After that, you head to a toll booth where you have to pay the fee ($3.00 US, $3.50 CDN). As I was searching for the correct change, the toll collector was chatting away with me about what a nice day it was, have a great day, etc.
We spent the next few hours sitting at a hotel's outdoor patio, watching the crowds go by. I think it's actually pretty easy to spot a Canadian from an American, so we played that game for a while as we also watched the girl that gives the horse and carriage rides clean up that bag that they put on the back of the horse (yeah, that was our view for a while!).
The change of atmosphere was brought home as we headed back home across the border. The US Customs Agents are very military looking (not that there's anything wrong with that!), carrying sidearms and rarely smiling. Quite a contrast from their low-key Canadian counterparts.
Vacation mode was definitely off. The general pace and attitude of the American's is really a contrast to the Canadian's. Maybe it's the beer, but I think there's something to be said for a lifestyle that has humor and relaxation, with no drop off in productivity.
Lighten up America!
It's one of the few technical terms that really describes itself... (think about that, and what that says for our industry!).
Usability is really in the eye of the beholder. Ask 10 people their definition of "quality", and you'll get 10 different answers. Usability is a big part of quality, but it's rare to see it mentioned in any of the so-called "quality methodologies". What is easy to use by one individual is a nightmare for another. That's why the definition of "usable" software has to have several components:
- The Persona. The "definition" of the user who will be using the software. There can be several personnas definined, but it's difficult to design software for personnas on opposite ends of the spectrum.
- The Requirements. Requirements are a description of what the software should "DO".
- The Specifications. Specs are "HOW" the software should accomplish the Requirements. And there's the rub. Some of the best software meets the requirements, but is still unusable. The best way to define specifications are with:
- Storyboards and Prototypes. These are essentially paper prototypes of how the software will look and interact.
- Usability Testing. This is the most overlooked, but most critical piece of software development.
Feature-rich, but usable?
Usability testing is accomplished by asking users (that meet the personas - not techncial people's PERCEPTION of users) to accomplish everyday tasks. They are observed, and asked some questions after they have attempted their tasks. Feedback goes into the next iterative development phase. Without that feedback early and often, the risk of poor usability will always be high.
More to come...