Inmates are running the asylum – Some Notes

by Paul Joseph on October 23, 2012 · 0 comments

I recently re-read the book Inmates are running the asylum . For the uninitiated, this is the grand book on interaction design meant for product managers & business owners. For actual designers, there are other books like About Face (by the same author). Alan Cooper, author of this book is the man who introduced the concept of ‘personas’. He has done wonderful work in Microsoft & other places earlier and runs Cooper Design agency now. To avoid re-reading, I took notes this time for my reference later. And then thought, why not put it in the blog as well for larger consumption. I have tried my best to make it readable/appreciable to a person who has not read the book as well. If it is not come out so, I am sorry, go read the book. The first curious question is – who are the ‘inmates’ and what is the ‘asylum’? An asylum is any organization that develops software and ‘programmers’ are the inmates who are running the asylum – driving from the backseat & designing things as they please. When engineering gets outsourced, this becomes more of a problem, not less. Anyone untrained in Interaction Design methods tend toward self-referential design (imagining oneself as the user) and programmers naturally fall into this trap à Every software engineer thinks that he is different and that he is the one who can do both design as well as code. The rest of this post is split into these sections: General Insights on design, Definitions, Personas, Goals, Scenarios, Design Processes, Other Design tools & techniques General Insights on designing a software product Cross anything with a computer and what you get is a computer (Camera, Alarm Clock etc.) & it becomes unusable. An alarm clock with mechanical controls does one job and does it well. Configuring it is easy as well. But when you add a computer to it, with all the extra features, it becomes so difficult to configure and becomes unusable ‘Dancing Bear’ phenomena – Occurs when people wonder and feel happy that the (difficult to use) software actually works! Most software is like dancing bear. The wonder is not that the bear dances well but that the bear dances at all What is wrong with dancing bear software? It ‘forgets’ (the state in which it was closed earlier) It ‘is lazy’ (& asks the same questions several times) It ‘is stingy’ and ‘is parsimonious with information’ It ‘is inflexible’ – When human processes get computerized, tasks are distilled out but all non-task aspects are lost and they are important too ( for example : in a manual order processing case, a user can quickly process an urgent job without all information in it but not so in software. Software should allow that but still track who did what) It ‘blames users’ (for its own mistakes) It ‘won’t take responsibility’ (you better save, you better verify etc.) Software Apartheid – The gap / inequality between people who work in the technology industry and the rest Shipping late does not hurt but shipping a wrong product does in a big way ‘Randomness of the market’ is caused by cognitive friction most of the times – It is not that the market randomly chooses to make a product success or not. It is because of the cognitive friction that exists in the products Nobody – not even a stupid and incompetent person – likes to be treated as if he is stupid or incompetent. That is what software does Software engineers draw diagrams showing back end data handling code and front end UI code as 2 separate boxes – but in reality, there is no such difference when it comes to interaction design. It is not possible to have ‘UI block’ alone handle interactions. An interaction change would involve ‘back end’ block of code as well Programmers are homo “logicus”. They Trade simplicity for control Exchange success for understanding Focus on what is possible than on probable (focus on edge cases while leaving out gaps in core elements) Act like jerks (Act like Man-Boys, the big kids in school who threaten the small ones. Most likely, programmers were the small kids in school who got threatened but now they think it is their turn!) Users are not ‘elastic’. Usage of the word ‘user’ causes trouble because everyone thinks different things about the user. This will cause ‘lip service’ and the developer will code as he pleases. So always use a name – a specific individual – a persona Humans react to computer in the same way that they react to other humans. So software should behave like a ‘likeable’ person and be ‘polite’. What makes software polite? Is interested in me and remembers my choices & behaviour Is deferential to me: Users’ preference should precedence over computers. Never use the word ‘Submit’. User need not submit, only the computer should Is forthcoming – not just in providing answer to what I ask for but also give other relevant information. When you print a document, the software better tell me if there is enough paper in the tray to print my job, cartridge status etc. Has common sense – It should have frequently used controls next to each other. Never-used controls should not be in the first page of the interface Anticipates my needs – Load more links/items when idle instead of waiting for explicit request Is responsive – understands the current state of usage and react accordingly. E.g. Automatic resizing when connected to a projector. Is Taciturn – about its personal problems. No unnecessary status updates or dialogs. Not only should the software keep quiet about its problems but should also have intelligence/confidence and authority to fix its problems on its own. It should not tell things like ‘No memory etc.’ to the user unless he can do something about it Is well informed – Should know about its internal states well and should not show options not available currently Is perceptive – When a SW is always used in maximized mode, it should always be maximized at launch Is Self Confident – No unnecessary dialog boxes. When I Print, just Print. No unnecessary ‘Are you Sure’ Is Focused – Not offer too many choices. Choices offered is not a benefit but an ordeal Is Fudgable – Can re-order work items and be flexible. Sales order processing example: If a user wants to re-order work items to urgently attend to someone, it should allow, though it can be construed as ‘fraud’. Let the user do what he wants but keep detailed records of such actions – making accountability easy. When inflexible rules are imposed on flexible humans, both sides lose Gives instant gratification – When a new TV is bought, if one is enabled to watch the basic channels without much effort, he would spend a lot of time to set complex functions later. If he is made to feel stupid for just setting up the basic items, he will hate the product. Is trustworthy – Never let the user down in his business. Even if someone deletes a file, store it somewhere he does not know & show when he needs Interaction designers should not worry about hardware / software just as a user would not When an interaction designer has done a good job, the user would be unaware of the existence of an interaction designer Most really breakthrough conceptual advances are opaque in foresight and transparent in hindsight Interaction Design is Architecture of a building, not Interior Design Documentation of interaction design is very essential. Write / Story Board / Animate / Sketch with sufficient detail that developers believe it is a complete blueprint Design = Product Definition Process Central Recommendation of the book: Interaction Designer should be the ultimate owner of product quality Definitions Cognitive Friction – The resistance encountered by a human intellect when it engages with a complex system of rules that change as the problem changes Interaction Design: Anything that will directly affect the end user of a product. Program Design: Everything else Apologists: People in the computer industry who are power users, are giddy with power or have Stockholm syndrome Survivors: People, who feel frustrated and stupid using software, belong to other industries Personas “A precise description of the user and what s/he wishes to accomplish” Make up pretend users & design for them Hypothetical archetypes: Imaginary but are defined with rigor and passion Actual user is valuable but never let him directly affect a solution Not really ‘made up’ – Discover them as a by-product of the investigation. Only names and personal details are made up Personas are defined by their goals and vice versa – so it is an iterative process Start with a reasonable approximation & converge on a believable population of personas Design for only one person – Having people LOVE your product, even if it is a minority, is how you succeed Personas are narrowly defined, not broadly Users are not ‘elastic’. Usage of the word ‘user’ causes trouble because everyone thinks different things about the user. This will cause ‘lip service’ and the developer will code as he pleases. So always use a name – a specific individual – a persona Be specific. Like ‘Emily uses Word 97 to write letter to Grandma’. Distinctive specificity is powerful as a design and communications tool Personas SHOULD have a name. Stereotyping is OK too (e.g. is a black) if it lends more credence. No need to be politically correct. Add photos as well that you may get from magazines etc. Do not confuse precise user taxonomy with a real person. When there is a real person, lots of idiosyncrasies creep in. So persona should be hypothetical Persona should be precise, not accurate. That is, define it in great & specific detail. No averages are to be used – no one has 2.3 children. (This part is a bit confusing to me – I thought precise and accurate mean the same! Nevertheless, what Alan Cooper means here, I suppose, is: It should be precise but need not be accurate. ;-) HaHa, Okay, seriously: A persona should be as detailed as it can get with information but it need not be an accurate thing. For example: You should specify that the persona has 2 children who are aged 8 and 5 but it should not be taken in the spirit that it applies to only those people who have children aged 8 and 5 fit this persona. It could be 9 and 5 as well. Something still seems wrong, ain’t it? Okay, let us live with precise but not accurate J ) Personas are unique for each project. Occasionally we can borrow but it is rare Personas end feature debates – You can think of each feature for only a persona. Not for ‘a user’ Marketing persona is based on demographics and distribution channels. Design personas are based purely on users. They are not the same. Marketing personas shed light on sales process while design personas on development process Persona should be a ‘user’, not a ‘buyer’ There can be anywhere between 3 & 12 personas. Do not design for all of them. Some of them could only be to be ‘excluded’ – call them negative personas We know we have isolated a persona when we have discovered a person whose goals are unique Primary Persona: Someone who must be satisfied but who cannot be satisfied with Interaction Design for any other persona Identifying primary personas is very important. Each primary persona requires a unique interface It is OK to have up to 3 primary personas. If we have more, we have a problem – probably the problem set is large and we are trying to accomplish too much at one time. We may end up with 7 useful personas but never more. (A bit confused here, does he say we can have primary / secondary etc. put together 7 personas?) Use printed personas in ALL meetings Goals Persona exists to achieve his goals. Goals exist to give meaning to a persona Good Interaction Design has meaning only in the context of a persona actually using it for some purpose. Essence of good interaction design is to devise interactions that let users personas achieve their practical goals without violating their personal goals. The most important personal goal is to not feel stupid Tasks Vs Goals: Goal is an end condition. Task is an intermediate process needed to achieve that goal. Task changes with technology but goals are very stable. Tasks may look contradictory to a goal. For example: You need to mow a lawn (a task) to rest in the lawn (goal) Developers usually design for a ‘task’. For a System Admin, a developer would design for a task (configure, monitor, track etc.) while design is needed for the goal (smooth performance of the network) Personal Vs Practical Goals Distinction between them is critical to success Do not have to achieve ALL practical goals at once but never find ANY of the personal goals violated Principle of commensurate effort: People react emotionally to computers. If companies put effort in making one feel good (a few practical goals achieved, no personal goal violated), they would put effort into more complex tasks (the other practical goals) because they know they will get extra rewards for it. New TV example: When a new TV is bought, if one is enabled to watch the basic channels without much effort, he would spend a lot of time to set complex functions later. If he is made to feel stupid for just setting up the basic items, he will hate the product. Personal Goals Not feel stupid Not make mistakes Get enough work done Have fun (not be bored) These are universal and are always true. Any system that violates personal goals will ultimately fail, regardless of how well it achieves other goals Corporate Goals These are hygiene factors – goals pre-requisite for effective functionality but powerless to motivate by themselves Increase profit / market share Defeat competition Offer more products/ services etc. Practical Goals These bridge the gap between personal goals of user and the corporate goals of the company. E.g. Handle client’s demands, record client’s order etc. False Goals They ease the task of software creation, which is a programmer’s goal. Other false goals are about tasks, features & tools – They are means to ends but not end in themselves. Goals are always ends. E.g. Save memory, Run in a browser, Speed up data entry, maintain consistency across platforms, be easy to learn etc. are false goals. Avoid these when documenting user goals Scenarios   After personas and their goals, we should turn to their tasks, through ‘Scenarios’ Scenarios are like role-playing or method acting Unnecessary task are eliminated during scenario creation More ‘breadth’ than ‘depth’ is needed. Should not get lost in edge cases (if the user clicks on a button 2000 times continuously….) 2 types of scenarios: Daily use & Necessary use (there can be several daily & necessary use scenarios) Daily: Actions performed with greatest frequency. Most personas have 1 or 2 daily scenarios. Never more than 3. Learning curve should be fast. Soon ‘shortcuts’ & ‘customizations’ would be expected. Necessary: Not performed frequently but important. May not need shortcuts and need not be customizable. The number of such scenarios may be larger than daily use Edge Case: Occurs rarely. Programmers will emphasize on this but can be designed roughly Code may succeed/fail in its ability to handle the edge cases but product will succeed/fail in its ability to handle daily and necessary cases Other Useful Design Concepts Inflecting the interface: This is a tool to make design simple but also make software powerful. Simply put, it says: Put controls needed for daily interactions in the prominence. Push others into secondary locations Perceptual Intermediaries: For any software, if we graph the number of users against their particular skill levels, there will be a few beginners to the left, few expect on the right and a huge majority of intermediate users in the centre, forming a bell curve Most users move from beginning to intermediate or drop off. It is in the intermediate position that most of them remain Developers design for ‘experts’. Sales & marketing teams focus on ‘new users’ (beginners) and push for their needs. So the largest, most stable and most important group (intermediates) are ignored Example: Several software products have a need for a user to be a programmer to use (experts) but also have wizards and tutorials (beginners) Vocabulary: A common vocabulary is needed across the team. It is impossible to communicate without a common set of words, understood in the same way by everyone in the team. Those words need to be ‘precise’, not necessarily be ‘marketing worthy’ Lateral Thinking: Edward de Bono. ‘Reality never needs an advocate, because it can never be denied’. So, do not constrain yourself & feel free to imagine. In fact, most constraints are illusory or self-imposed. Other design tools/processes (that do not substitute interaction design) User testing: Done in parallel to bug test but AFTER programming. It is good but cannot replace Design, which is done BEFORE programming Usability tests can make a product ‘smoother’ but cannot ‘design’. So, design first (with personas, goals and scenarios), build prototypes and test them for usability BEFORE programming Style Guides and Interaction Guidelines: Should complement goal-directed design. Cannot be blindly trusted Visual Cover on a bad product is like ‘painting a corpse’ – so visual design alone is not enough Industrial Design – It is good but does not consider ‘cognitive friction’, only physical friction. Example: Microwave buttons are shiny, smooth and easy on the fingers but you do not know what would happen when you press them Design Process related insights Technology is not de-humanizing. The process is. 2 important things to note: (1) Design the interaction before programming and (2) Have the design done by a trained IxD person Design in 3 stages: Conceptual Design à Behavioural Design à Interface Design What does ‘DONE’ look like? Detailed physical description of the product (typically for a building) Reaction end users would have (typically for a movie) SOFTWARE NEEDS BOTH Feature List Bargaining Additional features are only for the early adopters, not for mass market Lost in the battle in the perspective needed for success Focus on ‘GOALS’ than ‘FEATURES’ PROTOTYPES are experiments to be thrown out but few of them ever are Writing a program is like making a pile of 1000 bricks. If the bricks are not placed with great precision over another, the structure goes unstable. 998 th brick being not precise may be acceptable but if it happens at the 2 nd brick, it is a huge issue. Prototypes are like that Prototypes are just visualization tools for business people 3 qualities of Hi-Tech businesses Capability – provided by engineers Viability – provided by business people Desirability – provided by Designers Marty Cagan’s Feasible, Valuable and Usable is probably derived from this! It is sensible to first find what customers find ‘desirable’ and then challenge the engineers & business people to build & sell. ‘Desirability’ is not a ‘Need’. In short term, satisfying the need is enough. In the long term, satisfying the desire is essential Design method of Scot McGregor Identify all key users & stakeholders Write profiles on them Develop statements of their goals and tasks they would go through to accomplish those goals Come up with proposed visual representations of key objects and interaction behaviours Start building it Difference between ‘listening to’ and ‘following’ your customers When you “follow”, ‘conceptual integrity’ is lost & customer-driver death spiral occurs Product company becoming a service company: In consultant terms, selling brain Vs selling grey hair. Always do more ‘brain projects’. Else, your value will fall and you will be given low-level demeaning tasks 4 steps to void this spiral Taking a longer view (even at the cost of some short term losses) – can postpone short term thinking but not long term Taking responsibility to be the product and not blame the customer Taking time – do not announce shipping date before design is complete Taking control (from all other stakeholders) Comparison of software product development with making movie Pre-production à Production à Post Production MOVIE: Script/Casting/Production Design à Shooting/Technology à Editing/Sound/Marketing SOFTWARE: Interaction Design/Story Board/Hire programmers à Coding / Debugging à Documentation / Marketing

[via Indian Mobile Phone Industry News and Analysis]

Follow us @wirelessheat – lists / @sectorheat

Follow us @wirelessheat - lists / @sectorheat

Leave a Comment

Previous post:

Next post: