The Shared User Vision...

One thing that have been discussing off and on has been Alan Cooper's “The Inmates are Running the Asylum.”  En route to OOPSLA, I decided to pickup this book again and I have finally finished reading it.  The last time I left it off was in Chapter 9, which was discussing the importance of user-centric design by use of personas and instead of thinking of software in terms of the features that it could provide, and that it was much more important to concentrate on the goals that the user had.  Accomplishing this requires some interaction design, which is what the next portion of the book deals with.

Alan states that the developers often confuse tasks with goals.  Tasks, he defines, are the steps that are done to accomplish goals, but unfortunately developers usually design user interfaces to complete tasks instead of accomplishing goals.  Take a step back from the context that Alan is talking about, one of my courses at OOPSLA has been with Kevlin Henney, and he reminds us that when developing object oriented software, the getters and setters are generally not the proper abstraction for an object.  More specifically, his example was for a Bank Account, where the methods provided are getBalance() and setBalance().  While this is a very powerful interface, this is not the proper abstraction to use, especially since in this case, the object could change state between the initial get and the final set.  As such, a better interface would be a method to acquire the current balance, a method to withdraw funds, and a method to deposit funds.  In addition to being a more coherent interface, the business logic can easily be applied in this design.

Likewise, the context that Alan is referring to is precisely the same issue, only it is a different user.  When designing user interfaces, the same comes out.  Instead of acquiring the information that the underlying algorithms require, consider the user's goals first, and these goals are not necessarily computer related.  Alan starts off the list of user goals, for example, by stating that one of the goals is to not feel stupid, for example.  One issue that Alan discusses when this happens, however, is that developers make up false goals for users, such as it is important to save memory, there must be a web interface, and more.  Perhaps they are requirements, but they are not goals.  Alan goes into great detail here, and even provides some information on making software polite.  Many of his ideas are great, but are not immediately obvious however.  It is not a notion of simply saying please and thank you, but rather becoming more human, as Clifford Nass and Byron Reeves' "The Media Equation".  In their research, they have discovered that humans interact with computers in ways similar to the ways that they interact with humans.  This means that when software indicates that they are doing something wrong, the interaction must be the same as when another person points out that they are doing something wrong.  In particular, you would not like someone to come over to you and tell you that the work that you have been doing is completely wrong, yet repeatedly in software, this happens.  For example, people will select options that appear to be usable in the current function and the software will come out with a phrase that would definitely not be appropriate when coming from a human.

In the next chapter, Alan discusses usage scenarios, which are essentially use-cases.  The important thing is with scenarios is that most of the time, the users will only use a finite set of functionality, as the 80-20 rule would suggest.  Although this subset could change overtime and depending on the task, these tasks should be easily accessible to users.  The problem is probably determining proper use-cases and which functions are in that finite set.  To help in this regard, Alan provides his table of Perpetual Intermediates, which describes the number of users that are beginners, intermediates, and experts, and most users are intermediates.  The users will evolve from beginner to intermediates quite fast, however, most users will stop here, and only a few will progress to experts.  The situation is, however, that experts can get bored of the software, and could migrate to other software, so targeting these users is not ideal.  Your goal should be to optimize your software for your intermediate-level users, and make it easy for beginners to learn.  One major component of this, however, is the use of vocabulary, where the vocabulary should be consistent between the developers and interfaces and the definition should be shared. 

Software companies have repeatedly continued shipping software that does not meet user expectations, but this is not for a lack of trying. The example that Alan provides is that of Microsoft Windows, where up until Windows 3.0, people really laughed at the usability of Windows. Alan argues that this situation exists because software vendors are more interested in shipping regular releases of software rather than focusing on usability and stability. Each release, they ship a version of software, and based on user reactions, future versions of the software address those complaints, and this is an acceptable practice in software, and many software companies attempt to emulate our friends at Microsoft.

But why? According to one of the case studies that Alan provides in the book, the proper interaction design of the Logitech Peacock met user's needs so well that it resulted in fewer support calls than any of its other products. Support and maintenance of the software being more expensive than properly designing the software from the start, it just seems completely backwards to continue developing software in this fashion.

Another aspect that I totally agree with Alan about is the fact that some interfaces are developed without showing them to users first.  In many organizations, software is developed and by the time users really get a feel for the software, the development is almost completed.  The analogy that Alan uses that is fantastic is that a piece of sand paper can make a chair or a table smoother, but the sand paper cannot turn a table into a chair or a table.  This is a great analogy because if you have created the wrong interface to the application, the code that you had will probably need to be rewritten entirely and cannot just be adjusted directly as well as we would like, but this is unlikely to occur at the end of a development cycle.  The only way to develop for this case is to prototype and let user's experiment with the software well before it is fully developed, where the code is easily formed into another object.  One analogy that I like is that of pottery, where when you are creating a vase, the clay can be easily maneuvered into a shape and form, however, once it is baked in the kiln, there is no way to change its form without breaking it.

Innovation is another topic that is discussed throughout the remaining chapters of the software. I never thought of it in this fashion, but the style guidelines provided by Apple and Microsoft for their respective operating systems stifles the true innovation of interaction design, especially since these style-guidelines are not done by a third party. In other words, this would be like dictating that all of Microsoft's competition work in visually compatible fashions to this document, and those that do not, are not compliant. The ability to innovate and to make new controls and to think of software from a new perspective is blocked by the need to be comformant.

On the same token, Alan points out that many companies that are on a regular release cycle, such as a software version per year, are likewise stifling innovation. The need to deliver software in a finite fixed time forces the time to do the proper analysis of what users require and proper interaction analysis to in a short time. While I agree with Alan on this front, there are some organizations that have addressed this by having concurrent development of software versions. Doing this is difficult to manage, however, it does provide for more time to do upfront design. But there is definitely a need for this regular release cycle; companies that do not release regular software versions appear to be idle. For example, when I was in the market for a design tool, one of the tools that I was considering's product name ended with 2000, and the last press release of this company was in 2002; being 2004, it seemed to me that this organization was idle. When I contacted them regarding this issue, they said that they have released some products in between, but have not really changed the version number; even with this answer, I did not feel comfortable investing in this product.

I regularly have to perform interviews for interns at my current organization, and during these interviews, one of my all-time favourite questions to ask is, "if I were to give you a project to develop from scratch, which programming language would you use?"  This is one of my favourite questions because I have yet to have any applicant answer it correctly.  There is absolutely no one that has to date asked me what the project is, and based on this, they generally answer the question based on the language that they are most comfortable in or the language that they want to learn the most.  My desired answer is one that takes into consideration the strengths of the language to solve the problem.  There are definitely some tasks that a scripting language is more well suited for than a compiled language like C++.  These developers are focused on solving a problem without knowing what the problem is.  But this issue is more fine grain than interns.  I have also experienced similar situations with managers and experienced developers, who ask prematurely whether the interface will be a rich-text interface or a web interface, or whether it will be in C++ or Java, and many people simply do not understand that to answer these questions, there is very little opinion in it.  The decision to prefer one technology over any other should definitely be the technology that solves the majority of the user's issues and meets the user's goals.  Likewise, one thing that is mentioned in the book that I agree with is that user interfaces do not necessarily imply a graphical user interface.  All too frequently, we begin developing graphical user interfaces out of habit or thinking that this is what users need, however, there are times where the use of text interfaces is appropriate, and one of the examples that Alan provides for this is a point of sale application; in the minds of many people, it would seem that this application would imply a graphical user interface, but a text interface was created on one project, and it was quite easy to use.

Part of the problem that I see here is that applications unfortunately suffer from an identify crisis, and the sad part of this is that there are too many such applications on the market right now.  The identify crisis goes way beyond the screen full of buttons, but also in the ways that these products are created.  In one of the previous chapters, a great example of this is the executive who prefers the navigation via the mouse, and therefore, this becomes a requirement, whereas the application may be better suited for the industry by use of the keyboard.  All of these crazy visions of the user are resolved by using personaes, because the right application will be created and the question of whether t should be a graphical user interface or a textual user interface, a keyboard-driven or mouse-driven interface, and the multitude of other options are not decisions that come from the developers, marketing, executives, etc., these are decided upon by the needs of the person who will actually use the application, and so stated, probably the one that influences purchasing of it at some level or another.

Alan discusses upfront design in the context of interaction design, and states that once the interaction design is completed and documented, it can be easily implemented by developers. He states that most of the time (probably 80%) should be spent on interaction design and the remaining time is spent on the implementation. But the interaction design, by definition, only narrows the scope into what features are delivered and how these features work. The entire topic of software architecture is not discussed, but this is equally important to successful and maintainable software.  I am not sure if Alan has put this in with the implementation.  Either way, he does clearly state that this interaction design must be documented and presented to everyone involved to acquire the shared vision of the software products, arguing that the shared vision is required to avoid people doing tasks that are unrelated to the end goal of the product.

Alan argues that doing the design prior to the implementation is something that is fairly new to software development.  In some environments this can be true.  His analogy for this is rather interesting, in that he picks the creation of a modern movie, which proceeds in three stages: pre-production, production, and post-production.  As bizarre as this may seem, it actually dovetails quite nicely with modern software development.  During the pre-production stage, the script is written, production of the film is designed, actors are casted, and money is raised.  During production, the movie is filmed per the plan in the pre-production.  During the post-production, the film is edited, visual effects are added, and marketing starts.  The first aspect to note is that there are many people involved in creating movies, so any thing that is changed in one of the later stages becomes harder and harder to change and the cost of change is prohibitedly expensive, and people know this in the movie industry, so they attempt to do everything in the earliest stages possible, and avoid changes that should have been done in previous stages.

Software development essentially has the same stages, although there names are different, but many organizations are not as organized as the film industry in not going back to earlier stages, or even observing that there are stages.  Books like Software Engineering by Robert Pressmen discuss these software stages, but the reality is that many organizations do not observe them fully, and we do not have a clear, shared vision of what is being created.  Design is intended to describe this shared vision so that people can understand what is happening.  Developers understand what they must create and marketing understands what the developers will deliver.  This is not a situation where the developers believe that they are delivering one product and the marketing department believes they are delivering another, and the customer has another vision.  In reality, there should only be a single vision, and that should be the customers visions, as denoted by the personae for the application; it does not really matter what the other people want in the software and what they think the software should do, in reality it is the customer that will use the software, and all their needs must be met.

Another aspect that he states is new is performing usability testing prior to the product being created.  At present, most software development goes to both software testing and usability testing only after the software is in a completed (at least partially) state.  Similar to security, software usability cannot be an after thought.  It must be designed from the start; attempts to resolve user interaction issues after the core application is developed will be more expensive and difficult to do than if done prior.  This is similar to the aforementioned analogy of the creation of a movie; it is easy to change the object that explodes in the pre-production scene, but after this point, it can be very difficult and expensive.  Such kinks should be ironed out prior to the software being built; this is generally done via prototypes.  This tool makes sure that there is a shared vision and that users understand what is being created.  This is not to say that prototypes are not created today, but rather, users are not always involved with them.  In may cases, the prototype is created as part of the estimation process or as a validation that the product can actually be created, but in many cases, such interfaces are not shown to the actual users of the application.

I say these items in rather broad, all inclusive terms similar to the way that they are presented in the book.  In reality, not all software is created this way, but in my experience, there are still many that proceed in this fashion.  New methodologies such as extreme programming involve the user in the building of the application and the proponents of short-iteration iterative development, but this is unfortunately such practices are not the norm.  I clearly see this as an aspect of our development paradigm that needs to change.  As denoted in Steve McConnel's keynote in OOPSLA, our software is a little too complex at this state to do the entire design at the beginning, but we still need to understand what the software does in simple terms and what we are actually delivering.  This shared vision of the software must still hold.

And this is really what the Inmates Are Running The Asylum is all about.  To create software that meets our customers needs, we need to know that customer and we have to design the software for that customer.  The book highlights the reasons that there is a problem right now, and presents some ideas to changing the present situation.  I recommend this book (or its companion, About Face 2.0: The Essentials of Interaction Design) to every developer.