|
|
|
|
|
|
|
|
|||||||
|
Argentine tango blog
/ with Interaction Design interludes / by Oleh Kovalchuke |
|
|
|
|
|
|||||||||||||||||||||||
|
|
|
 |
 |
 |
 |
|
|
|
|
|
|
|
|
|
|
||||||||||||||||||
 |
|
 |
 |
 |
|
||||||||||||||||||||||
|
|
|
 |
|
|
||||||||||||||||||||||
|
|
|
|
 |
 |
|
|
|
|
July, 2006
July 29, 2006 - Taxi dancers in Buenos Aires
Another insight from the voluptious Deby Novitz, directly from Buenos Aires:
There are taxi dancers here in Buenos Aires. Some of the older guys who dance well but are on pensions will accompany a woman to the milonga. There are also some younger guys who do this as well. I have found the younger guys to be very nice, courteous, and not always the best dancers, but probably better than the dancers of where the lady came from. There are guys who dance well who need to make some extra money, they are also nice, courteous, and with honorable intentions. Some of the professional dancers also hire themselves out but at very high rates as they really do not want to do it.
These guys except for the professionals charge 25 pesos per hour. They have a 100 peso minimum. The professionals charge 200 pesos an hour with a 2 hour minimum. (Yes, women pay it.) They usually do not work past 1 am. The clock begins when you meet your dancer. The person paying assumes ALL the expenses. This means that if you want him to pick you up in a taxi you pay for the taxi. If you want to have dinner you pay not only for both dinners, but also for his time. You pay for the milonga entrances, and also for any drinks. One women got angry when she found out she had to pay all the expenses. I told her it is a business transaction not a date.
There are women taxi dancers as well. I have on occasion been asked to accompany someone to the milonga and dance with them. I know other women who do this as well. With the taxi dancers I know, male or female, they are NOT prostitutes. They provide a service to people who would like to be accompanied to the milonga. It is very important to understand this. It is insulting to be expected to provide these additional requests whether you are male or female. The people who do this professionally do not even think of selling themselves as prostitutes. They have reputations and want them to remain good.
The dancers I know do not ask for money at the milongas. They may see a woman who is not dancing, invite her to dance. He may dance several tandas with her. During this time he mentions that if she would like to have him accompany her sometime, he is available. The men I know arrange to do this at a later time, not at the same milonga. There are some that offer their services on the spot. You should never feel pressured. You pay after the services are rendered.
July 24, 2006 - Psychology, interaction design and a crack
Jack Bellise took exception to my 'Power User' motivation argument from Do keyboard shortcuts always facilitate work? message. In fact I have no other way to describe it but to say simply that I have managed to crack him up. Here, in his own words:
Oleh, you crack me up.
Let me see if I've got this right. You perceive, in the matter of software keyboard support, issues of class struggle and id/ego conflict? I thought I was creative... but this is profoundly imaginative. (You don't have your father wrapped in duct tape and locked in a closet, do you?)
And all this time I thought it was simply that productivity-minded people seek to constantly add to their keyboard repertoire because its precision is unconditional, and it therefore yields several benefits, speed among them.
Here is my response:
Well, I think if you don’t crack up at least one person, then the message is not worth writing, don’t you agree? Thanks in turn for your thought provoking message - those are to be treasured.
You make two curious points.
First you argue that productivity-minded people would find speed desirable and beneficial:
"...productivity-minded people seek to constantly [learn X - OK] because ... it ... yields ... speed."
It is true indeed that speed of task performance often leads to higher productivity for that particular task. However, the point I was trying to make in my message is that Productivity is multilayered concept, it has different meanings depending on user goals (speed of particular task performance could be only one of those goals, but not necessarily primary goal), or to rephrase it: "Not all people are productivity-minded". I believe that design should take into account considerations of nonproductively-minded people.
You second point is on the scope of applicability of UCD/GDD, namely at which cut-off point you stop thinking about user goals and begin to "just do it!":
"You perceive, in the matter of software keyboard support, issues of [motivation due to creativity and proficiency, AKA self-actualization and self-esteem - this is what I wrote in my original message - OK]. And all this time I thought it was simply that productivity-minded people seek to constantly add to their keyboard repertoire because its precision is unconditional [their motivation is reliability and usability - OK] "
This second point is more interesting to argue because it is only once removed from the "just code it" approach, the all-too familiar attitude in the current software development environment.
To me UCD/GDD is more than simply a collection of useful usability guidelines. There are many examples where consistent application of guidelines, without knowledge of their origins has been counterproductive in unanticipated context. This is why I begin to design with a concept, and attempt to take into account user motivations. Once I have the concept of user interaction, maintaining user centered approach becomes quite effortless even in the small matters of shortcut implementation.
Do I agonize over id/ego/superego conflict when I think about which hot key to use in my design? Not really. Might I consider user motivations to learn and his cognitive limitations, when I think about adding effort-demanding interaction to the design I make? You bet.
----------------------------------------------------------------------------
Actually I have misunderstood Jack. So I had to write another reply to clarify my position. Here is that second respoinse:
Jack,
I would like to admit the crucial mistake in my previous reply to you: I have misunderstood you - you were not arguing with my description of motivation for the "Slackers", you were referring to the 'Power Users'.
In my original message I have mentioned that self-esteem could be the motivation behind memorizing the keyboard shortcuts for 'Power Users'. I wrote:
"Decision to design for shortcuts should take into account user background. For instance, mastery of shortcuts can be used to build self-esteem. As one learns shortcuts, he might claim membership in the exclusive group of the 'Power Users' (instant three-prong boost to self-esteem via authority, scarcity and social proof). 'Engineers' (personality type) love shortcuts. Accountants, Writers, power plant Operators (occupations) satisfice, and would rather spend time doing accounting, writing, power plant operating - the tasks, which extend far beyond the tool, instead of attempting to memorize shortcuts within the tool."
You, on the other hand, argue that keyboard mastery is goal good enough to justify life-long study; no further motivations to learn should be implied, thank you very much... Well, if that were true, why not give people any gadget at all and they will happily spend the rest of their very short lives exploring it because it is right there, in front of them to master. Why would we need to design for interaction at all?
I certainly would like to differ with this position. I strongly believe that people, including 'Power Users' do have other reasons to learn the stuff they do aside from the sheer challenge of complexity of the task at hand. Achieving high social status in their niche is very much one of those reasons, if only to bring more little 'Power Users' in this world.
So the real question I would like to ask you is this: In your opinion what makes people productivity-minded?
By the way, my references are Maslow's pyramid of needs, Cialdini's psychology of influence and Dawkins et al evolutionary psychology. Could you provide me with yours so I will not spend the rest of my life studying the unnecessary complexity of human psychology?
July 20, 2006 - Do keyboard shortcuts always facilitate work?
Juan Lanus wrote about unwillingless of some users to learn software shortcuts:
This amazes me. Shortcuts are one of the best kept secrets of the Windows UI. For example, many people ignore they can switch tasks with the alt-tab-... sequence.
Consider switching tasks with alt-tab in larger context. I have used alt-tab with Windows 3. Not anymore. Because it is simply less mental effort to switch windows by clicking the visible button on the TaskBar in XP.
Letter based shortcuts are vestiges of command interface. The well-known argument against command interface, and therefore against shortcuts is human preference of recognition over recall.
Another, less obvious argument is that shortcuts violate consistency principle. Take for example wordprocessing: as you type you know that if you need to highlight a word, you reach for the mouse, if you need to rearrange the text, you reach for the mouse, if you need to check the spelling, you reach for the mouse. Typing - keyboard, editing - mouse. Now, assume that to make some text bold you use shortcut key for bold instead of reaching for the mouse. This keyboard shortcut interaction would create inconsistent behavior for editing.
Also since I always pause as I work, the unconscious, mechanical interaction with mouse punctuates my work without breaking the flow.
In a test I recently made with a 75 years old CPA, I confirmed all this. He uses computers since ever, and PCs since long time ago too. He was not aware of any keyboard shortcut.
Decision to design for shortcuts should take into account user background. For instance, mastery of shortcuts can be used to build self-esteem. As one learns shortcuts, he might claim membership in the exclusive group of the 'Power Users' (instant three-prong boost to self-esteem via authority, scarcity and social proof). 'Engineers' (personality type) love shortcuts. Accountants, Writers, power plant Operators (occupations) satisfice, and would rather spend time doing accounting, writing, power plant operating - the tasks, which extend far beyond the tool, instead of attempting to memorize shortcuts within the tool.
July 19, 2006 - Process insights from IxD list
From John Schrag on control of initial design
One thing we've been doing with some success is getting all these people together not for a 'design' meeting, but for a 'requirements' meeting. This keeps everyone focused on the problem they're trying to solve, and not how to solve it. I ask questions like "What should the user be able to do when we finish this that they can't do now? What other features does this have to work with?". When the discussion gets to UI design (as it always does), I say "I've noted that idea, but let's not worry about details of the UI design until we get all the requirements down."
I find that it is useful to have developers, marketers, QA, etc involved at this stage, because they are often aware of technical, competitive and business requirements which are beyond what your user studies might have shown.
We design the UI outside of that meeting, and then usability test and refine it. Then we bring it back. We still run into debate about the UI at this point, of course, but it's powerful to be able to say "Well, it meets all the requirements we came up with together, and it tested really well. Which part of that do you want to change?"
From Dan Saffer
Alan Cooper in one of his books suggests that interaction designers should have two reasons for every design decision they make. The reason, he says, is for just this purpose: when people want authority over your design, you have ammunition. Otherwise, your "opinion" is just that, and everyone, right or wrong, can have one.
From Russell Wilson
On one product we have had the ability to do this (define the vision early) and I've had quite a bit of success. However, I'm encountering much more difficult issues when redesigning existing products where there are many problems, little to no conceptual integrity, but developers are *defensive* of their existing work.
From Sabine Junginger
You might have already tried this, but from my experience it is very effective to demonstrate the consequences of the conceptual *dis*integrity from a user's perspective, documenting the resulting disconnects and detours in terms of the user pathway. Many developers do not understand these consequences until they hear it directly from the people they think they know so well. Once you introduce the user, user pathways and user experience, the tension is no longer between the old "designers" (which is what most developers consider themselves to be) and the new design experts, but about the need to make it easier and more enjoyable for people external to the organization to use their products.
From Lada Gorlenko
Think big and fight big. Separate design critical decisions from the rest. Trade non-critical decisions, if they buy peace and progress. Don't come across as someone who always wants to be right about design, even if this is exactly what you are paid to do. Come across as someone who fights only when the fight is worth it.
From leo frishberg
So, let me start by using my favorite counter-argument to the notion that the embedded software and hardware team should have an opportunity to opine on the UXD: "Would you like my input on the chip layout? Would you like my opinion about your object classes?" This usually causes them to pause, laugh nervously and we move on.
I have had inordinate success here in wrenching "design" (specifically UXD) from the development team for several reasons:
1) The group tried several different strategies prior to my arrival (this took many years of different trials-by-error) before they figured out that they really didn't know what they were doing
2) The group also determined, through these experiments, that they needed a professional immersed in the science and art of IxD/UXD.
3) They also figured out that they couldn't do this with part-timers (either contractors or individuals from our central engineering team) because of the need for deep domain knowledge.My "success" results not so much from my own "genius" or "great design" work (I haven't really had the time to show off anything that would cause anyone to gasp in astonishment), but instead from the team's active engagement in sincerely trying to improve their design/development process and failing with every attempt to date.
With that said, however, I haven't been sitting idle for two years. Instead of rushing in and attempting to revolutionize the application interface, I suggested that we needed a solid body of user-centered research to help guide us. Note the 1st person plural. While it was primarily ::me:: doing the research, I made sure that development / marketing team members accompanied me whenever possible.
During the very frequent feedback sessions to the team about the research progress, I revealed to them patterns of use that they found simultaneously familiar and surprising. An odd mixture, but one that helped establish my credibility: "Our users are doing such-and-such - sound familiar? But we aren't providing an interface to support that activity....why not?" I suppose that this dovetails with the discussion about requirements gathering mentioned so far. But it goes beyond that - it is changing the culture of the development team from focusing on ::me:: and focusing instead on bona fide ::users:: a critical shift if I'm going to get them to stop opining about what the UI ::should:: do.
With that foundation established, it has been relatively smooth sailing to begin changing the interface; in some cases radically. The conversations I have with development are predominately around what is technically feasible, where the big infrastructure "gotchas" are and so forth - exactly the rich discussion that should be going on. In addition, the marketing and development teams are required reviewers of the UIS, and I'm very glad for it. Both functions have found holes in the spec, seeming contradictions, apparent violations of O/S standards, etc. which only numerous pairs of eyes can find. Thankfully, in all of the reviews, very little discussion about what the UI "should do" have come up; instead the presumption is that the proposed UI is good for the user and we need to make it even better.
From: Mark Schraad
1) Sometimes the engineers are right, and it is worth giving them some real consideration.
2) If you are an ethnographer debating a positivist (sometimes qualitative vs. quantitative) it helps to be have sufficient expertise in the oppositions camp. This establishes credibility and allows you to debate with a common language.
3) I have had great success using evidence. And, qualitative is evedentury. I have also had better success with cognitive speak than behavioral speak. To many, cognitive is perceived as science and behavioral as art.From Dave Cronin
- Base your decisions on ethnographic research. I've found few things that silence critics as quickly as apt anecdotes and observed behavior patterns.
- Define (and agree on!) the problem before proposing or evaluating solutions.
- Figure out constructive ways for the whole project team to participate early enough in the process to entertain divergent thinking without it becoming counterproductive. I'm not necessarily advocating playing with legos or brainstorming (though those are both fun).
- Depersonalize solutions by focusing on serving the needs of personas/user models/roles/whatever you like to use (i.e. it's not about "my idea" versus "your idea," but about serving the needs of "nancy.") This also helps with the defining the problem bit.
- Be willing to throw your ideas out. If you're a good designer, and you've got a strong solution to a complex problem, my experience is that nothing is going to freak the team out more than going back to a blank slate. After about 5 minutes they usually come running back to what you proposed (whether they give you credit for it is another question ;).July 10, 2006 - Meaning of command buttons for dialog boxes
Robert Hoekman asked:
Somehow, before I started with my current employer, a decision was made (arbitrarily) to use "OK/Cancel" buttons for everything they applied to, regardless of whether or not something else, like "Apply" or "Save", would offer more meaning.
.... Any ammo is good ammo.
How about some heavy bullet-points molded at Microsoft's armory?
Jack Moffett wrote: "One issue I've had with Okay/Cancel, and even more so with Yes/No, is that you have to read the dialog to be sure of what you are committing to."
True, and this truth is reflected in the recommendation for dialog boxes from Vista UI Design Guidelines (the guidelines, incidentally, are very reasonable):
- "Use positive commit buttons that are specific responses to the main instruction instead of generic labels (such as "OK"). Users should be able to quickly grasp the options by reading the button text alone. Always start commit button labels with a verb."
Do not show the guidelines themselves to your employer, Robert, since within the same section one of the illustrations appears to contradict the recommendation. Oh, well...
The issue with dialog in the illustration is systemic: if you replace 'Yes', 'No', and 'Cancel' buttons with more direct 'Save', 'Discard', and 'Cancel', there will be semantic clash for 'Discard' and 'Cancel' buttons.
The root of the clash is in the different scope of 'Cancel' and the other two actions action. While 'Cancel' applies to dialog regardless of content (like 'X' button in the upper right corner of window), 'Save' and 'Discard' are actions related to the content, yet visually they are not separate from 'Cancel' button. This is an example of problem, which was created by Visual Designers for Technical Writers, and which should have been fixed by Interaction Designers.
Solutions:
- Specific: Spell out 'Discard Document'.
- Generic (for all dialogs in Vista release): Visually separate 'Cancel' from content related command buttons.
July 4, 2006 - What followers can do to express their pesonality
Kat's two cents, worth their weight in gold:
I'm fortunate in that I get to dance with some really great dancers pretty regularly. When that is the case, then I am comfortable enough to explore options with more finesse. playing with my hips more, breaking down steps to tiny parts, fancier flourishy bits, whatever. I find now that often my voice is most effective when it is shown in tiny ways that only we might notice. But that can only happen when the dance is more of a conversation than an excercise with a machine that does rote patterns. I don't think most followers have that opportunity very often.
You can still develop a voice without that, but I think it has very little to do with waiting for pauses. It has to do with finding minutia within every step that you can make your own. the way you move your foot, shift your weight, close your legs, hold your partner's hand, etc. and all those things are almost easier to focus on when you're dancing with someone who's not showing off or trying to make you work for it. clearly, that can't happen all the time. but it definitely doesn't need to wait for a pause.
"the way you move your foot, shift your weight, close your legs... playing with my hips more, breaking down steps to tiny parts, fancier flourishy bits..." - these are the things I pay attention to and teach advanced follwers.
July 3, 2006 - Process and people
No process will substitute for talent and for human relationships. It must be obvious, but often it isn't (due to peculiar property of human mind to look for the simplest uniform solutions). And so the self-evident reminder is due here: Process is not solution, it is only facilitator - it can remove some of the hindrances to personal contribution and to effective team work, but it will not replace talent. Emphasize outcomes, play to personal strengths and process will evolve around available personalities.
July 2, 2006 - In defense of Vision-Centered Design (Activity-Centered Design vs. Human (User)-Centered Design)
Stimulating if meandering article by Donald Norman: Human-Centered Design Considered Harmful.
The starting postulate is simple: human centered design process is well suited for incremental design improvements – it evaluates if and how design idea conform current set of user expectations, current user goals, mental models, practices. Human centered design process is less suitable for evaluation of disruptive technologies, ideas.
This is not limitation of process per se. This is due to natural limitation of our human mental abilities (and, by the way, relates to recent thread on cognitive load): we have hard time imagining alternative outcomes.
According to Klein’s book on decision making, when we construct mental simulations we are limited to three changing objects interacting for six consecutive steps. Disruptive ideas, technologies are disruptive precisely because they don’t fit with the rest of common expectations, they re-arrange many more than three existing practices in novel ways. The corollary, born in history, is that we, humans, are notoriously poor predictors of future developments of disruptive technology ("The phonograph has no commercial value at all." - Thomas Edison, 1880s; many books are filled with examples of this phenomenon).
Robert Reimann writes: "I would argue that understanding human goals in the context of products and systems provides the clear vision of the end result that Norman finds elusive, while significantly mitigating the risk of failure. I believe that this understanding comes from well-developed user models that capture the essence of human behaviors and motivations pertinent to the design problem at hand."
----------------------------------------------------------
Given natural limitations of human mind, Norman’s concerns about constraints of evaluations used in HCD process appear to be well-justified. The crucial questions, unarticulated in his article then are these: “Who is going to be the judge of applicability of disruptive design idea?”, and: “What is his/her track record as far as disruptive ideas are concerned?”
----------------------------------------------------------We know the answer at Apple (Steve Jobs). The answer to these questions doesn’t mean that human centered design process should be discarded (here is where Norman went wrong), rather that it should be applied with gusto where there is need for incremental improvements. There are many, many areas where this is true. On the other hand, negative results of HCD user modeling and evaluations should always be taken with doubt, and possibly dismissed by stakeholders whenever disruptive technology is suspected (here is where Norman went right).
Finally, activity centered design process should be encouraged as long as it’s own limitations are understood: it is not a magic bullet - ACD removes focus on current user expectations, and thus might facilitate innovation, however someone (human, not process) still has to dream up the crazy idea, which may or may not be viable after the venture capital financing runs out.
Or as Norman states: "Great design, I contend, comes from breaking the rules, by ignoring the generally accepted practices, by pushing forward with a clear concept of the end result, no matter what. This ego-centric, vision-directed design results in both great successes and great failures. If you want great rather than good, this is what you must do."
An interesting follow up question then is this: "Which technologies could be disruptive today?". I will not break any new ground if I say digital appliances, designed for specific activities. Hm, "designed" for "activity" - "Activity Centered Design"?
-----------
As I said in the beginning, the article is meandering: there are interesting observations on dynamic nature of interaction, and on error handling, on system approach to design - all of these can and should be addressed within framework of HCD process.
 |
|
|
|
|
|
||||||||||||||||||||||
|
|
|
|
|
|
||||||||||||||||||||||
|
|
|
|
|
|
|
|
|
|
||||||||||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
