Congratulations—you've survived the most nerve-racking part of any project, the delivery of your design framework. By this time, you've hopefully got everyone excited about the design direction, and much of the uncertainty is behind you. Now, though, you have a big pile of hard work ahead. Fleshing out the detailed design means resolving numerous difficult questions: How much is essential to accomplish by a reasonable ship date? How will the engineers implement the functionality you've imagined? How will the design handle all those details and edge cases you've been able to ignore until now? How will that complex data visualization tool you've glossed over really look? It's not surprising that the detailed design work often takes more time than the rest of the process combined.
Aside from creating the best possible design within your business constraints, the objective of detailed design is to give the product team—especially the engineers—as clear and comprehensive a blueprint for the product's form and behavior as you can manage within the time you have. Good specifications help engineering managers develop more accurate estimates of effort and cost, while letting engineers focus on how to build the product instead of spending time on how it behaves and looks. Specs also help the quality assurance team plan their testing, let technical writers begin documentation early, and even allow the sales and marketing teams to start generating excitement before anything is built.
Equally important, detailed design specs help ensure clear communication and accountability on all parts of the team. Rather than arguing over whether a half-baked implementation meets a fuzzy requirement, a product manager can point to a spec and say, "It doesn't work or look like this, so it isn't done." In turn, engineers can say to management, "That's not what's in the spec we based our estimate on. It's going to take more time." You can get away with minimal specification and some missing details if you're doing a simple product with a small team of talented engineers, but detail and clarity are essential when you're building complex products with large teams or outsourcing any engineering or manufacturing.
This chapter outlines a handful of general principles to use in approaching detailed design of any sort, provides an overview of process and roles, and describes a couple of options for structuring your time depending on the engineering process and schedule.
Detailed design doesn't usually entail flashy feats of design acrobatics, as framework definition sometimes does; rather, it requires good balance and excellent juggling skills. On a daily basis, you must weigh pragmatism about implementation against optimistic advocacy for the most desirable solution. You must keep implications for the entire system in mind while you focus on the design of a single screen or component. You'll need to collaborate more frequently with more people than ever before, juggling their concerns and involvement with your own need for quiet design time. Like previous phases, detailed design requires a specific mind-set; integrating the following principles into your practice will help you succeed.
Although a brief period of relative design team isolation is useful for focus during modeling and framework definition, if it goes on for long, your design is unlikely to see the light of day. As you begin detailed design, frequent collaboration with multiple people becomes critical to success. You need design engineers to help you understand what's expensive to do and what's within reason. You may need subject matter experts to ensure that your design follows industry best practices and regulations. You'll probably work closely with a copywriter for a large corporate Web site. If you're designing an enterprise application, especially in a legacy environment, you'll most likely need business analysts to help you understand business rules and system capabilities; business analysts also help engineers know what aspects of which systems to tweak. Usability testers and perhaps human factors experts can help minimize the possibility for error and confusion in most products, and are especially critical for medical devices or any other application with potential safety issues. In any case, you're certain to need business decision-makers involved at critical points. External consultants with limited-length engagements should also make sure the project owner or someone else inside the client organization joins enough design meetings to understand the design intent inside and out.
Within the design team, collaboration happens in informal meetings and check-ins throughout each day. Outside the design team, collaboration is usually a combination of brief, informal communication and more-structured meetings. It's fine to drop by someone's desk or send an e-mail to ask a question or get an opinion, but decision making and detailed review of design in progress should happen with all of the necessary experts present, preferably at least once a week. Otherwise, you risk poor communication and uninformed decisions; even though extensive collaboration can feel like a drag on your schedule, it saves doubt, process thrash, and rework in the long run.
One of the most common mistakes in detailed design—especially interaction and visual interface design—is not being thorough enough. It's easy to plop a field or widget on the screen and think you're done, but interaction designers need to consider what kinds of data can and cannot be entered in that field, how to minimize errors, and whether the field is available or unavailable in certain circumstances.
With a complete spec in hand, engineers should not have to make a single guess about the appearance or behavior of the product. If you're designing a service with human "components," you might need to create scripts, guidelines, training materials, collateral, or other non-electronic tools. This kind of detail takes a fair bit of time or, if the details aren't terribly interdependent, a large team.
As in framework definition, you also need to consider the entire system, even when you're focused on details. What else in the system is aware of or affected by the contents of that field? How does the system get that bit of data to display it in a graph? Will moving that hardware control half an inch affect the screen layout? Can you use any red for common interface elements, or do you need to reserve it for visual feedback? If someone chooses "ship my items as they become available," how does that affect the shipping cost and the back-end fulfillment process? Every decision has the potential to affect some other aspect of the design.
Even the best designer in the world won't produce perfect solutions that are perfectly implementable on the first try.
Design consultants have a reputation for chucking a document over the wall to the engineers and running for the hills. There's some truth to this—most don't do it as a matter of practice, but even the best consultancies may be forced to do it as a matter of budget. Unless they are building the product as well as designing it, external consultants are often asked to provide only limited support once there's a detailed first draft of the design. After all, the design is done, right?
Any engineer or in-house designer knows this is not the case; even the best designer in the world isn't going to produce perfect solutions that are perfectly implementable the first time through. Fast whiteboard iteration and informal design reviews can catch a lot of issues and get that first draft of the spec pretty close, but subject matter experts, business analysts, and engineers usually need to spend some time reviewing the design's finer points to spot more subtle issues, such as a workflow detail that isn't quite in line with best practices, some aspect of the visual system that's going to be difficult to build, or a physical-surface detail that will be tricky to mold in manufacturing. Also, the point at which you have a complete or nearly complete first draft is usually the right time to do a thorough usability test to make sure you haven't made little design mistakes that only users can help you identify.
For these reasons, it's best to document the completed design once you've gone through a round of whiteboard or physical prototype iteration with the necessary experts, then give the draft spec to the whole project team for an intensive review while you either work on another chunk of the design or prepare for a round of usability testing. Once you've got useful feedback, you can clean up any problems—which are typically minor if you've used good process so far—and revise the spec to make it "final." (Always keep in mind that unexpected issues could still arise during implementation.) In other words, budget your time to touch every part of the design twice; the second iteration should go much faster than the first.
For interaction and visual design, this document-then-iterate cycle involves not only piles of screen drawings, but also a fair bit of text. Industrial design documentation consists primarily of CAD files, renderings, physical test models, and color/material/finish (CMF) specs, which are then reviewed and iterated—usually a few times—with the mechanical engineering team. In either case, expressing the design intent in concrete and detailed terms is necessary to ensure thorough review.
Some designers advocate multiple rounds of iteration and testing, but this approach provides diminishing returns for a couple of reasons. One is that multiple rounds of very fast iteration are already happening at the whiteboard or in CAD files, then being assessed using personas and scenarios. Another is that the methods and practices described in this book, when applied by skilled designers, tend to yield design that has only minor usability issues; advocates of multiple rounds of testing are often assuming that design is based on inadequate research, done by unqualified individuals, or done using poor process. (Of course, if your first test is a disaster, that tells you that something about your research, process, or skills needs some work! If you get a poor test result, you'll want to do another round of iteration once you identify and address that larger issue.)
As part of your post-framework discussion with stakeholders, you'll need to establish how far ahead your design should look. It's usually important in a deadline-driven project to focus the design on only what can be built in that immediate release. This may seem obvious, but it's a challenge for many designers to dial down their natural idealism. Don't let go of it entirely, though. Advocate for the better design solution—just pick your battles carefully.
Sometimes, however, it's useful to develop detailed software design in a slightly more ambitious way, including functionality or more challenging design approaches you anticipate might not make it into the near-term release. As a more complete design emerges, everyone on the product team can make a better assessment of what is or isn't worth stretching the schedule, then you can pare down the detailed design as needed for final implementation.
If you haven't reached consensus on your focus in the design vision meeting (see Chapter 19), hopefully your project owner is making sure the appropriate people are researching the open issues. Within a few days, you should be able to sit down with the necessary stakeholders to agree on what probably will or won't be in the upcoming release and how far out you should design.
For devices, it's best to settle on the basic physical requirements—such as approximate size and shape, key moving parts, input methods, and component architecture, including screen size and type—before investing too much in evolving and detailing the physical product design. For interaction design and visual design on any platform, you need to know the input mechanisms as well as the physical size, resolution, and bit depth of the target screen. Screen requirements can be tricky with desktop and Web applications, since end users typically have a range of display setups; the best solution is usually to aim for what most of your target market is likely to have by the time you ship. It's also helpful to know what tools the programmers will use to develop code, so you can take advantage of existing libraries.
You may find it surprising how often stakeholders don't understand the time and cost impact of changing their minds about any of these topics. On a project for a handheld consumer device, I once had stakeholders insist that a segment-based display—which has very little flexibility from an interaction design perspective—was necessary for cost reasons. A few months later, before the rather complex engineering was anywhere near done, pixel-based displays had dropped enough in price to be feasible. The interaction and visual design had to be done over. On another occasion, the project owner insisted on a device with a 12-inch touch screen, only to ask for a screen half the size once she saw a near-final appearance model. She expected that the on-screen elements could just be shrunk to fit, though of course this would lead to illegible type and unreasonably small touch targets. In both cases, various members of the design team had done their best to educate stakeholders about the implications of their choices; clearly, communication about this is something you can't overdo.
Every design decision has a cost and a benefit in terms of time, money, usability, sustainability, and competitiveness.
Every design decision has a cost and a benefit in terms of time, money, usability, desirability, sustainability, and competitiveness. Some of these decisions are up to designers while others can be worked out between designers and engineers, but the most critical trade-offs have to be made by the product owner or a larger group of stakeholders. Most often, your job as a designer is not to decide what trade-offs to make, but simply to decide what's worth advocating for from the perspective of desirability and perhaps sustainability—other stakeholders typically have time, money, and competitive considerations covered.
The cost-benefit equation is well understood by most teams delivering physical products. It's clearly worth adding a few gigabytes of storage that cost you 10 percent more if it lets you charge 30 percent more, but probably not worth using an expensive color LCD just to display one line of text on an office phone. The environmental cost-benefit is becoming increasingly clear to product companies and manufacturers, as well; even when the more sustainable option adds a little bit of up-front cost, there are often savings elsewhere in the process from reclaiming used products, not having to clean up toxic waste, and not having to combat negative publicity. Moreover, being seen as "green" can be a useful differentiator with environmentally conscious consumers.
These trade-offs can be less clear in software since there's not a manufacturing cost to consider, but even so, "reduce, reuse, recycle" still applies. In the environmental sense, reducing means considering whether you really need that processor-intensive capability (which will cause people to dump their old hardware and buy new) just because it's cool. In the economic sense, it also means considering whether a custom control that takes three weeks to code is really that much better than something "off the shelf." Reusing and recycling involve looking for opportunities to leverage a bit of code written for one function in another. Rather than using two slightly different controls or screen layouts, see if the same design can serve both purposes. This saves expensive coding time and usually leads to a cleaner, simpler, and more desirable design.
Many detailed design decisions involve conveying the appropriate experience attributes. Many of these considerations are related to the design language, which is covered in Chapters 17 and 18, but the design language is not the only communication vector. Consider how your on-screen text, the product's surfacing details, and overall behavior either contribute to or detract from the desired attributes.
This is especially important with consumer products, where your ability to delight users can make the difference between a ho-hum device and an enormously successful one. What delights people is usually an extra touch that's novel, playful, and somehow unexpected. Apple excels at this—the nearly physical "inertia" effects used in scrolling on the iPhone, for example, add a bit of life to an otherwise tedious task. Keep these touches subtle so they won't become annoying when the novelty wears off, though; the genie-returning-to-the-bottle animation used to minimize windows in Apple's OS X doesn't get in the way, but the ripple effect for adding new widgets to the desktop would be a bit over the top for a frequently used function. Mind you, if you don't have usefulness and usability taken care of, the extra goodies won't overcome user frustration.
Process and project management are closely intertwined during detailed design; the design team must coordinate a multitude of varied, interdependent tasks and still generate a huge volume of work in a short time. The overall process builds on the same techniques used during framework definition, but requires steady output at a greater level of detail.
The core design team of design team lead, interaction designers, visual interface designer, and sometimes an industrial designer should remain intact through this phase for most medium and larger projects; very small or narrowly focused projects may only have one or two of these roles from the outset. However, there are times when it's useful to expand this team (or keep any additional visual and industrial designers involved) after the design vision meeting. Whether to do so depends on which is more important: finishing the design sooner or doing it at lower cost?
It's sometimes possible to increase the number of people working on a project to finish a design in less calendar time. The feasibility of this depends on the nature of the design problem. It's difficult to divide and conquer when you're designing a simple product with tightly integrated functions, such as a basic e-mail application, because the inefficiency introduced by the larger team is likely to erase most of the gain in calendar time. However, larger teams can work well with multi-interface enterprise systems, service design with multiple components, or anything else with distinct aspects that aren't too interdependent. For example, a museum information system that involves a kiosk and a handheld device could make use of two interaction design pairs, with one pair focused on each platform, as well as a couple of junior designers to assist the lead visual and industrial designers with details and production.
This larger-team approach is a bit less efficient than having one smaller team design the complete system; it requires more time from the team lead and more intrateam meetings to ensure the consistency and coherence of the solution. Unless they were involved in the framework definition phase, the additional team members also require a bit of ramp-up time, but you can minimize this problem by distributing the original team members (e.g., one of the original IxD pair works on problem A with a new team member while the other works on problem B with another new team member) and having the ID and VisD maintain lead roles. This is shown in Figure 20.1. It's effective to develop two or three significant parts of the design in parallel as long as you have an experienced team and a full-time project lead, but simultaneous design on four or more complex problems is likely to result in some design incoherence, because one team lead may no longer be able to keep the whole design in her head.
Historically, product designers of various types have often been called into the engineering process at the end to put a pretty face on an already-engineered product or to spackle some usability over the cracks in the walls while the house is falling over. In reaction, many designers of various disciplines have been insistent that design needs to come before engineering; in software, some have said that design must be finished before coding begins. Some people incorrectly interpret Goal-Directed Design in this way; the framework should ideally be designed before major technology decisions are made, but it's essential that design engineering happen in parallel with detailed design.
We all see the world through the eyes of our own professions, so of course everyone involved in product development thinks his discipline is the horse that has to go before the cart; this has been the genesis of many product development methods. People tend to forget that a horse with a cart but no human to drive it might be happy for a while, but he'll eventually wander around, irritated by dragging the cart and not accomplishing much. Engineers without designers and designers without engineers will do the same. It takes more effort, but engineering and design must function less like a horse and cart and more like a constant feedback loop: The designer says, "I'd like to have it work like this," the engineer responds that "this" is going to be very difficult, and the designer either convinces a business stakeholder that the difficulty is worth it, or the designer and engineer together come up with an alternative.
Figure 20.1. When expanding a team to handle multiple interfaces or system components, keep one person from the original team involved in each aspect of the project.
Anyone designing software has to contend with a whole minefield of strongly held beliefs, particularly of the waterfall-versus-agile sort.
Perhaps because they are less mature than other forms of product development, the design and engineering of software seem to create a great deal of angst about who's driving and how the whole effort gets from point A to point B. That's not to say there's no design versus engineering tension in hardware development—simply that anyone designing software has to contend with a whole minefield of strongly held beliefs, particularly of the waterfall-versus-agile sort.
Product managers (PMs) and other non-engineers have long struggled to gain visibility into and control over the engineering process. When it comes to software engineering, in particular, the work product remains invisible for a long time, so it's hard for an outsider to understand or respond to it until construction is nearly complete. Combine that with poor or absent design and you get a product that's not what the PM expected. The PM then says the product doesn't satisfy the requirements, the scope changes, and suddenly the engineers are in trouble for slipping the deadline.
Waterfall methods attempt to address the problem by getting maximum clarity on requirements before coding begins: Each phase of the work is theoretically complete and correct before the people downstream begin work on the next phase. Many designers slip comfortably into this sort of process. However, some engineers understandably resist these methods when they're handed a fait accompli (often in the form of poorly articulated requirements) and told to go make it work. Overly narrow interpretation of waterfall principles leads to isolated silos, uninformed decisions, and a lot of inefficient rework.
There are cases in which a waterfall-like approach is advisable, though, such as with less-skilled engineers and on large, complex, or mission-critical projects that require structure and predictability. Design can effectively bridge the gap between requirements and technical specifications in the Rational Unified Process (RUP) and other waterfall processes, which helps alleviate many engineering concerns. However, strict waterfall is pretty much never a good idea—at a minimum, there should be informal design engineering reviews throughout the detailed design work, so that information flows in both directions.
In software development, frustration with waterfall approaches has led to the emergence of various agile methods. These differ in details but have a handful of assumptions in common:
Design works well with both waterfall and agile engineering methods, and can address weaknesses in each.
Ever-changing requirements are developed by business stakeholders and given to engineers
Coding should be time-boxed in short periods (called "iterations" or "sprints") to allow for continual value generation and learning
Small engineering teams should succeed or fail as a group
Communication should be frequent and face-to-face
Working code should be the primary measure of progress
From what design teams have seen at Cooper and heard from our clients, agile methods are most successful with small teams of skilled engineers who are working on fairly simple products. We routinely see these methods fail on large-scale IT projects, however, and for every client we encounter who has enthusiastically adopted agile methods, we encounter one who has abandoned them for being ineffective.
Agile methods and Goal-Directed Design are similar in that both involve iterative approaches, small teams, and an emphasis on frequent communication and visible work product. The most fundamental difference between the two—and the source of some "religious" wars—is in the assumption about whether requirements and design are really engineering problems. GDD, as you've no doubt seen throughout this book, is based on the premise that design should be done by designers. Also, rather than giving up and assuming that requirements are unknowable (which is an understandable view given the experience of many software engineers), GDD is all about nailing down requirements by making them concrete in the fastest, cheapest form possible: sketches.
For the two approaches to work together, engineers need to agree that designers have something important to add, and that it's best for the design team to do their own "iterations" in sketches to reduce the amount of time wasted on badly articulated requirements before the first coding sprint begins. The design team, in turn, should ideally deliver design in small (but not arbitrarily defined) chunks. Figure 20.2 shows how this approach differs from the others.
Design team members continue to have some overlapping responsibilities during this phase, but they also spend more time working alone at their desks on role-specific tasks. Frequent design team check-ins are still essential, as is planning a detailed project calendar together. In contrast to the framework phase, though, there are quite a few meetings that can happen without the entire design team involved.
Note that the following tasks and the subsequent few chapters focus on software and convergent software/hardware devices; the artifacts involved in service design—which may include anything from building architecture to printed collateral to employee training materials—are too varied to describe in any great detail, though the general process of collaborative refinement is similar.
In particularly complex domains, the interaction designers (generator and synthesizer, IxDG and IxDS) may begin the phase (or the work on a specific part of the design) with a bit of supplemental research. Aside from this, most of their days are spent generating additional scenarios—starting with common variations on the key path scenarios (see Chapter 16) and ending with edge cases—then filling out and adjusting the design to address them. This work still happens largely in design meetings, but as the design work progresses, the two spend an increasing amount of time each day at their desks.
The IxDG, working with a set of widgets and styles defined by the visual interface designer, does the initial layout for each screen. Much of this work is just capturing decisions made at the whiteboard, but there is nearly always a little bit of adjustment that happens as things get translated from sketches to pixels.
At the same time, the IxDS uses his notes from each meeting to begin drafting the specification, typically using whiteboard photos as image placeholders until more-finished renderings are available. Just as drawing the design tends to reveal flaws in structure and layout that seemed to work on the board, documenting the design helps reveal incomplete thoughts and problematic workflow.
Throughout the process, the interaction designers meet with software design engineers, subject matter experts, business analysts, or copywriters as needed. The IxDG and visual designer work closely together on the visual system, while the IxDS works closely with the VisD on making sure the visual style guide and the form and behavior documentation work together in a coherent whole. Interaction between the industrial designers and the rest of the team may decrease as the design language and the control types and locations are firmed up, though any contemplated changes require ongoing discussion.
The visual designer uses the feedback on the design language studies to create one or two archetype screens. These show the visual language applied to a real screen design, which allows for a more detailed assessment of how well it's working. Depending on the time available and the level of detail achieved in the framework phase, this might happen late in framework definition or at the beginning of detailed design.
After this, the VisD develops a first draft of the visual system based on the archetypes and his understanding of what other screens are likely to contain. This system contains a specific grid for the layout, a set of fonts of specific size, color, and style for various purposes, and detailed treatments for controls and data. As the interaction designers develop more-detailed designs for the content and structure of each screen, the VisD adds to and evolves the visual system. He also improves upon the IxDG's first take on each screen, optimizing layout and hierarchy, and adjusting the system if needed. He reviews these with engineers to ensure that the way controls are drawn will work with how the code is being written.
As the major functional elements of the visual system start to settle down, the VisD can begin working on icons or other visual elements that aren't on the critical path for the rest of the design; such tasks might also be assigned to a second designer. These, too, must form a coherent system. When there is hardware involved, the visual designer generally collaborates with the industrial designer to ensure that any graphics or labels on the device are both usable and appropriate to the brand.
Like the IxD synthesizer, the VisD documents the system as it takes shape, partly as a way to avoid a time crunch at the end and partly to aid in identifying holes. As a last step, the visual designer (or perhaps a junior production designer) slices up any assets the programmers need for construction; this may occur as part of a separate development support phase (see Chapter 25). In the case of physical products, he also supplies any text-labeling specs and image files to the mechanical engineer for either print application or emboss/deboss specifications, so the mechanical engineer (ME) can fully document all aspects of the product for manufacturing.
The industrial designer's work combines aesthetic, brand, and practical considerations in a tight iteration loop. He works with interaction designers to fine-tune physical control input behaviors, such as how a rotary knob communicates one step, how much friction there is, whether there should be a tactile or audible click, or how quickly the screen scrolls in response to the dial. Based on this collaboration, the ID works with the ME to identify and test a range of controls.
ID collaboration with engineering is, if anything, even closer than the collaboration of interaction designers and visual designers with programmers. Along with refining the overall form, proportion, surfacing, colors, and finishes, the ID works closely with mechanical and electrical engineers to finalize materials, prototype potential mechanisms and parts to ensure good fit and function, optimize the fit of components inside the device, and finalize the part count and assembly method to make manufacturing efficient and reliable. The ME team generally takes responsibility for the final CAD database delivered to manufacturing.
This process is pretty straightforward if there aren't a lot of moving parts, a need to house many components in a tiny space, or a requirement for waterproofing or heat and electrical shielding. The average DVD player, for instance, is primarily an aesthetic redesign exercise because it is an established architecture without novel engineering challenges, whereas a tiny cell phone employing unique interaction or technology takes more back and forth, since it may require extensive testing with electrical engineers for thermal management and other issues; the need for airflow and cooling of internal components can drastically affect the industrial design. A device that must withstand considerable physical abuse or wet conditions can also require more time, and perhaps even research and development in materials science.
This phase typically involves some hand sketching to communicate design intent, but relies more heavily on 3D modeling over the final component layout in a CAD application, with files passed back and forth between the ID and ME. Photorealistic renderings based on the CAD file are critical communication tools within and outside of the design team. Inexpensive foam or resin models focused on size, shape, and major mechanical functions have generally been developed in the previous phase to aid in narrowing the design direction, but might still be used in the early stages of detailed design. As confidence in the design increases, the hardware team develops more elaborate (and expensive) working prototypes and appearance models as learning tools before committing to final tooling and manufacturing.
The team lead's role remains the same: ensuring that the design is good, that the whole design team is on schedule, and that internal and external collaboration are going well. She also clears obstacles, gets the team additional resources when needed, and sometimes pitches in on design or documentation if a schedule crunch is unavoidable. No project lead is equally proficient at all aspects of design during this phase, so she ideally involves other senior designers as needed to review work and support various members of the team.
Either immediately before or immediately after the design vision meeting (see Chapter 19), you'll need to develop a list of design topics that require further work. You'll then estimate the amount of effort they will entail, suggest priorities and get agreement from stakeholders, work with the engineers to decide how you'll deliver them, and finally develop a day-by-day project plan as a team.
Develop a detailed topic list with time estimates in half-days or days. This will help you develop a day-by-day plan and keep everyone on schedule.
Using your framework and key path scenarios (plus a list of less common scenarios you already know you have to cover), you should be able to generate a list of design topics to use as a discussion tool. Although each team member might prefer to start a list individually, it's best to generate or at least review the topic list together, since one person's list might remind others of topics they haven't considered.
The list need not include every widget—you'd drive yourself crazy. Instead, focus on tasks and elements that will take you half a day or more to draft. For an e-mail and calendaring application, for example, the interaction design topic list might look something like this:
Main e-mail list view
Alternate e-mail list views (conversation view, detail list view)
Managing folders and conversations
Composing and formatting messages
Mailbox filtering rules
Spam handling
Mail error handling
Main address book screen (alphabetical list)
Alternate address book views (by company, detailed view)
Creating and managing contact groups
Creating and managing contacts
Address book error handling
Main calendar screen (week)
Alternate views (daily, monthly)
Recurring appointments
Integration of meeting invitations with messages
Calendar error handling
Main toolbar and menus
Help behavior (not content)
The visual designer's list would mirror this, but also contain key visual design tasks related to establishing the visual system, such as the layout grid, icons, and typography. When there is hardware involved, such as on a phone, the industrial designer's topic list would include things like angle adjustment and the handset, as well as the keypad and various controls.
Next, estimate how long a first pass at each of these design topics will take. Estimating in half-day chunks works well. There's no specific formula for doing this; it depends on the complexity of each bit of design. However, if you're estimating design topics at more than a couple of days each, break them down into smaller bits; larger chunks make it difficult to see whether you're running behind. In complex domains, you might want to allow for a day or so of detailed questions with a subject matter expert before you start each design topic.
Collaboration, essential though it is, eats a lot of time. For interaction design and visual design, one day of collaboration for every four days of design is usually an effective metric if your collaborators are accustomed to working with designers; I've sometimes allowed a bit more than this when the lead engineer or project owner tends to revisit old decisions and get pulled into edge cases too early. Effective collaboration usually yields a list of things to adjust, so allow another day or so per collaboration day to modify the design. (Note that this doesn't necessarily mean collaboration will occur only on specified days.)
For industrial designers, collaboration is more likely to be ongoing throughout the day, especially early in the phase when the mechanical engineer is essentially a design partner; unlike interaction designers and programmers, the ME and ID are working in much the same medium, even though their CAD applications may differ slightly in focus. The amount of ID time required depends on the complexity of the product, the skill of the engineering team, and the need for further exploration, but the ID might spend as little as a week or two of effort in this phase for a simple product architecture.
Documentation should be occurring as design progresses, but you will also need some dedicated time to draw and write as the design settles down. For interaction and visual design, documentation typically requires about one dedicated day per three design days, plus one to three days for team-member review, proofreading, and cleanup. These estimates don't include any sort of interactive prototype or animation.
Industrial design documentation is generally lighter; the ME is responsible for turning the CAD files into final specs for manufacturing. The ID does typically document his intent for color, material, texture, finish, and any application of graphical elements.
If you're able to make a second pass at the design, such as after a round of usability testing or extensive review by subject matter experts and engineers, plan on spending about 30 to 50 percent of the original design time estimate on revising the design and its documentation, depending on how complex it is.
Most project managers add 10 to 15 percent to their time estimates to allow for forgotten details, unexpected problems, communication delays, and other potential frustrations. Whether you should do this depends on what you think will be more effective with your stakeholders in the long run: Is it better to hit them with the bad news first and avoid setting high expectations, or to state that your numbers assume no delays and deal with the additional time only if they're a problem? I usually find that stakeholders hate surprises, so it's better to plan on the contingency time if you can. Your project owner may have a different preference. At a minimum, though, allow for a couple of days to address topics that were more challenging than you expected.
Figure 20.3 provides a summary of these metrics for estimating your design time. Note that these estimates assume each team member has a consistent amount of time per day to spend and that each is experienced and comfortable with her tools and tasks. Note that the amount of time spent on a topic (and therefore the amount of overall time spent) varies widely depending on the team's experience and skill level; experienced designers can move 25 to 50 percent faster than less-experienced designers and easily twice as fast as non-designers (such as subject matter experts or product managers) doing the same tasks.
Once you have your list and estimates, recommend what you think the priorities are, especially if there is a limited time in which to design and build a product. I've generally found that three levels of priority offer enough distinctions:
The amount of time spent on each topic varies widely depending on the team's experience and skill level; experienced designers can move 25 to 50 percent faster than less-experienced designers.
Essential: You won't have a product or a coherent design without it.
Important: There may be a noticeable lack in the product or design without it.
Optional: The world won't end if it gets postponed to a subsequent version.
When you're done, you should have something like Table 20.1, which will serve as the basis for a critical discussion with stakeholders.
There are a couple of other decisions that will affect how much time the detailed design takes. One is how you'll deliver your work. The other is whether or not you need to do any usability testing. You should plan on discussing both with stakeholders.
Whether you deliver design in a single, meal-sized document or serve it up in smaller, snack-sized pieces isn't entirely about how the engineering team structures their time. It's possible for an agile team to work from a completed first-draft spec if they're starting behind the design team, as long as design engineering has occurred along the way. It can also be useful for a more waterfall-oriented team to get chunks of specification ahead of time, so they can start building some of the more complex pieces of code, working out tricky mechanical problems, and the like.
Many software or service design problems lend themselves to a chunked approach in which the design team delivers part A and goes on to work on part B, while the engineers review and perhaps begin to work on part A. However, as with splitting the design effort across a larger team, the overall gain in calendar time results in some loss of efficiency for both designers and engineers. For example, if you were designing an e-mail, calendaring, and task management application, you could presumably deliver the calendar part of the design, then turn your attention to the to-do list. When you suddenly realized that it would be useful to display to-do items for each date on the calendar, you'd need to let the engineers know right away that the design was going to shift, then go back and revise the calendar design.
This need to adjust design after the first draft has been documented leads to a certain amount of inefficiency, so you'll want to add a little bit of design adjustment and documentation time, such as a day or two for each two weeks of design.
The role and timing of usability testing are discussed in Chapter 23, but it's a good idea to determine whether you'll be doing any before you lay out your detailed schedule. If a third party is conducting the test(s), each test need not add more than a day or two to the design team's schedule, as long as testing happens in parallel. If the design team is conducting the tests, each test could add as much as ten days or more, depending on the degree of fidelity and formality, the size of the sample, and the location of your tests.
Once you have a list of your design tasks and some idea of how long they will take, sit down with your key stakeholders to review and prioritize the list. This should happen as soon as possible after the design vision meeting. The engineering leads should take part in the discussion as well; although engineers probably cannot provide an accurate estimate of engineering effort until the design is a bit more crystallized, stakeholders need to understand their best guess as to how much time and cost will be involved in executing various parts of the design.
When time and budget are limited, less-critical features and functions are usually the first things to go. If you must, consider trimming your contingency time, usability testing, and second pass at the design. Reducing the collaboration time is a last resort; you may produce a larger volume of design in a short time, but there is a greater risk that you will spend time polishing something that is too difficult to build.
If you're asked to leave some parts of the design to engineers—an unfortunately common occurrence in software—explain that this does not actually save time and generally delivers worse results. If you are still forced to do so, at least make sure you build in plenty of collaboration to ensure that the engineers understand not only the design, but the principles and rationale that guide it, and make sure the parts you leave undone are limited to routine forms and other straightforward components.
Finally, you'll need to lay your tasks out on a calendar. Start by drawing (or projecting) an actual calendar on the board and filling in the design team's vacation dates and any conflicts for key stakeholders, and then lay out your tasks.
If you've done a good job on the framework, you should know what most of your tasks are at this point, barring any feasibility issues that come up along the way. The best way to avoid a crunch at the end (or worse, a missed deadline) is to plan your work day by day. Lots of small deadlines will help you see if you're falling behind so you can catch up right away. They're also essential in coordinating the work of multiple designers and engineers. In a team environment, hitting the one big deadline at the end isn't good enough, because last-minute work on your part means last-minute work for everyone else, too.
As the saying goes, if you put the little rocks into the jar first, you might not be able to get the big rocks in at all. What this means for design is that you should start with the design problems that are either foundational or big and sticky. This can usually be driven by your design instincts, but there may be some aspect of the design the engineers need first; it's fine to be guided by this as long as the engineers' priority topics don't depend on you designing something else first. Follow these issues with those of medium difficulty, and leave straightforward things until the end. For interaction design, this means handling navigation issues and big, complex tools first, with routine forms and dialog boxes at the end. For visual design, the layout grid, common controls, and other aspects of the visual language should come first; it causes little difficulty to save icons until last. Industrial designers must address overall shape, assembly, and moving parts before focusing on purely cosmetic details.
There are several reasons to handle the big issues early. One is that more aspects of the design depend on them, so you'll save rework later. Another is that if you're stuck with a fixed (and inadequate) budget, especially for software, it's better to leave the engineers with the routine bits than with the trickiest parts of the design problem.
It's always handy for you and your collaborators alike if your check-in schedule can be routine, such as every Thursday at 2:00. However, it's usually more important that check-ins occur when you need them; if that means one on Monday and another on Thursday, your collaborators will probably be happy to oblige as long as you're making good use of their valuable time.
Depending on how your design time is accounted for, you may be asked to deliver whatever design you can fit in by a certain date. If this is the case, you'll need to work backward from that date. Note your delivery date and put in a day or two for documentation review right before it. Divide the remaining time by four, then allocate the last quarter to documentation. Add a day or two of contingency time just before the documentation days. Finally, drop your design topics and collaboration time into the remaining days.
While detailed design is usually less dramatic than earlier phases, it remains critical to success. Your ability to collaborate with others outside the design team to translate your vision into a buildable product is what determines whether that vision gathers dust on a shelf or makes it into the hands of users. Detailed design demands not only a solid understanding of design principles, patterns, and process, but also excellent time management, collaboration, and communication skills. In some ways, your collaboration during framework definition is merely a warm-up for the actual design performance, in which every part of the symphony must play in tune and in perfect time.
Chapter 21 outlines some useful principles and patterns for detailed design. Chapter 22 describes how to evolve the form and behavior and develop a visual system. Chapter 23 will help you determine how and when to integrate assessment techniques, such as usability testing, into your process. Finally, Chapter 24 offers guidance on effectively communicating the details of your design to engineers and other constituents.