http://tc.eserver.org/authors/Berkun,_Scott A bibliography of works by Berkun, Scott in the field of technical communication. en-us Copyright (c) 2005-08 by the EServer. All rights reserved. tclib-editorial@eserver.org (TC Library Editorial Board) webmaster@eserver.org (Geoffrey Sauer) http://tc.eserver.org/images/newlogo.gif http://tc.eserver.org/dir/Berkun,_Scott http://tc.eserver.org/32767.html http://tc.eserver.org/32767.html Last week I announced a study on why designers fail - exploring the reasons why designers, and people who work with designers, believe designers don’t achieve the results they desire. I presented the results as UIE 13 last week, and as promised here is a summary. Prize winners will be announced soon. Many top reasons for failure are not typically considered design issues, such as collaboration skills, persuasion skills, and receiving critical feedback. http://tc.eserver.org/26930.html http://tc.eserver.org/26930.html Are there good websites and evil websites? Rarely. Most things we know and use fall in between: tools are amoral. They don’t prevent someone from using them for bad or work better when used for good. Great software performs just as well when you’re drafting praise for homeless shelter volunteers as when you’re writing recipes for orphan stew. If we want to claim that the things we make are good or bad, we have to go beyond their function. Goodness, in the moral sense, means something very different from good in the engineering sense. http://tc.eserver.org/26926.html http://tc.eserver.org/26926.html For projects of importance, you need divergent skills to succeed. It is not possible to find an individual with all of the skill sets needed, nor would you want to. To create a first rate website or software product, you need many tasks to be done in parallel, which means that more than one person has to be working at them. As soon as two or more people are involved, the dynamic for how decisions are made, and how work gets done, becomes important. Any group of people can do work together, but it takes the right approach and team philosophy for that group to produce good work. Collaboration is critical in any creative pursuit involving groups of people, from filmmaking, to urban architecture or even web and software development. http://tc.eserver.org/26924.html http://tc.eserver.org/26924.html For many projects ease of use is never a stated project goal. It may be an assumption among managers or developers that the project will result in something easy to use, but if it’s not a first order goal of the project, tradeoffs can never been made in favor of ease of use (and can implicitly be made against ease of use). Often the lack of a clear statement of ease of use occurs because the team managers or leaders are unfamiliar with how to make ease of use operational in the development process, and one way to avoid this issue is not to make it an explicit goal. http://tc.eserver.org/26929.html http://tc.eserver.org/26929.html Perfection in design is not possible. No matter how much is known about a given business, user group or technology, you can not simultaneously satisfy all possible objectives. For any website or user interface, there are no mathematics, and no algorithms, for deciding which objectives to satisfy in a single design, or even forThe swiss army knife: a balance of interesting design tradeoffs accurately defining an optimal solution within any of those objectives. There are usability, design and business methods that effectively evaluate and illuminate promising directions , but they are sensitive tools, that work more as guides, rather than maps. In general, any form of design involves too many simultaneous possible objectives and forms of solutions to enable any overall mathematical or algorithmic based confidence. An optimal design, in the broadest sense, is a mythical idea. http://tc.eserver.org/26927.html http://tc.eserver.org/26927.html This describes the role that I played as program manager for IE5.0, and the basic process we used (the essay is derived from an old post to chiweb). It's a good anecdote as to how one team managed the cross discipline work of design and usability, with the engineering and development process. http://tc.eserver.org/26925.html http://tc.eserver.org/26925.html The shift to internalizing usability for an organization can be accelerated by thinking about usability from a strategic, instead of tactical, perspective. Tactical use of usability engineering is responsive and isolated, focusing on adjustments to existing designs, often late in the schedule. Strategic use of usability or user research is proactive and integrated, improving decision making at many levels of project and business planning. To make the transition from tactical to strategic work, a usability engineer needs to develop partners and champions within the heart of an organization. It can often take several projects releases, and the cultivation of multiple partnerships with key players in an organization for this change to come to fruition. http://tc.eserver.org/26928.html http://tc.eserver.org/26928.html Unless you have the power to make business and development decisions for your project, some of your energy will be spent influencing those that do. Experienced usability engineers or interaction designers may have limited skill in influence, despite how significantly it can effect their ability to contribute to projects. It’s the smartest and most effective designers that work to understand the human to human interaction within their project teams, as part of their work towards better human to computer interaction. http://tc.eserver.org/26931.html http://tc.eserver.org/26931.html All-star teams lose. While it’s an honor to be chosen to an all-star team, it’s miserable to play on one. These teams are constructed without consideration for how to bring people together. Whenever an all-star team plays a mediocre, but intact team, they usually lose. The true goal of any team is not to have the best players for each position: it's to succeed. Success comes when a team makes use of the team's abilities towards a goal, something you don’t get merely by picking the best players at each position. http://tc.eserver.org/26909.html http://tc.eserver.org/26909.html The central mistake new managers make is egoism. On the surface, the change is all about you: you’ve been promoted, you have a new job title, you have a new office. Perhaps you’ve been waiting for this change for some time, while watching peers or friends get promotions, and now finally you feel you’ve received the respect you’ve earned. http://tc.eserver.org/26919.html http://tc.eserver.org/26919.html One common concern raised by managers and engineers alike is this: how easy to use is enough? This question, and the absence of an easy answer, is often the first defense people offer against investing in usability and ease of use. The smart usability engineer or designer has at least one response: the usability benchmark. By capturing the current level of ease of use of the current product or website, a reference point is created that can be measured against in the future. It doesn't answer the question of how usable is enough, but if the benchmark is done properly, it does enable someone to set goals and expectations around ease of use for the future. http://tc.eserver.org/26915.html http://tc.eserver.org/26915.html Web browsers are funny things. On the one hand, they’re supposed to be lightweight little programs that just let you view websites, and on the other, they carry the same burdens as operating systems and application suites, trying to provide everything to everyone. Here in this little essay I explain what I know about designing browsers. I’m in the lucky minority of people that have actually designed successful browsers, or parts of them, for any length of time, and with Firefox and Opera in the headlines, and the art of browser design becomes important again, I thought I’d write down some of what I know. Its been years since I was a program manager on the Internet Explorer project, but I’ve maintained interests in the design of navigation and searching systems of all kinds: what follows is a rough summary of what I’ve learned. http://tc.eserver.org/26922.html http://tc.eserver.org/26922.html Conferences are what you make of them. If you’re not sure why you’re going, or what you want to get out of the experience, you’re unlikely to get it. This essay gives one perspective on conferences, and how to make them more valuable and engaging experiences. I think in general professional conferences take a very conservative approach to training and education, and it demands that attendees take more responsibility for getting value from the experience than should be necessary. http://tc.eserver.org/26916.html http://tc.eserver.org/26916.html Good feedback is rare. It can take a long time to find people who know how to provide useful criticism, instead of simply telling you all the things they think are “wrong” with you or whatever you've made. A good critic spends as much energy describing what something is, as well as what it isn’t. Good criticism serves one purpose: to give the creator of the work more perspective and help them make their next set of choices. Bad criticism uses the opportunity provided by someone else’s work to make the critic feel smart, superior or better about themselves: things that have nothing to do with helping the recipient of the critique. http://tc.eserver.org/26913.html http://tc.eserver.org/26913.html Before you worry about interviewing, consider this: good interviewing does not make a good candidate out of a bad one. The higher the quality of the people coming in to your interviewing process, the higher the quality of those that will come out of it. Do not rely on HR or some other person to decide who enters the process. The more energy you, as a hiring manager, invest in recruiting, the better your results will be. http://tc.eserver.org/26918.html http://tc.eserver.org/26918.html What follows is some advice for managers on how to manager people, especially talented people. I worked for nine years at Microsoft, sometimes managing projects, sometimes managing people, but always with a manager above me. I think I’m smart, but many of the people who have worked for me definitely were. Over the years I’ve experienced many mistakes and successes in both how I was managed, and how I managed others. There's no one way to manage people, but there are some approaches that I think most good managers share. http://tc.eserver.org/26914.html http://tc.eserver.org/26914.html Coming up with good ideas is hard enough, but convincing others to do something with them is even harder. In many fields the task of bringing an idea to someone with the power to do something with it is called a pitch: software feature ideas, implementation strategies, movie screenplays, organizational changes, and business plans, are all pitched from one person to another. http://tc.eserver.org/26908.html http://tc.eserver.org/26908.html The most important thing about a brainstorming session is what happens after it ends. No matter how poorly you run a brainstorming meeting, some decent ideas will surface. But depending on what happens after the session, those ideas may or may not impact anything. So while you can read books and take courses on better brainstorming techniques, the most important thing is figuring out how the brainstorming session fits into the larger decisionmaking process you or your team has. http://tc.eserver.org/26923.html http://tc.eserver.org/26923.html In the early and middle phases of a project, teams need a way to understand and explore the current direction of the design. The challenge is to create the openness needed for good ideas to surface, while simultaneously cultivating the feedback and criticism necessary to resolve open issues. Unlike a brainstorming meeting, where the exclusive goal is to come up with new ideas, a critique meeting is focused on evaluating a set of existing ideas, and possibly identify future directions or changes. Instead of hoping that hallway and email discussions will lead the team in a good direction, it’s generally worth investing time to set up critique meetings to drive the design forward. http://tc.eserver.org/26910.html http://tc.eserver.org/26910.html The best advice for having a bad manager is to seek other employment. Don’t undervalue your happiness: it’s impossible to be happy if you work directly for someone you can’t stand. It may be difficult to find another job, but if you are willing to make compromises in other areas (salary, position, project, location, etc.) it will certainly be possible. Being happy and underpaid is a much better way to spend a life than unhappy and anything else. http://tc.eserver.org/26920.html http://tc.eserver.org/26920.html Discoverability is often defined as the ability for a user of a design to locate something that they need, in order to complete a certain task. It’s common to hear programmers and designers utter the phrase “that won’t be discoverable”, while pointing to a specific command or link they believe users will fail to find. The trap, and the myth, of discoverability is that in any design, not everything can be discoverable. http://tc.eserver.org/26921.html http://tc.eserver.org/26921.html Looking for jobs is tough. I remember when I looked for my first industry job about ten years ago, how frustrating a process it was. I had everything to prove, and every desire to prove it, but few opportunities to do so. And worse, by the time I graduated in May of 94', all of my friends were gone: they moved away in response to job offers. Many of them had jobs lined up before the spring semester even started. Meanwhile I struggled to find good interviews, and maintain the work needed to graduate on time. I think most people, especially students, underestimate how much energy job searching requires, and there really isn’t that much honest guidance on how to be smart in going about it. This essay is an attempt to offer some good advice - the kind I wish I had back in 94'. If you find it useful, please pass it on to other job seekers you know, or if you’re in school, to professors and other students. If you have other suggestions to add, please let me know. http://tc.eserver.org/26917.html http://tc.eserver.org/26917.html Through years of suffering through the American education system, I was implicitly taught that learning, and therefore training, required large numbers of people sitting in neat little rows, listening to dispassionate people ramble away on mediocre and predictably boring lessons. http://tc.eserver.org/26912.html http://tc.eserver.org/26912.html We all know someone that's intelligent, but who occasionally defends obviously bad ideas. Why does this happen? How can smart people take up positions that defy any reasonable logic? Having spent many years working with smart people I’ve catalogued many of the ways this happens, and I have advice on what to do about it. I feel qualified to write this essay as I’m a recovering smart person myself and I’ve defended several very bad ideas. http://tc.eserver.org/26911.html http://tc.eserver.org/26911.html Something curious happens when we confront things we don’t like. Instead of the useful choices of taking action to improve things or accepting things as they are, we often just sit on our asses, point fingers and complain. We’ve developed the passive habits of spectators, rather than the active roles of creators and supporters. http://tc.eserver.org/26456.html http://tc.eserver.org/26456.html The Explorer bar is a component of the Internet Explorer web browser that provides a unified model for web navigation activities. The user tasks of searching for new sites, visiting favorite sites, and accessing previously viewed sites are simplified and enhanced by using a single user interface element. http://tc.eserver.org/21291.html http://tc.eserver.org/21291.html There's a natural balance that can be mastered between both intensely imaginative, and passionately logical lines of thought. We need to seek out this synergy to be good at design. The surprising truth is that for designers everywhere, the scientific method can be an extremely powerful tool for finding and evangelizing your great ideas. http://tc.eserver.org/18688.html http://tc.eserver.org/18688.html This list provides resources about web design, usability, and related topics. http://tc.eserver.org/18679.html http://tc.eserver.org/18679.html It takes a certain craft to know how and when to build prototypes of web designs or software designs. This primer of prototyping explains when and how to build them. http://tc.eserver.org/18682.html http://tc.eserver.org/18682.html Interface design is difficult in part because everything requires interpretation. A design that works for one task or one user might not be appropriate for another. In other types of engineering, like architecture or bridge building, designers can always rely on laws of physics and gravity to make designs work. There is at least one immutable rule for interface design that we know about, and it's called Fitts's Law. It can be applied to software interfaces as well as Web site design because it involves the way people interact with mouse or other pointing devices. Most GUI platforms have built-in common controls designed with Fitts's Law in mind. Many Web designers, however, have yet to recognize the powerful little facts that make this concept so useful. http://tc.eserver.org/18686.html http://tc.eserver.org/18686.html People don't like to learn things. If they take the time to learn something, they expect to be able to apply that knowledge in many places. It follows that good designers conserve the number of things users need to learn to get stuff done. The streets in American cities are good examples of conservation of knowledge. Anywhere in America, yield and stop signs look exactly the same. Traffic lights use red, yellow, and green to mean precisely the same things regardless of the street or city. Mailboxes on street corners use the same colors and icons, so they are clearly identifiable anywhere. It becomes difficult for people when their knowledge of things breaks down. A driver from a country with different street signs who visits America will make mistakes until they learn the new signs. Even subtle variances like the difference in speed of two different yellow traffic lights can cause American drivers to make mistakes. http://tc.eserver.org/18687.html http://tc.eserver.org/18687.html Web sites and software often compete with each other based on the features they provide. The popular assumption is that the more features a product has, the better it will be. The truth is that features improve a product only if they are actually used by the customer. In most cases the proliferation of features in products creates more complexity than value. Each feature gets an icon or a link on a Web site or toolbar, and is yet another item that the user needs to wade through before they can find the one that they need. Web sites are still young, but many Mac and Microsoft® Windows applications show the carnage of years of feature wars with competing products. Over the years I've learned a few things about how to keep interfaces simple, and simultaneously keep the power intact for more sophisticated users. http://tc.eserver.org/18689.html http://tc.eserver.org/18689.html At Microsoft we have full-time employees, called usability engineers, who are trained to help product teams understand what the user's needs are, and analyze how well our product user interfaces match those needs. They do a great deal of work, and understand the discipline of UI design and data collection really well. They are critical to the success of our products. As I've learned from the e-mail I've been getting at hfactor@microsoft.com, most developers don't have the luxury of this kind of support, and are on their own to make good interface design decisions. This issue will introduce a basic development process that helps good UI make it into products. Word of warning: There is no magic recipe for good UI, or for writing good code, and I can't guarantee improved interfaces without some extra effort. http://tc.eserver.org/18685.html http://tc.eserver.org/18685.html You cannot build a useful product or Web site without usability testing. If you have never watched someone use your designs in a usability lab, you are taking shots in the dark. You can't possibly know whether your hard work is making things better or worse. The features you are focusing on may be things that no one really needs, or could never figure out. Without regular sessions in the usability lab during the development cycle, projects are guaranteed to head in directions that do not benefit the users of the product. As a developer, you should have deep interest as to whether your hard work is making the product better. It's in your interest to make sure your work gets examined in the labs, so that you can make adjustments and ensure that you are making the best possible product for your users. http://tc.eserver.org/18684.html http://tc.eserver.org/18684.html The greatest challenge in web or software design is creating a work of deep craft. That is, the presence of the designers and programmers coming through to make the user feel as though you were really trying to make them happy. For many products, I can point to specific parts that in isolation made me feel that way, but it's rarely carried through consistently. Web sites always have rough edges: search results pages that are ugly and hard to read, error pages that are incomprehensible, JavaScript pop-up menus that appear and disappear awkwardly, with visible repainting and redrawing, home pages to well-known Web sites that are garish, cluttered, and cold. http://tc.eserver.org/18681.html http://tc.eserver.org/18681.html Nothing says more about what you think of your users than error messages. The moment things go wrong is the moment users need you most. Software products, including some Microsoft® products, have developed bad reputations for cryptic error messages that are hard to understand or resolve. What's alarming is that Web site user interfaces are just as bad, or worse, in their handling of problem situations. We've taken a step backward in the baseline for acceptable treatment of our customers. Here's a short guide for handling errors well, on the Web or in Windows. http://tc.eserver.org/18690.html http://tc.eserver.org/18690.html Last year at Internet World a woman asked me why software and Web sites were so hard to use. Let's call her Pandora. I told Pandora that either we aren't smart enough yet, or the industry has not matured to the point at which well-designed products are required for companies to be profitable. She didn't buy it. She swore that sometimes we just did it on purpose. She laughed when she said it, but I think she meant it. It's my job to make simple-to-use products, and I took what she said to heart. I said that we really are trying, and that we're getting better at it all the time. She walked away unimpressed. I went back to the hotel bar that night and thought about why things are the way they are with the Internet and computers. http://tc.eserver.org/18683.html http://tc.eserver.org/18683.html When I was a computer science/philosophy student at CMU, I took a design project course to learn about all of this interface design stuff I'd heard about. The first day of class I arrived at the studio room, and found a young man at a drawing table, sketching out different variations of the Walkman® he was designing. I got close enough to see the large sketchpad and saw 30 or 40 different variations that he had considered and put down on paper. I introduced myself, pleaded ignorance about design, and asked him why he needed to make so many sketches. He thought for a second, and then said, 'I don't know what a good idea looks like until I've seen the bad ones.' I smiled, but was puzzled. I felt like going back across campus to the computer science labs. If he's a designer, shouldn't he make fewer sketches instead of more? I didn't really understand what he was talking about until many years later. http://tc.eserver.org/18680.html http://tc.eserver.org/18680.html This essay explains why so many technologies fail to solve people's problems, and offers a business and engineering philosophy for creating better technologies. http://tc.eserver.org/18673.html http://tc.eserver.org/18673.html The chi-web and sig-ia mailing lists are two email based discussion groups on the topics of web usability, design and human computer interaction (the later with a heavier emphasis on information architecture). To subscribe to chi-web, read the info page or to get a better flavor for what happens there, use its full searchable archive. Alternatively, you can join sigia-l from here or view the sigia-l archive . Using the archives for each mailing list, I've compiled a list of the summary postings from useful threads, and a few personally selected favorite postings. Please note: my list below is not an exhaustive list of summary postings. I just picked the ones I found most salient and valuable for reference. Also, these summaries are collections of contributing posts: they are a mixture of opinions and commentary, with some references to reports, usability data, websites or books. http://tc.eserver.org/18675.html http://tc.eserver.org/18675.html Designs must be realized to change the world. How does project management intersect with the challenges of design? How can a manager enable great designs to reach the customer? http://tc.eserver.org/18677.html http://tc.eserver.org/18677.html At the heart of design and engineering is critical thinking. The ability to separate what is worthwhile from what isn't is the hallmark of the best in many fields, from film directors to project managers, programmers to designers. http://tc.eserver.org/18676.html http://tc.eserver.org/18676.html How do you cultivate good ideas? What process do you use? This issue discusses how critical thinking relates to generating and managing good ideas in design. http://tc.eserver.org/18668.html http://tc.eserver.org/18668.html There is every reason to use logical and creative approaches when working on any kind of design problem. The best designers know how to switch between approaches, and bring together both kinds of thinking into a process for discovering and crafting the best ideas. http://tc.eserver.org/18665.html http://tc.eserver.org/18665.html Conferences are what you make of them. If you’re not sure why you’re going, or what you want to get out of the experience, you’re unlikely to get it. This essay gives one perspective on conferences, and how to make them more valuable and engaging experiences. I think in general professional conferences take a very conservative approach to training and education, and it demands that attendees take more responsibility for getting value from the experience than should be necessary. http://tc.eserver.org/18666.html http://tc.eserver.org/18666.html There are many different ways to drive the design process. Critique meetings are one way to make sure teammates are involved, while maintaining a high level of design dialogue and quality idea discussion. http://tc.eserver.org/18674.html http://tc.eserver.org/18674.html This is an experiment in design education. The idea is to explode the process of design by forcing insane time constraints, and asking teams of designers to work together in front of a live audience. From what we've seen, it forces the discussion of design process, teamwork, and organization, and asks important questions about how designers do what they do. Below are summaries of previous events, and information about how to organize your own Interactionary. http://tc.eserver.org/18670.html http://tc.eserver.org/18670.html There are useful parallels between making films and making web sites or software products. We'd be wise to study how they manage creativity, and how our divisions of effort, and means of collaberation, compare and contrast. http://tc.eserver.org/18667.html http://tc.eserver.org/18667.html A list of the most common reasons engineering projects don't result in something that's easy to use. It covers diverse topics such as customer confusion, the impact of code architecture, the spinal tap commerative reason, and more. http://tc.eserver.org/18664.html http://tc.eserver.org/18664.html Perfection in design is not possible. No matter how much is known about a given business, user group or technology, you can not simultaneously satisfy all possible objectives. For any website or user interface, there are no mathematics, and no algorithms, for deciding which objectives to satisfy in a single design, or even for accurately defining an optimal solution within any of those objectives. There are usability, design and business methods that effectively evaluate and illuminate promising directions , but they are sensitive tools, that work more as guides, rather than maps. In general, any form of design involves too many simultaneous possible objectives and forms of solutions to enable any overall mathematical or algorithmic based confidence. An optimal design, in the broadest sense, is a mythical idea. http://tc.eserver.org/18678.html http://tc.eserver.org/18678.html How can a design make your web pages feel natural for users? How do you achieve flow in site navigation and design structure? http://tc.eserver.org/18671.html http://tc.eserver.org/18671.html This describes the role that I played as program manager for IE5.0, and the basic process we used. It's a good anecdote as to how one team managed the cross discipline work of design and usability, with the engineering and development process. http://tc.eserver.org/18669.html http://tc.eserver.org/18669.html It's easy to fall into working in response to how things are going, instead of using usability engineering as a way to help lead a team in the right direction. Thinking strategically about the connections between business goals, and engineering practices can can help. http://tc.eserver.org/18672.html http://tc.eserver.org/18672.html Unless you have the power to make business and development decisions for your project, some of your energy will be spent influencing those who do. Experienced usability engineers or interaction designers may have limited skill in influence, despite how significantly it can effect their ability to contribute to projects. It’s the smartest and most effective designers that work to understand the human to human interaction within their project teams, as part of their work towards better human to computer interaction.