Thu Apr 15 17:42:21 1999 Subject: Re: Creativity in the Digital Age > BTW, Cooper's feeling about UT is that it's too late in the > design process -- that it's a 'fix' that fits the current > development model (which he criticizes extensively). the same can be said of testing (aka: inspection) in any industrial process.. the basic mental model is, "we agree to make a certain number of pieces which will be defective enough that they have to be thrown away. then we'll try to find a test which eliminates a majority of the bad ones while incorrectly eliminating as few good ones as possible." the key objection is that when you focus on testing/inspection, you might forget to ask if the process really needs to generate that much waste in the first place. even when inspection works perfectly, it's expensive. you pay for the materials and time necessary to build the defective product, you pay for the level of inspection required to identify defective items, then you choose between paying for rework on those items or paying to throw them away. the alternative is to eliminate the need for waste (and therefore testing) by making sure your design is stable and can support production under an efficient process. you generally do that by building a lot of small prototypes which test a specific principle or process, and then throwing them away. there are two differences between throwing away a prototype and throwing away a product: first, prototypes are cheaper. second, you only have to throw away a single prototype per principle or process. the need to throw things away never disappears, but a good development methodology can help you throw away as little as possible. that doesn't mean that design completely eliminates testing, or that solving problems at design time is always cheaper than solving them at production time. designs, like any models, are based on a limited set of assumptions. there's always something you missed, or deliberately chose to leave out. some high-performance software development teams will in fact *demand* an average bug rate of about 1 error per 1000 lines of code. those bugs are the ones which are harder, and more expensive, to find at design time than they are to find through building and inspection. if a piece of code consistently passes inspection with a lower-than-average bug rate, it's considered a sign to check the inspection procedures for bugs of their own. granted, that type of precision is restricted to things like the flight software for the space shuttle.. the last known safety-related fault which flew was detected in 1986, and only one in-flight failure of any sort (a non-critical annunciation fault in '89) has been recorded since 1985. the story of how that software was developed is exciting, but it's the kind of thing you only get when a large number of people devote half their lives to making sure that nobody's gonna get hurt using *their* code. for things like websites, a good series of prototypes and some solid design thinking can eliminate most or all of your need for after-the-fact user testing. just remember to break it early, while it's still cheap. i personally suggest building the link structure of the site first, using nothing but pages of text links, with notes that describe the general contents of each page. that's about as cheap and easy to rebuild/rearrange as anything i've seen. while you define the structure of the site, you can refine the spec for the content you'll need. most of the time, you start with a mixed bag of content which will probably need to go in the site somewhere, and a whole lot of gaps that need to be filled. as the link model is refined, you can find the positions for the content which already exists, and decide what spacer material needs to fill the remaining holes. the other advantage of text links in design is that they give you a chance to find good names for you links. there are *way* too many sites out there whose iconic navbar runs something like: - squiggly arrow - umbrella - circle with lines through it - possible stick-man - etc. and the perpetrators usually get all huffy when you fail to realize that those translate to: - product information (the *flow* of product) - main page (the overall *coverage*) - site map (it's the *globe*) - company personnel (dynamic *people*) - etc. because they define 'creativity' as a big guessing game, where the sheer eloquence of the symbol expresses meaning without forcing the designer to use cheap cop-outs like literal description. usability is based on picking the cheapest damn cop-outs you can find, and making things so obvious that the eloquence of the symbol is irrelevant. that doesn't mean it's easy. making things cheap means making them simple, and simplicity takes work too. good link names tell the user what the can expect to find on the next page, but at design time they help you build the specification for the content which will go on that page. the idea is the same in both cases, it's just that the designer has the freedom to make the link fit the content, or the content fit the link. once you have the structure of the site laid out, and are fairly sure what type and quantity of content you'll have for each page, you can start into the realm of design where graphic artists excel.. arranging the contents of a single page in a way that is both visually pleasing and functionally efficient. having the site's taxonomy in advance actually helps the graphic designer, because they have a catalog of all the types of pages which need to be laid out. that allows them to develop the themes and conventions which will be used from page to page, to give the site a sense of unity. trying to work backwards sucks, because you can invent themes all day, but you don't necessarily know whether they'll fit the needs of the content. 1. well-defined core information 2. usable linking structure 3. spec for interstitial content 4. coherent style guidelines for content 5. good link names 6. site-wide navigational metaphors 7. per-page layouts 8. site-wide visual conventions & themes do it in that order, and you'll find yourself developing sites which are usable, intuitive, easy to manage, and just generally look good.