machinespace

machinespace = the networked information space of ever-increasing complexity that humans have to interact with.

August 24, 2004

user requirements = business requirements ?


The Reader might be interested in perusing a previous article titled "UI design myths revisited" dated 08/23/2004, particularly Myth # 10, to gain additional context regarding this posting. Also, for definitions of terms used here, please refer to the machinespace glossary in the August 2003 archive.

...For some reason, there is a myth that has been persistent for years - that somehow an user's requirements for an application or a web site is somehow different from all the other functional and non-functional requirements. UI designers and Usability gurus have done their bit in making these "user requirements" sacrosanct and somehow different from the vulgar system requirements demanded by the business.

User requirements are no different from any other requirement - because they define the needs of a human user, it is even more important that user requirements be stated along with the rest of the requirements, and describe what it is that the user will need from the application in order to effectively fulfill their personal and business goals. After all, the user ultimately will function as an integral part of the business system, providing inputs, requesting outputs and making decisions based on their interactions with the rest of the system components.

Users are usually the "control" components of a business system, and as such, trade-offs need to be negotiated with the other components during function allocation based on the designers knowledge of the user's strengths and limitations in terms of experience, skill, workload, work environment, physical condition, etc. From a systems perspective, an application or product is "User Friendly", "Usable" or provides a "Positive User Experience" if a FAVORABLE balance is negotiated with the other components, and "Unusable" if the balance negotiated is UNFAVORABLE to the human components of the system.

Most user requirements are in some way related to the functionality, since the user is trying to fulfill a business need through the use of the application's functionality - ie, user needs usually build upon the basic business need for the specified functionality. For example, if there is a business requirement to be able to print a document from an application, the functional requirements usually define what the print function needs to be able to do in order to satisfy the business need - ie, should be able to stop and start printing, preview and zoom, specify printers, specify paper etc etc.

The usability/user requirements further builds upon the functional requirements by adding specific requirements for the user to be able to access & control each of the Print function features for the application to be truly useful to the user and fulfill the business needs. Thus, there is a close relationship between usability requirements, accessibility requirements, functional requirements and the underlying business needs. In fact, many cases, they are the same.

A lot of the confusion arises from an analyst mistakenly mislabelling a PERFORMANCE requirement as a Usability requirement. Performance requirements are of 2 types - system performance and user performance. System performance can be stated in terms of hard numbers - ie constraints on load time, data base access etc. User preformance is most often stated as a usability goal, such as target time to perform a task, number of errors etc etc. But these are NOT usability requirements - they are Performance Requirements that the system and its users have to meet in order to satisfy a Business requirement.

It should be understood that Business Requirements (i.e., the ultimate reason for the initiation of a project or service) are not necessarily limited to being something to do with the "core business" of the company - Business Requirements can encompass Operational requirements, Legal Requirements, Security Requirements, Performance Requirements, User requirements and of course, Accessibility requirements which, strictly speaking, are a sub-set of the user requirements.

Depending on the needs of an Organization at any given time, ANY requirement can be elevated to be a Business Requirement. For example, if a Company decided that it was going to mandate Section 508 of the Disability Act (Accessibility) compliance as a general company policy for all applications built in-house or purchased from vendors, then Accessibility becomes a Business Requirement.

What remains to be defined is the extent of the functionality that is needed to comply with the new Accessibility Business Requirement i.e., should the application support ALL disabled users or does it need to accommodate only the Visually handicapped users? Does it need to accommodate impaired motor skills or hearing disabilities? etc. These decisions can be made based on the actual need, ie, number of business users in the company that suffer from a disability, and the kinds of disabilities that exist within the organization.

It would make no business sense for a company to expend a large amount of resources and effort to make an application Section 508 compliant for visually handicapped users if there are no such users in their customer base. Thus the functional requirement could just be limited to accommodating a hearing impaired users and motor skill impaired users.

(note: the foregoing is just an illustrative example, so don't jump on me if the above hypothetical company makes a business decision to save money by making an application partially accessible. heh heh).

_____________________________________
copyright 2004 ajoy muralidhar. all names, websites and brands referenced are the copyright/trademark of their respective owners.

August 23, 2004

UI design myths revisited

Eons ago - uh, actually, make that 2001 - Dr. Paul Smith, a HCI professional at IBM's Toronto software lab wrote an interesting paper titled "Debunking the myths of UI Design". The good doctor updated it in early 2002, with fresh insights.

Reading it again in August 2004, I was struck that many of the same misconceptions Dr. Smith talked about are still prevalent now... you'd think that with the hard knocks the industry has taken in the aftermath of the Big Bust, we'd be well grounded in reality by now.

Anyway, I was wondering if my fellow UI designers felt the same way.I know we have made a great deal of progress over the years, and although I probably still cling to an irrational belief or two (the irrationality just proves that I'm still human, after all. machinespace hasn't assimilated me completely - yet)

I'll start by restating the myths that Dr. Smith originally listed, and then discuss them one by one with my interpretation of each in terms of current realities. There are some myths and misconceptions still left to debunk and destroy.

Myth 1: Design is a Luxury
Reality: hmmm. No way. Design was never a luxury, even if it is narrowly applied to just the UI. Design of a website or application goes far beyond the UI, making everyone involved in the development project a designer of sorts. However, even if we take the "narrow" definition and limit it to just the User Interface, design cannot be considered something "nice to have, but not really needed". Even if we were to disregard an aesthetically pleasing UI, the customer demands at the very least, a well laid out, easily understandable, clearly marked interface. That's design, isn't it? And what of the client? they don't consider the protection of their company image and branding a luxury, do they? Things have definitely changed... User expectations for web sites and web based applications are so high now, and demands excellence in design. Mediocre doesn't cut it anymore, even if it meets all functional expectations. And no, we aren't even in the realm of "experience" here - just basic expectations.

Myth 2: Developing a customer solution is just conceptually and logistically too big to tackle; people working at the solution level will get bogged down in unmanageable issues. You should develop the product as a set of components, and then organize your development team to mimic the product.
Reality: That may very well be true - developing a complete solution is challenging, and requires the cooperation of the whole team. It is very easy for people to scurry off and build their little components and bring them back to be assembled, but this leads to duplication of work, missed requirements, integration problems etc etc, let alone having something that works as a seamless whole. If there is anything that we have learnt in the last few years, it is that the application or web site information architecture and system architecture have to be worked out fully, with all the interaction between the various components accounted for. A solution cannot be considered valid if it does not meet this criteria. The Development team should understand the product as a whole, and should not be broken up at the component level. Failure to do so will result in a product or application that may be functional, but which is difficult to maintain, upgrade or scale.

Myth 3: User interface design responsibility is best distributed within components. Each implementer designs the user interface for his module.
Reality: We know that this is a sure recipe for disaster... the application as a whole needs a consistent look and feel, and having each component developer design the UI for their module will result in a hodge-podge of design styles and runs the risk of visually and logically fragmented.

Myth 4: User interface guidelines solve the problem of distributed design.
Reality: Guidelines have their place, and serve a useful purpose. A designer depends on his or her past experience in creating a design and irrespective of what a design guide may recommend, that designer's interpretation of the guide is ultimately what is going to be in the design. The application look and feel itself may be dictated by corporate identity standards, but the application interactions should allow for some flexibility in interpretation for the UI designer and the developer. Making the guidelines more rigid does not work - they cease to be guidelines and become specifications, limiting the designers' options. Worse, strict guidelines may influence designer behavior adversely, resulting in cookie cutter solutions for every problem.

Myth 5: Teamwork happens.
Reality: Who are we kidding? We've known for years that application development for the internet cannot be factionalized, but to this day we cannot get beyond labelling each other - we're still UI designers, web developers, business analysts etc etc etc. This sectarian approach to application development is non-productive and wasteful of resources. Team work cannot happen in an environment where there are differences in perception of the importance of each other roles - a UI designer is not more important than any other team member, no matter what their level of involvement. The first step to true teamwork is to accept this fact. The second step is to acknowledge that we are just the steward of our primary tasks -The ownership of each component of the solution (whether it's the UI, databases, hardware, whatever) is with the whole team.

Myth 6: Human-computer interaction experts should carry out both design and feedback activities.
Reality: Not true then and not true now. Who are the experts anyway? Are they not practitioners like you and I? Does years of immersion in the internet world somehow give us a special insight and perspective on the merits and drawbacks of one approach over another? Expertise and education does not free us from bias... not by a long shot. Since we aren't talking about just UI design here, I'll admit that the HCI expert as designer can do a great job in designing the information architecture and planning the interaction models for each user interface, in order to provide the best possible user experience - but unless the HCI specialist is also trained in graphical arts, I'd leave the visual design to a graphic designer. Intranet based applications which already have a defined UI look and feel " corporate wrapper" don’t count, of course, unless there is are some unusual display needs to be accounted for. As for carrying out the "feedback" - the HCI expert cannot compare to the subject matter experts drawn from among representative users and support personnel. It is advisable to solicit feedback from as many types of users and stakeholders as possible, since no HCI specialist can possibly acquire the necessary depth of business process knowledge to be able to account for every possible interaction.

Myth 7: Software companies generally assign usability a high priority.
Reality: High priority yes, but only as it does not impact production schedules. In a crunch, the company's need to make their products "feature rich" seems to override the need to make the existing features usable. Much effort is spent on making the added features functionala at any cost, so marketing can claim that they are available in the product - even though they may be inconvenient or non-intuitive. In most cases, Usability is the first casuality of the shrinking budget or slipped schedule, and although the usability situation has improved vastly over the years due in part to the relative ease of upgrading web sites and web-based applications. Software Companies generally want to project an user-friendly image and are willing to do a great deal to accommodate their user's needs, since usability is equated with acceptance and thus increased sales. They are keenly aware that their competition would use any usability deficiencies as a weapon in their battle for market share. Still needed - Usability to be viewed as a non-negotiable business requirement on par with Performance.

Myth 8: Industry pressure requires a full-court press on the current release.
Reality: Nope. Not at all... The phased release model with a product being released with core functionality only, and then upgraded over a series of followup releases seems to be working - especially if upgrades can be provided at a low or reasonable cost (and of course, all security related patches being provided in a timely manner free of cost). Anti-virus software makers, Yahoo Messenger, MSN Messenger etc have been using this model for years now. Also, the acceptability of the updates is enhanced if it is done unobtrusively without affecting ongoing tasks, and the user is permitted to retain control over downloading and installation. However, I have noticed that this approach seems to work better for Utility software that business or entertainment software. These classes of software have a better chance of succeeding if they are " functionally complete" when they are released, and upgrades are aimed at improving experience rather than functionality.

Myth 9: Successful software companies develop technology, package it, and market it. The packaging is essentially assembling available parts into a customer solution.
Reality: Successful companies, by definition, are those who provide Customers with usable solutions that meet one or more business needs - whether they choose to do so by assembling an application from parts and components they have laying around, or by designing something from scratch to meet a specific customer's need. The solution offered has to be stable, innovative and offer definite cost and resource advantages over the existing or currently utilized technology or process. No amount of marketing hype or fancy packaging can get away from that simple truth - to provide the customer with what he or she wants. Sometimes, the need may be there, but a customer may not be willing or able to expend the resources that are needed to acquire the solutions that are most suited for their business needs - a successful company is one that is adept at recognizing the constraints that their potential customers are bound by, and offering solutions that help them work around the constraining factors - flexible solutions that can grow as their customers need grow, without requiring a huge investment in money, time and people resources. Solutions have to be truly customizable down to the last step. Pseudo-flexibility (or is it quasi-flexible) doesn't cut it. A company that can provide such flexible, scalable solutions at a reasonable cost will have the widest customer base, and thus the greatest chance of success.

Myth 10: Usability and functionality have separate requirements.
Reality: This one deserves a separate article, so please see the article "User Requirements = Business Requirements" dated 08/24/2004
____________________________________
More to come - watch this space. Dr. Smith discussed 21 myths in his paper, so we have a bunch more to explore :)

for those who are interested, the original paper may be downloaded from the IBM site. Here's a link.. I commend IBM for making their archives available. They are a great resource.
http://www-106.ibm.com/developerworks/library/us-myth.html

_____________________________________
copyright 2004 ajoy muralidhar. all names, websites and brands referenced are the copyright/trademark of their respective owners.

August 18, 2004

the two faces of Usability...

It's ironic, really. For years, we shouted from the rooftops about usability and its importance, and beat everyone to death using the end-user as a club.... finally, due to the sustained efforts of the design community and the usability gurus and of course, the dozens of books touting the value proposition of the big U, usability practitioners finally had what they always wanted - acknowledgment, responsibility and authority, to make sure the little guy is protected from the big bad developers… yes, I left respect out of the list. That has to be earned, not demanded.

Then what happened? Usability was the first member of the user-centered design proponent family to make the business case for their inclusion, and no sooner did they get corporate recognition and funding, they promptly forgot about the other members of the family.

They forgot their colleagues working as human factors practitioners, information architects, interaction designers, visual designers, prototypers, content developers etc etc, and went off to buy themselves expensive equipment and set up laboratories, test facilities and such… they set themselves up as a "quality function" to test designs for "usability".

They developed strategies for testing of software and web-sites and carried out extensive studies, pointing out all the things that were wrong and making their recommendations for change. They even set up a organization for Usability professionals.

Of course, it wasn't an exclusive club, anyone could join and play their reindeer games, but the vast majority of professionals in our field who saw themselves as design strategists, information designers, architects etc, and could not relate to what Usability was evolving into.

but wait.. wasn't Usability supposed to be about helping building great, user centred products? to be full partners in the design and development, and not just the evaluation? But alas… Usability had mutated and evolved, and now we have two Usabilities - usability engineering, and usability testing.

those who chose to go the usability testing route soon found that had burnt their bridges with the design and development functions, and are now seen as some kind of Inquisitors whose job it is to subject applications to hellish tortures.

usability engineering still remained in the domain of the designers, human factors professionals and information architects even though they did not see themselves as "engineering" usability - they were busy struggling to translate requirements into designs that met the end-users needs while juggling the constraints of project schedules, business and technology requirements.

If applying the design principles they knew resulted in a product that was deemed user-friendly and usable, they were happy. Usability testing became a barrier to be crossed in the design process, much like any critical review or quality testing, not as design partner.

It wasn’t intended to be that way.. it just happened. The fact that IT personnel and Management saw usability testing as akin to formal software testing did not help. Usability testing became powerful, but they became isolated.

at first, they rationalized their isolation from design with such platitudes as "we need to be objective, we can’t get involved in the design… etc etc" . Very true, and necessary to maintaining objectivity, but it did not give them the design clout they thought it would.

oh, they have plenty of clout in corporate America and elsewhere in the world… clout enough to stop a product from launching, if need be… but the policing powers were never what they wanted in the first place, but since they lost their place in the design arena, they are struggling to regain a foothold, since it is all too easy to bypass formal usability testing and get a product launch with various other flavors of semi-formal and informal user testing.

after all, all that seems required to qualify a product is the endorsement of a bunch of representative users. Qualitative results seem to work just as fine, and products on a tight production schedule would rather not have another hurdle to cross on the way out the door.

we have only ourselves to blame for this… we have the same qualifications and skills, but we do not wish to see ourselves as members of the same family whose roles are complementary and supportive of each other - the laboratory is only a location where usability is measured and documented, not where it is created.

usability is built into products and applications at many, many places in the product design lifecycle, beginning with the planning and function allocations and going beyond deployment. usability test findings and recommendations are just one more piece in the complex puzzle.

How can we correct this situation? we need to embrace the philosophy of usability, not its processes. There are very many processes in design, but the underlying philosophy of making applications and products easy to use is a common goal for all of us, whether we are analysts, designers, human factors practitioners, usability professionals or developers - remember, the philosophy unites us while the processes divide us.

The usability focus needs to shift from the "testing" mentality and to the product usability as a whole, engineering usability into products, while working closely with the rest of the development team from beginning to end.


We need to stop seeing each other as as barriers, but as enablers. It's not too late to step back and reassess ourselves, and find ways of cooperating better, and moving together towards our common goals. ______________________________________________________
copyright 2004 ajoy muralidhar. all names or brands referenced are the copyright of their respective owners.

August 17, 2004

Lessons from a webvet - Nico Macdonald

Nico Macdonald runs Spy, an UK based consulting firm. He's been in the trenches a long time, and over the years he has garnered nuggets of web wisdom which he presented at the University of Huddersfield to Multimedia Students earlier this year. The presentation was longer, and had much more context, of course.

I've paraphrased Nico's lessons a bit to save me some typing.. any inconsistencies or errors you notice are mine alone. Please excuse my impertinence, Nico.

Lesson 1: There are no absolute rules. All principles need to be interpreted according to the situation

Lesson 2: It is not print, and it is not about aesthetics

Lesson 3: Web design starts with a pencil

Lesson 4: Start off with something worth criticizing. You can't build up a design by starting with usability. "Usability is good at optimizing a given design. It can sand a rough chair into a smooth one, but it can't sand a table into a chair." quote from Robert Reimann, quoted in What is Web Design?

Lesson 5: Designers as leaders - you have to give your users credit for knowing what they need, and they may adapt what you create (paraphrased)

Lesson 6: Designers need to understand clients and their business and communicate effectively. Clients have other things to consider as well as your concerns. Design isn't always the most important thing. (design has a brief and a client, art may have a patron but there is no brief)

Lesson 7: It's important to understand technology. Engineering is part of design. Engineers tell you how to do something, designers look at what to do.

Lesson 8: The solution is less important than the planning and documentation for site support and development

Lesson 9: Web design cuts across organizational boundaries. Are we designing services and organizations or just a web site?

Lesson 10: The medium in which you work is not a given. The Web is not always the right solution.
______________________________________________________

copyright 2004 ajoy muralidhar. 10 Lessons of Web Design copyright Nico MacDonald of Spy.

defining interaction

periodically, I go back to the basics and think about the definitions of terms that I have become used to, and have been using in a matter-of-fact way. I like to reflect on my understanding of terms that are bandied about in the field of information architecture and UI design.

what do we mean when we talk about "interaction" in the context of UI design?

limiting myself to interactions beween a human user and an information system represented and enabled by the internet/world wide web, to me, interaction is the manipulation of controls provided by an application or appliance user interface to add, modify, process or delete information to achieve a stated or unstated personal or business related goal.

yeah, yeah.. for any sticklers out there who need more clarification, by information applications, I mean web sites, search engines, forms, transactional applications and I include 'hard' physical device controls such as device butons, scroll wheels, and touch screens along with 'soft' widget controls represented within applications.

now let's take a quick look and look at how the term interaction is understood by the world at large...
____________________________________________________________
The process of control and feedback between the user and hypermedia system.
www.nosh.com/resources/gloss.html
hmm. a good basic definition. does not imply engagement and involvement. surely a systems engineer was behind this one :)

Exchange of information, ideas, opinions between and among learners and teachers, usually occurring through technology with the aim of facilitating learning.
www1.worldbank.org/disted/glossary.html
ok. at least it defines the context. a learning environment.

A situation in which the effect of one factor depends upon the level of another factor. Interactions are included in statistical models whenever the factors do not act in a purely additive manner.
www.statlets.com/usermanual/glossary.htm
a statistical definition. dry as ground chalk. ugh.

Two independent variables interact when changes in the value of one change the effect on the dependent variable of the other.
www.twocrows.com/glossary.htm
another one of those. double ugh.

In the context of teleconferencing, the give and take between participants in different locations. Though not widely recognized, it is the meeting element that turns lectures into learning situations, and is often an essential ingredient in the success of a program. (paraphrasing Novak)
citl.tamu.edu/citl-glossary-main.htm
hmmm. again, since it at least states the context. Give and take implies active interchange of data/information. Important to understand that all interactive situations do not turn into learning opportunities.

An interaction occurs when the effects of two or more variables in a regression analysis or two or more factors (in an analysis of variance) are not independent of each other. For example, you may find that the effect of a treatment is not the same different sexes.
obelia.jde.aca.mmu.ac.uk/multivar/gloss.htm
argh. another statistical definition. too many of these round. there's a zillion more physics related ones.

Mutual or reciprocal influence between two or more similar organisms or individuals of different species. Major interactions are: competition, mutualism, predation, parasitism, amensalism, and commensialism.
www.geog.ouc.bc.ca/conted/onlinecourses/enviroglos/i.html
that's interesting. we have a taxonomy. now what kind of interaction should we as designers be shooting for?


A behavioral specification that comprises a set of message exchanges among a set of objects within a particular context to accomplish a specific purpose. An interaction may be illustrated by one or more scenarios.
swiki.hfbk-hamburg.de:8888/MusicTechnology/24
ah ha. definitely interaction, but not necessarily human. could be a pure machinespace transaction. we need to humanize this one some more.

Interaction is a measure of the estimated number of trips that will be generated between origins and destinations for a particular activity. Interactions depend upon the properties of the origin to generate a trip, the property of the destination to attract a trip and the cost of traveling between them.
www.esri.com/library/glossary/i_l.html
ok, ok.. this one is even more diffcult. but it raises an interesting issue - ascribes a "cost" to the interaction. so, if the cost of an interaction exceeds the value generated by the exchange of information, the activity should cease to occur. so, low-cost interactions = good, high cost = bad. I have to think on this more... is low cost interaction the same as "ease of use"?

Ok. enough of this lame-brained exercise. I've had my fill of definitions for today.

my point? there are are many definitions of interaction out there as there are specializations in scientific endeavour. Just because we understand it in one way, does not mean that it means the same to everyone else. You might start off by finding out what your clients mean when THEY talk interaction. extend the courtesy to all those who are around you... you might be surprised.


when you talk interaction, make sure you are very careful to specify the context.. it'll make your life so much easier. Our first task is to be usable to our user groups. if they don't understand you, you can't be very effective.

yeah, it's kinda like having a team member who is extremely skilled and willing to do anything you ask them to, except that they only speak and write in a language that no one else can understand. sign language will suffice for simple messages, but you really can't have a conversation.

we all need to talk in the same language. don't always expect them to learn yours, you might be better off learning to express your ideas in their language. go git em, tiger.

next time: defining usability

______________________________________________
copyright 2004 ajoy muralidhar. all names or brands referenced are the copyright of their respective owners.

August 16, 2004

from utility to emotion...

I wrote this a while ago, when advance notices of Don Norman's book "Emotional Design" were first published… but I hesitated to post it.

I admit it. I was afraid to say anything that would look like I was criticizing the sage of design philosophy. Now that Stephen Hawking has recanted his theories about Black Holes,* I figured that this is the year for recantations of long favored theories.

Dr. Norman finally admits that man does not live by utility alone - but does not acknowledge the legions of designers who have been saying so all these years. In the area of web design in particular, visual designers with a penchant for designing to appeal to the emotions have been made to feel that they were breaking some sacred and inviolable law that functional usability comes first, last and everything in between.

Granted, losing sight of functionality isn't going to get a product, web site or software very far… but neither is ignoring aesthetic appeal, marketability, image and branding. A bland, functional, utilitarian world does not sell.

It's not as if this is a sudden revelation - I am sure that Dr. Norman has struggled for years to reconcile the opposing aspects of design appeal - the rational with the emotional aspects. He speaks of visceral needs … his endorsement isn't needed for the acceptability of something graphic artists, industrial designers and marketers have known since the dawn of advertising.

The "gut" sensation we all feel when we see a certain product or service which gives us the "gotta have it" feeling has been around since Thag the caveman first walked into a dealership buy a plain old knobby club and the salesman talked him into taking a few swings with the all new multi-function lightweight small-form factor club/attitude adjustment/disemboweller with a non-slip "softgrip" handle. sexy design sells - it's cool, works well and you want to be seen with it.

Lets face it... We are very much driven by our senses…. Our rational side tells us that one car is the same as another in terms of its basic functionality, but why does a BMW sports model leave us panting?. Oh. Cost does matter. We do not throw all good sense and caution to the wind in making our choices, but we are willing to stretch ourselves financially in order to possess a cool gadget or car or whatever.

I would not go so far as to call Dr. Norman's current position as a "turnaround" as the Guardian newspaper called in their article about him back in March 2004 here's the link, hope it still works….
http://www.guardian.co.uk/online/story/0,3605,1166467,00.html.
Don't get me wrong… the man who wrote the "Design of Everyday Things" and is a legend in our field was never that far off from where he is now - but his efforts in favor of functionality gave designers who focused on emotional aspects a bad rap.

We swung too far to one side.. now, with his influence, we can swing back to where we should be - the middle, and aim for that elusive balance that is good design - functionality balanced with form… form and function are the Yin and Yang of design, neither one leading or following.
___________________________________________________
*oh, he did admit he was mistaken, but then called the residual radiation which disproves his theory 'Hawking Radiation'. Which proves one thing - you CAN have it both ways.

Check out the articles about his recantation. Made a huge stir in the scientific world…

http://www.newscientist.com/news/news.jsp?id=ns99996151
http://us.rediff.com/news/2004/aug/03hole.htm

and by the way...

utilitarianism = doctrine that the useful is the good; especially as elaborated by Jeremy Bentham and James Mill; the aim was said to be the greatest happiness for the greatest number
www.cogsci.princeton.edu/cgi-bin/webwn

as for Thag, he's an old friend - remember Gary Larson's cartoon The Far Side? I often use him as a point of reference... as in, what would Thag the caveman say to this?

_________________________________________________

copyright 2004 ajoy muralidhar. all names or brands referenced are the copyright of their respective owners.

design solutions and the UI designer

What is design?

Hmmm. We could go off the cliff here, if we aren't careful. Design means many things in different contexts, so we should qualify the question by defining design in the context of its application. Since I am currently helping produce web-based software applications, let me talk about design in the context of software development.

I could be more specific and limit the discussion to designing for the web environment alone, but that would limit us, especially since a great deal of the application design for the web is dependent on the operating system and browser that is being utilized. Some day in the future, our computers will be reduced to network appliances that will be not have any resident software at all.

So then… in the context of software development, design is generally the second stage in the development life-cycle, after requirements analysis. The design stage of the development life-cycle determines how the required functionality can be achieved.

In contrast to the requirements/analysis stage which concentrates on what functionality is required, the design stage provides an opportunity to the design team to explore how the functionality can be achieved. In the design phase, a team may come up with a number of design solutions that could potentially meet the stated requirements. Each of these potential solutions represents a structure that needs to be analyzed in terms of implementation details.

What does this mean? It means that the design team now has to analyze each potential solution that has been proposed for its feasibility and justifiability to the client (customer) and users in terms of its cost in time, resources and money; efficiency, usability, flexibility, code/component reuse; supportability over the estimated life-cycle and adaptability to changes driven by market forces and technology evolution. Thus, the team needs an analytical process to evaluation each potential solution to arrive at a final (preferred) design solution to be able to provide recommendations to the customer/users.

It would be well for us as design team members to remember that in spite of careful reasoning and anaysis, and even though the solution we propose may be optimal, an organization may decide to adopt a sub-optimal or modified solution based on other, non-quantifiable variables that may have changed the business environment during the design/analysis processs.

Often, the less-than-optimal choice may be the result of caprice or lack of understanding on the part of a client representative (human, after all) or due to prior commitment made as part of another project that cannot be changed or revoked. Most of the time, sub-optimal choices are made because of incorrect assumptions, a poorly defined requirement or because of information that was not provided during the planning or requirements analysis stages.

As part of the design team, the UI designer is tasked with providing the best possible interface to the application to the users that meet their task requirements and satisfy the business goals. Since there may be several possible design solutions, the UI designer has to work with the team to develop interfaces that will work with each solution - it would be great, of course, if the analysis proceeded rapidly and the team was able to discard some of the solutions prior to UI design, and reduced the possibilities to just one or two.

Ideally, the team should be able to discuss the pros and cons of each solution to the client and arrive at the best possible solution in the early stages of design, prior to the UI being prototyped. I've noticed that in many cases, the documentation and discussions related to the anaysis and recommendations are too abstract for the client representatives and user representatives, and graphical representations (mock-ups) of UI screens do not always get the subtler advantages and disadvantages of each potential solution across.

In such cases, the UI designer would benefit from being "in tune" with the rest of the design team and getting a feel for the "preferred" solution that will be most likely chosen for implementation given the circumstances. Designing an UI in isolation, when there are multiple potential solutions will lead to frustration on the part of the UI designer, and confuse the client further - for example, an UI designer may develop an interface for a solution that he or she feels will be most "user-friendly" and still meet business requirements, while the rest of the team may be considering a solution that meets business requirements and rigid security requirements, but may be sub-optimal in terms of "user-friendliness".

Instead of becoming a battle of wills between the UI designer and the project team, with the "user" being the bargaining chip, it would speak well for our profession as a whole if we were able to take a solution that is sub-optimal in terms of user-friendliness and make it more usable through our creative efforts.

Remember, anyone can design an "user-friendly" interface for optimal conditions - all you need is a set of guidelines and common sense - it is when we come up with a good solution under sub-optimal conditions that the mettle of the UI designer is tested.

Besides.. Your willingness to co-operate and work as a team member will gain you support from all involved parties, and make it easier to provide input and modifications to the solution based on your analysis and expertise.

After all, that IS the ultimate goal… being effective and a valued team member. Not the outsider.


_____________________________________________________
copyright 2004 ajoy muralidhar. all names or brands referenced are the copyright of their respective owners.

August 14, 2004

Shedroff and design...


Nathan Shedroff's Unified Field Theory of Design

Nathan's information interaction design theory and his attempts to develop a unified field theory of design was the inspiration years ago for my quitting United Defense and the Bay area and moving to Chicago to take a position with Neoglyphics in Jan 1998.

Back then, Nathan was running Vivid studios, in San Francisco and he and his team were already legendary. IDEO was beginning to play catch up with them and others of the same ilk.

The paper on Unified Field Theory of Design from which this image comes from is 10 years old now.. he wrote it in 1994. How quickly time passes. Blythe Miller who graduated from De Paul in Chicago and interned at Neoglyphics went to work for him in 1998.

Vivid was aquired by Modem Media back in 2000, when the feeding frenzy was at its height, and companies like Modem, Agency, iXL and Sapient were growing exponentially by acquiring small and medium sized talent-rich houses.

The paper is much longer of course, and develops his ideas further - eventually, it became a chapter in the book Information Design, edited by Robert Jacobson and published by MIT Press. More on that later....

Nathan went much further than that, of course - he developed his theories, and published Experience Design 1. He continues to work, teach and speak in the Bay area.

____________________________________________________

copyright 2004 ajoy muralidhar. all names or brands referenced are the copyright of their respective owners.

August 12, 2004

affordance and usability

here we go again...

I was thinking about 'affordance' and 'usability', and was wondering whether there are really barriers to designers creating affordable interfaces.


I rooted around, and dug up a few definitions to make sure my understanding of the term affordance was the same as everyone else - and voila, I have one from the sage himself...

from www.rha.com/ui_design_glossary.htm


Don Norman sayeth "the perceived and actual properties of the thing, primarily those fundamental properties that determine just how the thing could possibly be used."

Alan Cooper refined this definition by omitting "and actual", identifying perception as the crux of the problem.

"The whole point is that, through a combination of instinct and experience, we expect objects to behave in a certain way based on their appearance and we have very strong expectations if we've used an identical object before. If a designer violates one of these expectations, their user will suffer frustration every time they use the interface."

other definitions of affordance on the Web:

from www.parc.com/istl/groups/hdi/sensemaking/glossary.html
"An affordance refers to a physical property of something that influences how it can be used. For example, the affordances of paper include its properties for being viewed, it's light weight, and so on. The nature of a handle on a door determine how one open the door - by pulling, or pushing, or twisting, and so on."

and from http://www.slostc.org/topics/usability/definitions.html

"Perceptual characteristics of an object that make it obvious what the object can do and how it can be manipulated."

and yet one more...
from http://ei.cs.vt.edu/~cs5714/glossary.html

"an aspect of an object which makes it obvious how the object is to be used."

1. Which brings up some interesting questions - why put the perception burden on the UI alone?

2. are there any recent studies on the affordance of currently favored widgets? after all, when designing a web based application, we tend to use lots of widgets other than the standard buttons - dropdowns, multi-column list boxes, treeviews, list boxes etc etc.

3. Can working (ie, application grade) widgets be "walk up and use" - ie, provide complete affordance without having any instructions other than the widget interface itself.

4. So, if an interface is affordable - ie, a user can determine instinctively how the controls on the interface can be manipulated, the UI is "affordable" - but is it usable yet?

5. Does affordability of an UI provide the user with enough information to carry out a task, if they have never done it before?

In Alan's definition, perception is the key - if the user perceives the logic behind the layout of the UI, and is provided with the requisite information regarding the sequence of operations to be performed on the UI, then they should be fairly confident of being able to complete their tasks without further training or instruction - of course, a bit of online help never hurts, but can be limited to FAQs, not necessarily a demo training.

Which begs another question -

6. if applications are designed to provide user affordance, why would Organizations need to train people over and and over when they build or modify applications?

Training would be needed only to familiarize users with any process/workflow changes, not on the application UI. If a user has a good sense of how the application should work, and the User interface provides affordance based on that expectation, then they should not have any problems using the application.

Ergo, there you have it - The UI should not have to bear the burden alone. Not if the organization wishes to have a productive usable tool, productivity applications need not have a "wow" factor - it's okay to set up expectations early on, to reinforce affordance, and then build to that.

if affordance is determined by perception, does it not make sense to influence perception in whatever way we can?

Granted, we cannot do this for an application that will be used in the "public" domain - ie the wide wide world of the internet - but within the closed confines of a corporate intranet, with its captive users, it is definitely possible. I'm not ruling out the possibility of applying this method on a public web app, it could work.

corporate users of complex applications over an intranet chould have some "early" instruction (all it training or whatever) in the product design cycle to familiarize them with the new or modified application workflow before the application is ever developed.

I don't mean formal training, just an opportunity to understand and develop a fairly robust mental model of the process... could be as simple as a relationship diagram.

so.. first we design the new/modified application workflow, fine tune through discussion with the client and representative users, then broadcast the workflow/process to everyone.

the design, prototyping and evaluation, development progresses as usual, but the difference is that we have set up "new" expectations, and since we will be building to those expectations, the UI will make more sense, and require less effort to learn to use, since we will be meeting the expectations of the users...

all we will be doing is reinforcing what they already know what to do - just providing the users with the tools to do carry out the process they have been familiarized with.

nothing new here. it's been around for a long time, folks.

it's called collaborative design.

_____________________________________________________
copyright 2004 ajoy muralidhar. all names or brands referenced are the copyright of their respective owners.

August 11, 2004

thriving in machinespace...

oh, it's not as impossible as it seems. machinespace is an artifact, after all, although it is vaster and darker than any continent ever explored.

ostensibly, it was intended to make life easier for us all. and it does. imagine a life without computing or communications devices. simple, yes. fruitful? doubtful.

of course, if you deem a fruitful life to be one that lives in harmony with one's environment, giving back to nature what we take from it.... an idealistic view, but not very comfortable.

imbalance is what creates tension in the system, and its tension that provides energy - energy to innovate and create.

After all, how many scenes of plants and flowers do you see in the artwork of primitive man? nature was all around him, of course.... but do you see herbiage and representations of plants? nope.. it's animals you see - animals that he hunted, some bigger and much more dangerous. idyllic pastoral settings do not make for innovation. stability and safety perhaps, but not innovation.

So.. that brings us back to "thriving in machinespace" - we created it, we can control it.. we can navigate it, and we can use it to grow...

are we smarter now than we were a generation or two ago? in terms of exposure to knowledge and information, definitely yes. In terms of learning to apply that knowledge and information in a constructive manner, definitely no.

at this point, we still are at a state of imbalance - there are differences in the extent of our immersion into machinespace - it is ubiquitous yes, but still not at the point where we cannot control its penetration into our lives. that will come in about 20 years. we can still step out of the wilderness of machinespace and onto the familiar non-connected spaces.

in the meanwhile, those of us who live more or less immersed in machinespace in our professinal and private lives can map the new terrain, laying out markers, drawing up maps, building roads and shelters.

yes, this is how a UI designer/information architect should view themselves - guides for those who will eventually populate and settle in the wilderness, and build great things....

onward, UI pioneers.

________________________________________________________ copyright 2004 ajoy muralidhar. all names or brands referenced are the copyright of their respective owners.

August 09, 2004

usability ayatollahs

All right, I said it. You know the ones I'm talking about. The Renowned Ones, the defenders of the Faith, the givers of the Law....The Ayatollahs of Internet Usability - the holy ones that dictate the law to the design community - tell me,please... where do they come from?

Have they ever worked on anything other than "informational" websites? Do they understand the typical corporate environment? Do they know how much damage they have done to our profession? True...they have indeed helped a great deal in making corporate decision makers aware of the importance of usability and user experience, but it is at that point that they outlive their usefulness....

Can someone...anyone...please send me examples of web-based applications that these Ayatollahs have developed?

The books, articles and pontifications in the hands of their devoted followers, who, on purchasing their favorite gurus's latest book suddenly deem themselves competent usability/UI design practitioners.

They then promptly jump in headfirst where angels fear to tread, and the result? IT project teams and project managers who are extremely wary of "user centric design" and UCD designers who want to help them develop a "usable" product.

Think, people... user centered design does not mean that every thing else is trampled underfoot. There are business needs to be met too, and technical constraints that have to be addressed.

Usability is NOT the exclusive domain of the so called UI designer or the Usability practitioner. No developer, designer or analyst worth his or her salt ever sets out to design an "unusable" product - the design solution has to be owned by the whole team, not just the UI designer or the usability practitioner.

A large part of a UI designer's work in a project team environment tasked with developing a complex application is in negotiating with the business analysts and the technical specialists - remember, they care about the end-user too, so don't treat them like total idiots. Work with them, and they will work with you.

And as for the Ayatollahs, please remember that their writings are not Scripture. An application designer with a good sense of his audience, and a fair understanding of requirements is a far worthier ally that all the books about usable design that were ever published.

don't be the usability high priest - be a team player. results matter.

________________________________________________________ copyright 2004 ajoy muralidhar. all names or brands referenced are the copyright of their respective owners.

August 02, 2004

findability

"Findability" of information has always been one of the holy grails of the Industry, … findability of information that can help make decisions, manipulate other information or generate other information. The very best search engine is of course, NO search engine - if information can be presented as needed, based on intelligent agents that can infer what information will be needed the moment that an User takes up a Task.

So, you see…. Every search engine there is a wannabe "find engine" - however, every method that we use to narrow down a mass of information - ie, through classification, filtering, searching, shortcuts, preference, most used etc etc can also be classified as Finding. It is possible of course, to build a website with the only navigation provided being one of the above methods (classification after all, is what leads to us deciding on navigation hierarchies).

Morville is right inasmuch an user who is offered the choice of a beautiful, tastefully laid out aesthetic site, with the most pleasing layout imaginable, but with information buried all over; or a stark site with minimal considerations to aesthetics, but with all emphasis on functionality - powerful search, shortcuts etc - the user will almost always choose the ugly site over the beautiful.Treasure hunts are fun, but not on an enabling website.

Think of it in this way - there are 2 aspects to it; the first is finding what one wants (findability) - then the ability to use that information (actionability). Real usability would be if we could optimize these two - whether this is done through standards, guides or whatever; if we lose sight of these two, and focus on the "rituals" of usability rather than the core precepts, the essence is forgotten and lost.

It all boils down to which site has a better "findability" quotient - if in our efforts to make a site more "usable", we add layers of hierarchies, and lay too heavy an emphasis on the way the user is going to use the information after they find it (actionability) through task analysis and streamlining of workflow, while letting "findability" be determined by design constraints on navigation structures, or the skill of the developers -the user ultimately loses.

A balanced site is what we want to shoot for - a fine balance between findability and actionability. Will usability, then, be far behind? Morville is an acknowledged "great" in the field, but I do believe that he has found something else to focus on, instead of looking at the problems underlying the philosophy of usability as a whole.

_______________________________________
copyright 2004 ajoy muralidhar. all names or brands referenced are the copyright of their respective owners.