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.
Berkun, Scott. UIWeb (1999). Design>Usability>User Centered Design
INTERACTIONARY: Sports for Design Training and Team Building
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.
Berkun, Scott. UIWeb (2001). Articles>Management>Collaboration
Leadership in Collaboration: Film Making and Interaction Design
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.
Berkun, Scott. UIWeb (2002). Design>Collaboration>Interactive>Multimedia
Leadership in Collaboration: Filmmaking and Interaction Design
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.
Berkun, Scott. ScottBerkun.com (2002). Careers>Management>Collaboration>Interaction Design
The List of Reasons Ease of Use Doesn't Happen on Engineering Projects
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.
Berkun, Scott. ScottBerkun.com (2003). Articles>Usability>Engineering
The Long List of Reasons Ease of Use Doesn't Happen on Engineering Projects
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.
Berkun, Scott. UIWeb (2002). Design>Usability>User Centered Design
Making Usable Products: An Informal Process for Good User Interfaces
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.
Berkun, Scott. UIWeb (1999). Design>User Interface>Usability
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.
Berkun, Scott. ScottBerkun.com (2003). Articles>Usability
The Myth of Optimal Web Design
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.
Berkun, Scott. ScottBerkun.com (2001). Articles>Web Design>Assessment
The Myth of Optimal Web Design
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.
Berkun, Scott. UIWeb (2001). Design>Web Design>User Interface
Notes for Job Seekers in UI Design
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.
Berkun, Scott. ScottBerkun.com (2003). Careers>Usability>Interviewing
Notes on the Role of Project Managers in Interface Design
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.
Berkun, Scott. ScottBerkun.com (2002). Articles>Management>Project Management>Interaction Design
The Power of the Usability Lab
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.
Berkun, Scott. UIWeb (1999). Design>Usability>Methods
Problems with Training (And What to do About It)
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.
Berkun, Scott. ScottBerkun.com (2006). Articles>Education>Instructional Design
The Role of Flow in Web Design
How can a design make your web pages feel natural for users? How do you achieve flow in site navigation and design structure?
Berkun, Scott. UIWeb (2001). Design>Web Design>Methods
The Role of Project Managers in Interface Design
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.
Berkun, Scott. UIWeb (1999). Design>Project Management>User Interface
Strategic Usability: Partnering Business, Engineering and Ease of Use
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.
Berkun, Scott. ScottBerkun.com (2002). Articles>Usability>Collaboration
Strategic Usability: Partnering Business, Engineering and Ease of Use
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.
Berkun, Scott. UIWeb (2002). Design>Usability
Strategies of Influence for Interaction Designers
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.
Berkun, Scott. ScottBerkun.com (2001). Articles>Collaboration>Interaction Design
Strategies of Influence for Interaction Designers
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.
Berkun, Scott. UIWeb (2001). Design>Web Design>Interaction Design>Multimedia
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.
Berkun, Scott. ScottBerkun.com (2001). Articles>Collaboration
User Interface That Kills: Swords, Craft, and User Interfaces
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.
Berkun, Scott. UIWeb (2000). Design>User Interface>Web Design
The Web Shouldn't Be a Comedy of Errors
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.
Berkun, Scott. UIWeb (2000). Design>Web Design>Usability
Why Are Good User Interfaces So Hard to Make? Three Insights into Good Design
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.
Berkun, Scott. UIWeb (1999). Design>User Interface>User Centered Design>Web Design
Why Good Design Comes from Bad Design
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.
Berkun, Scott. UIWeb (2000). Design>User Interface
There are 15 readers currently online: 0 registered users and 15 guests. Register.

![]()
![]()


![]()
![]()
![]()