Showing posts with label Scenario based design. Show all posts
Showing posts with label Scenario based design. Show all posts

Tuesday, December 12, 2006

Three reflections on an email design assignment

Adapting and Appropriating eMail, ProcessRight WorkFlow
Appropriating and Adapting eMail - ProcessRight Workflow Poster

First,

I have always loved email since 1978 when I began using it over the University of Alaska’s UNIX main frame in Anchorage to email people in Fairbanks. Significantly at that time we were discussing music, Bob Marley and The Wailers (how I discovered them), another thing of strong social importance Microsoft managers failed to recognize as valuable.

Why Bill Gates and the factory did not see what a huge innovation email was, and how extensible, I never understood. Why, despite my input and the input of others at Microsoft, development for email failed to gain much footing. Until the last few years a very small amount of money was invested in developing email. This was due in part to the structure of the development managers directly reporting to Bill Gates -- within that hierarchical structure, at each level there is a decreasing amount of authority, however at the next level down one can not really question the voice of authority above. This is an old fashioned management style based on military structures developed for waging war.

From interviews I did last fall including one of a former Microsoft lead email development engineer, I found that all that required was one manager at one level to wipe out Bill Gate’s vision – if Gates said spend $10-$20 million, the next manager changed that to 3 million, or less, there was nothing the visionary email engineers below could do about it. Eventually they quit and formed other companies.

Everyone understood the value and power of email of communications – but no one, save the customer voting with their buying power, could get management to budge. Finally when Microsoft's eMail product became the leading selling product after Windows itself did Microsoft management take notice. They were forced to do so by the downward trend in stock value and sales. Now we clearly see all end users really need are two things – browser and email -- and some products can be both and more at the same time using the same basic interface.

I believe this is why we have this as an assignment – had Gates encouraged other non-traditional, cooperative, even tribal structures to form leadership in various ways the product we describe would already exist, not just be embedded as a possibility in applications such as Outlook which require a developer to pull into reality.

In this way, over so many years, I learned that new ideas can be killed due to stubborn traditional systems which may not be recognized for what they are. New ideas may long await fresh new management.

Second,

Having the third party review engage the cohort from our idea stage down to their formal presentation was a stroke of genius in envisioning and shaping up our resulting product.

I found much that I took for granted was still embedded in my thinking as an “of course” and not explicit. In communicating with people you have to make your ideas explicit.

So such usability issues as landing pages to track the results of a process are one of these “of course” structures, which will be included in my future product designs.

Performing recent usability studies I found the exact same problems with beginners learning software exist now as they did in 1989 – the year Windows 3.0 was released. In 1984 I recall having very little trouble learning the MacOS interface.


Third,
The VIEW

There is a small political commentary nod in our selection of the title for the company “ProcessRight” Actually it relates to the political LEFT because the public voided the Right. I recently searched on ‘processright’, and quickly realized it owes its name in part it to the format of method calls in C++ and C sharp, such as used in the Invaders game at Duke University:

http://www.duke.edu/~jbs3/cps108/ooga/oogadocs/invaders/Invaders.html

“ProcessRight
public void processRight() - Provides the rules for what to do when a left event is pressed
Overrides:
processRight in class Game”

We used Google Talk IM to communicate in the last hours of our project. One of my cohorts, an employee of our favorite 800lb gorrilla across Lake Washington, may not want a GMAIL account to communicate using Google Talk IM.

It is true that Patton said, “There's a great deal of talk about loyalty from the bottom to the top. Loyalty from the top down is even more necessary and much less prevalent. One of the most frequently noted characteristics of great men who have remained great is loyalty to their subordinates." This should apply to Microsoft employees too.

But you got to get into the game so I invited my cohort to get an GMail account to learn what the other guy is doing - here is why - to paraphrase Patton (if even from the film) metaphorically --

'Google are Microsoft's enemy. Wade into them. Spill their blood. Shoot them in the belly. Lift their software and interface ideas.'

“For over a thousand years, Roman conquerors returning from the wars enjoyed the honor of a triumph - a tumultuous parade. In the procession came trumpeters and musicians and strange animals from the conquered territories, together with carts laden with treasure and captured armaments. The conqueror rode in a triumphal chariot, the dazed prisoners walking in chains before him. Sometimes his children, robed in white, stood with him in the chariot, or rode the trace horses. A slave stood behind the conqueror, holding a golden crown, and whispering in his ear a warning: that all glory is fleeting.” -Patton

Last,

Very much enjoyed working with my team – it was a blast!

“We're jammin'
I wanna jam it wid you
We're jammin',
And I hope you like jammin', too
Ain't no rules, ain't no vow, we can do it anyhow
I'n'I will see you through;
Everyday we pay the price with a little sacrifice,
Jammin' till the jam is through. Ooh, yea.

We're jammin'
To think that jammin' was a thing of the past
We're jammin',
And I hope this jam is gonna last
No bullet can stop us now, we neither beg nor we won't bow
Neither can be bought nor sold
We all defend the right; Jah - Jah children must unite
Your life is worth much more than gold. Ooh, yea.
[1]

[1] Song lyrics from Robert “Bob” Nesta Marley, “Jammin’” Release Date: 1977 Genre: Reggae Label: Tuff Gong Downloaded Monday December 9, 2006 from http://www.hotlyrics.net/lyrics/B/Bob_Marley__amp__The_Wailers/Jammin_.html Lyrics originally published on the album.

Saturday, November 04, 2006

It Works and We Like Using It

No matter how comfortable and well upholstered a chair is, if a person’s goal is not to sit down but to take a shower they need a shower not a chair. With basic and common sense approaches to system design authors on task analysis and usability outline ways to test and examine real people performing actual or visualized tests so that the resulting system designs both function and do so elegantly; these methods can compliment each other to derive the best from both forms of analysis.

In the early days of the Web, basic text sites, with just simple links sold merchandise; one classic site that sold quite a bit of merchandise was a Christmas gift site, center-justified colored text with many links running straight down a single page decorated with randomly placed candy canes. Certainly such sites were not easy to find, nor easy to use and, in a word, ugly. But they were useful.

One might think by now we were way past questions around online goals, and into customizing beautiful interfaces, but with the plethora of reasons to use Webs the need to evaluate what people’s actual goals are in unique situations and combine ease of use customized with real goals has grown as the world reaches past the 100 million mark of live sites(1). We seek to both have things work and enjoy using them; using these techniques ensures both are likely.

To help designers improve systems Task Analysis focuses on what real people do to achieve their goals (Greenberg, 2003), and Usability Evaluations are based on evaluating how discoverable and possible the interface allows for people to achieve their goals (Krug, 2000). Both have the same goal – usable systems – but by different means. The difference is Task Analysis captures the working environment and demonstrates who the user is and what they are trying to achieve, what their goals are including failures. In the Usability Evaluation method the goal is to help designers increase how well end users can accomplish tasks, and even measure the difference from old systems to new ones.

Following the advice of these authors, from the beginning envision incorporating task centered design to follow and watch how users actually work, and make notes as they demonstrate the Web based software for the design process.

As you learn more about a system you tend to forget that you are making due, using workarounds to make up for system flaws, so it is just as you enter a system that it is best to carefully document and record what your own experience as well as the users immediately.

Paper prototypes are a swift approach to get to the first level of task centered design, and it is with this approach that the beginnings of usability start. Working with teams dispersed worldwide one plan of action is to rely first on local teams, using their feedback begin to construct clickable wire frames, iteratively requesting feedback. Scenario based design (Carroll, 2000) will also help make the designers job easier in terms of what it takes to display lots of data and make it useable.

Several authors make the same point that having just a few people perform some usability tests is better than no data at all, notably Nielson. All in all combining pulling from several methods from beginning to end will make both the process and the results better for everyone.

(1)“Web reaches new milestone: 100 million sites” CNN article located at: http://www.cnn.com/2006/TECH/internet/11/01/100millionwebsites/index.html?eref=rss_topstories

Written for IMT 540



Dr. Dave Hendry's University of Washington's iSchool Website