Will companies finally realize that SOA must also incorporate UEA (User Experience Architecture)? Let's revisit next year.
Will companies finally realize that SOA must also incorporate UEA (User Experience Architecture)? Let's revisit next year.
The definition of ‘Simple’ requires a whole discussion…but typically, simplicity can be afforded by reducing the amount of pre-requisite knowledge the user needs to have and the number of decisions the user needs to make before taking action.
I got one of these laptops, and it is a marvel of vision and technology. It reminds me the first time I encountered a Mac Classic, back in 1986.
A quote from a recent article (1):
“...When you search for a crow on Google, you find plenty of references to people named Crow and people who crow about things, and that doesn’t help when you’re studying the bird,” Dr. Parr said..."
What should we expect? A mind reading Google that knows one is looking for Crow the bird, and not Crow the actor?! Results should include both to cover all bases.
It is the lack of context, or rather, the lack of opportunities to provide context during the search flow that leads to poor results. Moreover, even the more sophisticated approach that facilitates narrowing results through faceted browsing does not scale when the categories of knowledge are inclusive, overlapping or cross-disciplined.
Search is easy when both user and search agent know the answer as well as the question BEFORE the search executes. By that I mean the the user KNOWS what the answer should be. This is like searching for your car keys: You know what it is, you don't know where it is. When you find some keys, you know which is a car key.
When the search object is less defined and the search engine confused due to ambiguity, there is, naturally, a lower probability for a satisfactory result yield. Similar to grabbing the key chain a building engeneers carries, things are more complext because there are gazillion keys and they all more or less look the same. Which is the right key?
While a lot of thought is given to providing better interfaces for narrowing and navigating results, little seems to be on on the interface of search input -- the initial oppertunity to provide context.
(1) 'Helping Computers Search With Nuance, Like Us' , NYT, Peter Wayner, Sept 12, 2007
Public libraries offer all children access to an environment that facilitates life long acquisition of knowledge through simple, consistent and accessible interaction patterns. In contrast, public library websites and Online Public Access Catalogs (OPACs) for children are often not accessible and lack age discriminating features to support appropriate reading-level and comprehension skills.
A library interface that is sensitive to these categories of young readers and can filter in a meaningful way is an important step towards children’s independent navigation. In order to accommodate varying reading abilities in the library interface, librarians would have to ensure that the bibliographic records of their holdings are cataloged appropriately. Nonetheless, the effort required to introduce new cataloguing practices for children’s books is worthwhile because it can significantly enhance the ability of the interface to support children’s independent use of the library online catalogue.
But what to do if you don’t have a sibling and you really want to get the cool mark? Kill another relative, or better yet, a complete stranger, and here we are, today, far from world peace.
Lack of context is to blame for misinterpretation of symbols and signs.
I bet kids do not understand the meaning of this sign, although they know its function. We understand cultural disconnects, especially of the sad ‘Tarzan’ type where the supposedly primitive third world is perplexed by our modern one. But as the last sign demonstrates, the ‘modern’ is not immune to exposing its mortality. Suddenly you experience being old if you remember the Telephone.
But the wheel is reinvented all the time, and for good reasons.Consider the wheels in your life: In your car, train, airplain, bikes, rollerblades, elevators, shopping cart, Blackberry, iPod...They all share the 'wheel' attribute - circular objects that spin to afford action.
But the context of use requires innovation and consideration of the object's other properties, such as materials, size, degree of freedom, etc.So reinventing the wheel does make sense sometimes, because you don't want your airline to be equipped with Flintstone’s era tires...
I typically pretend to read the cars magazines they have here while listening to mundane conversations, but today my face is glued to the screen as I type.
This entry was composed on my Blackberry, you see.
So I got to think about 'Experience' vs. 'User experience', an old issue, similar to armchair travelers-bloggers, doers-dreamers?
"I like to watch." Being There, Directed by Hal Ashby.
In over two decades of practicing user interface architecture in one form or another, I sought to infuse some consistency and methods in measuring the success of new user interfaces, compared to those being replaced.
In recent years, standards such as NIST CISU-R (NISTIR 7432) provide much needed guidance in the areas of usability requirements and testing, but so far I find this approach very effective, especially when dealing with large, complex interfaces.
The universal usability matrix that I present here provides a method to estimate the impact of a current user interface on clients and end users, and how a new proposed interface compares. Replacing the typical anecdotal, qualitative assessments that a current UI is 'bad' or 'inefficient' or 'Not user friendly', the matrix affords:
The matrix typically includes 3 sections:
An important aspect of the usability matrix is in its ability to provide context to different customers. Especially relevant to UI of enterprise software where very small and very large sites need to be supported, and when the software is deployed globally, and large variations in workflows and definitions exist:
Usability Profiles provide the context for the universal usability matrix. The profiles are used in evaluating the Task Impact score. Each task has an associated ‘cost’ in terms of the time it takes to complete one instance of the task (efficiency), the time it takes to perform the task repeatedly as required to process all students. (Productivity), and the associated usability profile. Profiles have properties and attributes that are most relevant to the project.
There is no limit to the number of profiles used, or to the number of properties associated with the profiles. However, I found it best to limit the number of profiles to those that reflect the most typical clients. The process of developing the matrix is most successful when practical. Too many profiles have diminished returns since typically most attention is focused on the extremes.
Here is a basic, and in my opinion generic and reusable template to develop a task priority score. I use Excel or a Filemaker database to document the actual interfaces:
Attributes: Annually, Monthly, Weekly, Daily
Attribute Weight: 1,2,3,4
Note: The higher the Occurrence, the higher to weight.
Attributes: 1 to 10, 11-30, Over 30
Attribute Weight: 1,2,3
Note: Number of times the task is performed during Occurrence period. The higher the repetition, the higher to weight.To isolate Task Frequency use Occurrence X Repetition
Attributes: Less than 1 minute, 1 -2 minutes, 3-5 minutes, 5-10 minutes, 10-15 minutes, Over 15 minutes
Attribute Weight: 1,2,3,4,5,6
Note: Estimated time to perform a single task instance without exceptions. The lower the efficiency, the higher to weight.
Attributes: = Efficiency x Repetition x Occurrence
Property: Task Priority Score
Attributes: = Productivity
Finally, I am sure of that someone, somewhere may have developed a similar idea - I would love to know. Otherwise, feel free to use and extend this framework.
I just got a Blackberry Curve yesterday. I've had a chance to play quite a bit with the iPhone and I find that the two devices offer distinctive, different and yet valid approaches to the user interface challenge.
While the Curve does much more than the iPhone and costs less, it does not support direct manipulation and rich data visualizations/transformations that the latter offers.
The user experience of these two devices is thus fundamentally different, and cannot be generically summarized as a form over function issue. Yet, as usual, it ends up being the CONTEXT of use that determines acceptable usability trade offs.
Direct manipulation is most effective when one can concentrate on the device with both hands and visual focus. It is less effective when one is involved is other activities like driving or excerscsing. So if the context of use IS the iPhone, direct manipulation makes sense.
Marshall McLuhan's "The Medium is the Message" comes to mind. The iPhone's user interface is the focus on attention, not the actual task that is expected from the device as a phone. This is a contradiction to good ui design that, at least in my mind, needs to be transparent to the user.
Whis entry is not a critiscisom of the iPhone. Realizing we are in an evolving world where a shift is taking place from hardware to software, to Human.
In his monthly coulmn 'Technically Speaking' (February 2007, American Libraries), Andrew Pace wrote:
It was this time in the transatlantic flight: I finished most of the food on the tray, breaking my promise to myself to avoid airline food... The little piece of cheese I actually hate, smiled at me from under the organized mess of plastic containers, carefully refolded napkins (to save space, don't you know...) and food leftovers. The temptation was hard to resist, the promising red glow of Cellophane under which hiding a soft yellow cheese I hoped to like this time!
In front of me set an older genteman whoes face I could not see, and I noriced, through the tiny space between the seats, that he was intensely reviewing his sophisticated looking soft cheese token.
I instantly lost interest in my cheese and focused on him and his cheese, trying to predict next steps. Clearly, I thought, this person does not fly often. Perhaps even, this is his first flight! So to him, everything is new, sophisticated looking and even frightening.
After a little while the man unwrapped the cellophane, but little did he know how complicated life can be: He was now turning between his fingers a round red piece of something. He turned it left, and right, up and down for a few long seconds.
Finally he just took a bit into the wax and immediately put the thing on his tray. I could not see his expression.
OK - So he did not figure out that in odrer to get to the cheese, one is supposed to pull on a string that's embedded in the layer of red wax, peel the wax and undress the hidden treasure - the soft yellow cheese. It is a bit of culinary striptease at 40K high in the sky, and I can not get this instance out of my mind, especially when thinking about interaction models and task design...
User's possible thought process:
Not surprisingly, “Seek and you shall find” has been the catchphrase of successful search engine vendors. This maxim encapsulates the main thrust of successful interaction within the commercial domain: task A (seek) directly leads to outcome B (find). This interaction model is vectorial—its directionality is governed by the wish to achieve the optimal outcome.
Based on the vectorial interaction model, successful commercial search engines eliminate the vast landscape of the Web by providing patrons with a 'relevant' result set, quickly — on the first results screen and often in the top record. The fact that these search engines simultaneously provide an entirely unusable result-set of hundreds of thousands of records further emphasizes the underlying goal of providing the single relevant match for the search.
Given a result-set of workable dimensions (e.g. 25 links), the user would have been likely to explore it, but the paradoxical combination of results presented by the commercial search engines does not offer the user real choices. Rather, it conditions the user to view the action of searching and its outcome as inseparable, providing an instantly gratifying experience packaged as a volitional choice process.
Different from the “Seek and you shall find” vectorial model, is a model of user-collection interaction characterized by the phrase “Seek so you can find”. Here, the relationship between task A (seek) and task B (find) is more reciprocal and dynamic. It suggests a spiral interaction model in which the outcome emerges as a synthesis enabled by the search process. Whereas the vectorial interaction model works well for commercial search engines, I believe that the spiral interaction model is more appropriate for the academic and scholarly domains.
Commercial search engines help users find a needle in a haystack—and this has never been easier. Google’s ability is amazing even to those who understand its underlying technology. Nonetheless, finding a needle in a haystack (vectorial model) is not, in fact, such a big deal when you have the right equipment—a magnet in the case of this analogy. Only the needle attaches to the magnet while the haystack becomes immaterial.
Most research and academic electronic collections, on the other hand, are serving patrons who are interested in finding a piece of hay in the haystack (spiral model). The magnet becomes useless; the key functions of assigning relevancy and ranking of information become dependent on human capacities such as critical evaluation, synthesis, and decision making.
First posed on: Thursday, September 14, 2006
In his book The Memory Palace of Matteo Ricci(1), Jonathan Spence describes a memory system devised by a 16th century Italian Jesuit priest. Matteo Ricci’s goal was to find a way to store in one’s head the sum of all human knowledge, so he suggested the following idea: Depending on how much one wants to remember, one can build in one’s head virtual urban centers of various sizes. These imaginary cities should be complete with fully furnished palaces, homes, public meeting places and so on.
Each one of these imagined spaces would serve as a memory location to reference a piece of knowledge. It would be possible “to walk” through this vast mental construct to access this or other item or bit of information. Five centuries later, I find Matteo Ricci’s idea fantastically intriguing and completely relevant rich knowledge applications and UXD.
First posted: Wednesday, September 06, 2006
It appears, however, that while academic electronic collections have grown exponentially—and often as a result of significant institutional investment, the utilization rates for many of these collections remain lower than expected. Computers and broadband networks are ubiquitous, patrons are computer savvy, and researchers are excited about the potential of electronic resources--what then stands in the way of greater utilization of electronic scholarly collections?
Driven by substantial industry investment, significant advances in e-commerce over the last few years dramatically changed users’ expectations for usability and quick gratification during online sessions. Many institutional libraries, on the other hand, are facing shrinking budgets and diminishing resources just as the raising popularity of commercial research tools makes the success of academic collections increasingly contingent on enabling quick and easy access to the wealth of resources they offer. For collection developers, this situation suggests the need to take a closer look at the user interfaces that provide access to their collections.
Icebergs and Penguins
Icebergs are a good metaphor for the relationship between collections and the user interface. Like icebergs, most collections are largely invisible. The user interface, or the tip of the iceberg, does not reflect the actual scope or depth of the submerged mass. Some collection portals attempt to attract patrons by using gimmicky interface designs intended to create a contemporary look—these are the penguins of our metaphor.
Still, server log analyses, used like the underwater equipment necessary to explore the submerged mass, often reveal that only a small chunk of the collection is ever used. Analyses of inter-library loan requests support the frustrating realization that patrons remain unaware of much of the content available in the collection.
The iceberg problem can be framed as follows: What can be done to facilitate interaction patterns that help patrons realize the discovery potential of the available electronic resources and, by extension, justify current and future investment in the collection? I believe that the answer is in the user interface.
In what follows, I would like further to explore the conceptual and strategic relationship between the user interface and collection utilization. Utilization, along with usability and accessibility, are no longer the obscure jargon of narrowly technical discussions. Increasingly these terms permeate the electronic resources discourse. Yet the topics they represent often remain only loosely connected to the efforts of many collection developers.
This is understandable given the traditional separation between content and containers, or the collection and the technology that makes it available. Organizational structures often reflect and reinforce the boundaries between content and technology, making it difficult to establish effective communication between decision makers on both sides.
The resulting disconnect between the visible and submerged parts of the collection “iceberg” can lead, not only to decreased utilization, but also and more problematically, to an inversion in the relationship between collection development and improved usability and accessibility. Connecting Tip to BaseCollection developers often conceptualize the value of their collection for patrons in terms of quality and scope.
From this perspective, the collection development process tends to focus on uniqueness and growth. To achieve uniqueness, collection developers use their domain expertise to guide the direction of further investment in subscriptions and other electronic resources with the intention of creating collections that are unique in quality and strength. Growth is related to richness and wealth of content concentration—two central factors in making any collection authoritative and influential in its particular domain.
The centrality of growth (whether highly focused, widely inclusive, or both) as a means to increase the appeal of the collection is further highlighted by the unprecedented availability of new content and an apparently matching increase in demand. Uniqueness and growth are inherent in the mission of collections and constitute key motivators for collection developers. Yet despite being key attributes of collection development, uniqueness and growth become problematic when considered from the perspective of the delivery and consumption medium for electronic collections—the Web.
To explain this point, I will first examine the role of growth using the concept of “zero sum gains”, which I borrow from economics. Zero sum gains means that in some circumstances, the value of continued investment can diminish to the point of becoming meaningless. With billions of pages indexed on various search engines, the Web is a medium to which the concept of zero sum gains clearly applies—especially from the perspective of the end-user.
Growth is meaningful only if the end-user realizes that an increasingly large number of resources is available in the collection. Consequently, it is quite possible to invest in the growth of a collection without attaining a comparable expansion of its utilization.Uniqueness too is a complicated construct given the pace at which competing alternatives emerge on the Web. The co-modification of information on the web inevitably implies susceptibility to high substitution rates.
In other words, the cost of switching from one website to another is minimal to the end-user. To understand how the low cost of switching affects the relationship between uniqueness, investment and utilization, let us contrast electronic collections with brick and mortar ones. In traditional museums or special libraries, we can see uniqueness in action.
For example, the availability of a Vermeer masterpiece in a certain museum makes that institution a unique destination for Vermeer fans and scholars. Yet the availability of a digital impression of the same Vermeer masterpiece in numerous digital collections does not make any of them a unique destination.
On the contrary, each of these collections runs the risk of becoming interchangeable with all the others. I am not suggesting that considerations of utilization, accessibility, and usability displace uniqueness and growth as guiding concepts and motivating principles in the process of collection development.
Rather I would like to integrate the two perspectives represented by these concepts. Much like the two differently positioned but nonetheless inseparable parts of the iceberg, a scholarly electronic collection and its user interface constitute a single entity. In the remainder of this article I will consider how we can implement an integrative framework—one that can facilitate a dynamic interaction between the development of content and user interface—in the discourse on electronic collections.
I propose that we begin with a closer look at the patron, or the user in the user interface construct. ConclusionIcebergs dissolve overtime--their size diminishes until they finally melt away--and so will the iceberg problem discussed here. Collections will become highly visible through the implementation of user interfaces that would be developed with industry standards and metadata protocols.
These interfaces will support interaction models that fit the unique requirements of their patrons for knowledge synthesis through interactive and accessible direct manipulation.
It's a very ancient saying,
But a true and honest thought,
That if you become a teacher,
By your pupils you'll be taught.(1)
The daunting task of finding a needle in a haystack has never been easier. Or, so it appears. The web and in turn Google, Yahoo and other search engines (to which I will refer as Yogles) liberated a previously untapped human desire to locate obscure bits of information for personal consumption. Suddenly, millions of people are researching not only best airfare, pet rocks, organically correct coffee beans and lovers, but also complex medical conditions, dietary supplements or the secret life of Barbie and Ken. And the amazing thing is… this stuff can be found!!!
An activity that used to be limited to academic and research settings and required years of training and specialized knowledge is now reduced to the phrase “Google it!” This is probably good for Human Kind, but if you are developing sophisticated federated (or meta) search software you are in trouble. While scientific search still requires expertise to navigate the exponentially growing sea of knowledge, users increasingly demand the task to be as simple as Yogle makes it appear.
The user interface problem for the developers of federated search tools can be described using the agricultural haystack metaphor. Finding a needle in a haystack can be easy if you are equipped with the right tool, say a powerful magnet. This is what happens with Yogles--the magnets. MetaSearch tools try help with a more complicated task. It involves searching for a particular piece of hay in the haystack; clearly, a magnet is not as effective. Here, we face a challenge of a higher magnitude.
Developers spend a great deal of effort and imagination on creating fantastic search engines. But these, like all engines are buried under the hood, and most of the work done by the tool is transparent to the user with the exception of speed. The users, on the other hand, care little about HOW the search is done, and more about WHAT is found. The Yogle user interface underscores this gap: a single search field is very easy to use but the results often include thousands of records, and there are absolutely no organizing tools to manage a retrieved set or past results.
The rational for this minimalist approach to the user interface may be that a particular engine can be so good that what you are looking for would be displayed on the first screen and even in the first line. The problem is that the information displayed on the first page or line is often based on what OTHERS were looking for. In other words, it is easier to search for a coin under the light post, but what if the coin you are after is on page 75,233 out of 270,008?
By becoming a de facto standard for searching, Yogle’s user interface inflicts users with high expectations for ease of use and satisfaction in accomplishing a search task, even if the search task they need to perform is as remote in complexity and scope from the common search as an Amoeba is remote from Humans. Moreover, while the starting point of the search process has been popularized and has now become familiar to millions, we still lack widely accepted interaction patterns for organization and management of large sets of retrieved data.
In order to build a successful user interface for a federated search tool, developers would benefit from understanding the mental models that users create in order to deal with the entire search process. The process of profiling users--building use-case libraries that describe user types, scenarios of use, goals, workflows and outcomes--is common to software development. The problem with modeling for federated search UI is that many of the users themselves lack a clear mental model of what search, retrieval and analysis mean! In fact, a wide majority of users may not know what a federated search means.
Most software applications enable users to perform familiar tasks. As such, software represents the next level in the evolutionary ladder of productivity. For example, the word processor replaced the typewriter, and both advanced letter writing from the use of the pen, pencil, and feather. The introduction of e-Mail further reduced delivery speed and made the use of paper optional. Despite all these changes, the task itself--communicating in writing has changed little since its inception. Users are able to perform with software familiar tasks that have predictable outcomes. When the user’s perception of the task is closely replicated in the user interface, the application is perceived to be intuitive.
For most users, however, meta searching electronic data is not a familiar task. Users have to negotiate a lot of new technical information, such as terminology, scope of search (where are we searching), the impact of logic (AND, OR, NOT) on the result set, how ranking is determined and so on. Further, the absence of established workflows and interaction metaphors complicates mapping federated search activities.
The Yogle search engines excel in mapping to a common search structure. They work well when we know what we are looking for, but just don’t know where to find it. The challenge – and yes – the opportunity for developers of meta search tools is to come up with a successful user interface metaphor that encompasses the complete discovery process and reflects a wide range of user skills and expertise in searching for knowledge. The user interface of federated search tools requires a revolutionary rather than an evolutionary change, and it can only be achieved through collaboration among developers, librarians, patrons, and other stakeholders. We may even consider changing the name for this class of software to “MetaDiscovery Tools” to project a notion of a complete process that covers the search-retrieve-analyze-manage cycle.
1) From the soundtrack lyrics for ‘Getting to know you’ in the movie ‘The King and I’
Note to the reader: This is a reprint of my talk at ALA summer 2004, Orlando, LITA Pre conference Friday, June 25, 2004 Usability Issues in MetaSearch Interface Design
Imagine interfacing with an expensive keyboard that has dozens keys, most white, some black and none labeled. Each key performs a different function and numerous key combinations are possible. It takes years of long daily practice to become proficient and instructions are written in special code that requires years of real-time decoding expertise. Finally, this keyboard is a real pain to fit on the seat tray of an aircraft even in first class.
Welcome the piano user interface. In fact, we are surrounded by funky interfaces in our homes, workplaces, cars--mostly facing the challenges they present without much objection. (On this topic, I highly recommend Donald Norman's insightful book "The Design of Everyday Things", about the psychology of interfacing with common objects, i.e. doors, faucets etc.) But why is it that users seem to accept challenges such as the piano interface, which has not changed for centuries, while developers are compelled to work on improvements to the user interface of software?
Any software that has been around for several years has to accommodate substantial increase in functionality introduced by creative development and customers needs. Eventually, the interface itself may reach a saturation point that renders evolutionary changes to the design obsolete, and requires revolutionary approach.
Think of it as a house that was originally built for a young family. The kids have all grown and have families of their own, but they insist on staying in the house. Rooms and sections are added where possible to accommodate all residents, and everyone is happy. There comes a time, however, when providing newcomers to the family with a map and some written instructions to help locate the kitchen doesn't cut it anymore. Other solutions are required.
Unlike architecture, the design of software user interface has a short history and it involves only two common interaction types: The Command Line Interface (CLI) facilitated by the keyboard, and the Graphical User Interface (GUI), facilitated mostly by direct manipulation of objects on the screen.
CLI places significant burdens on the user's memory. It requires storage and retrieval of the application's functions dictionary. As a result, a novice user may require a long period of internalization but can gain substantial increase in operation speed over time. The GUI provides the novice user with instant access to most major functions through direct manipulation of objects such as menus and buttons. However, requirements for eye-hand coordination are high and operation is relatively slow because the user needs to locate functions on the screen, then move, point and click the mouse in order to operate the system.
These actions cannot be optimized significantly over time. Moreover, in a desktop environment, the large muscles of the hand are required to perform very delicate and precise motions for which they are not designed. Holding a mouse and staring at the screen for long periods of time, and the need to switch frequently between keyboard and mouse, result in discomfort and even potential injuries to the user. GUI may be dangerous to your health...
ATM machines are a good example for the successful implementation of GUI: These devices support a small set of secure workflows, each with predictable outcome. Interaction time is short and a touch screen affords genuine direct manipulation. Users are prompted with relevant feedback such as "You have no funds in your account" and can cancel an operation before it is executed. Finally, the chances to get a receipt for cash withdrawal but no actual money are very small.
In contrast, Expert Systems complicate the lives of interface designers and their users. Only a fraction of functionality can be displayed any given time, limited by factors such as screen size, network bandwidth, server load and visual load. Additionally, and most importantly, many of the tasks and workflows are not trivial. They require knowledge both of the task and of how the system affords the task--two items that often do not correlate. The software can perform a particular task, but the user interface does not offer an easy way to get to it. Increase in functionality reduces the effectiveness of graphical interface and increases the load on short and long-term working memory. Training and retention are a real issue as well as standardization of workflows across an organization. Most Expert Systems have a high learning curve that is closely linked to the limitations of the user interface in bridging the expert user with the expert system.
We have a long way to go before Microsoft Windows and other computing de-facto standards change to facilitate transparent correlation between work-related tasks and system functionality. Until such developments occur, work with real users is a methodology that can insure successful interfaces.
First posted on: Friday, September 01, 2006
Optimum, there, is defined as "The point at which the condition, degree, or amount of something is the most favorable."
Development of user personas as means to model interaction context, is becoming a common UXD practice. Indeed, relativity makes the 'best of all possible worlds', or 'The optimal UI for a particular application', a bit hard to define, unless context is established for user and interaction model.
But what is the difference between a persona and a stereotype?
A persona is contextual. AHD's definition: "The role that one assumes or displays in public or society; one's public image or personality, as distinguished from the inner self."
Stereotypes reflect a more rigid, non-contextual construct: "A conventional, formulaic, and oversimplified conception, opinion, or image." (AHD) One needs to be aware of the danger in mixing persona with stereotype, yet, be aware that good interaction is based on ease of learnability, often gained by consistency and reuse of interaction patterns.
So, a library of personas will make sense. But will the personas become stale and stereotypical?
First posted on: Thursday, August 24, 2006
A few years ago, while waiting at Heathrow for a connection flight to the US, I struck a conversation with a Nigerian who was setting up a Malaria foundation. Before he boarded his plane to Lagos, I volunteered to help with the foundation's website.
Over the next couple of months we communicated via email, and the site went up here: http://www.malariafoundation.org/. After that, we lost touch, and as I visit the site from time to time, it is clear that it has not been touched since the launch.This experience is similar to other experiences I had, where there is a great deal of enthusiasm to do good, but it is hard to follow up - both for me and for the organizers, in upkeep and long term maintenance.With little technical and organizational resources, I think there are many thousands of 'Sitewrecks' - websites setup by foundations and nonforprofits - who do not make it through the long voyage of on-going maintenance.
The solution is to set up a grass-root movement, similar to 'OpenSource' that will connect talent from all over the world, with organizations, and help with that. I am talking about a long-term relationship, not just to setup the site. Perhaps such an effort exist already?
First posted on: Monday, August 21, 2006
I help organizations realize their strategic vision for a world-class user experience.
An expert in transforming large-scale, data-driven systems into device/OS-agnostic UX frameworks, I advise management and stakeholders on strategy, tactics, and logistics involved in such major efforts. From concept to detailed design, I lead and manage highly contextual, responsive UX architectures that support cost-effective personalization, customization and localization.
I enjoy solving the numerous challenges entangling complex systems, and draw on my wealth of experience with the cultures of Fortune 20 to small companies, where I led B2B and B2C efforts in the financial, education, insurance, aviation, healthcare, telecom, publishing, research, manufacturing, and software industries.