Finally, implementation begins! You've designed a UI Spec based on the Functional Requirements, you've designed the underlying architecture based on both of those, and you've worked out some of the engineering details needed to support the UI requirements. You've got a Feature List divided into priority categories, and you're ready to start the Initial Development phase.

We make a distinction between the Initial Development phase and the Iterative Development phase. In the Initial Development phase, you build the features as they were designed. You start with the Core features (the ones you absolutely need to start using the technology in a meaningful way) but without the supporting features that make the application more interesting to use. Once you have the Core set, you start to use the system yourself and build whatever Important features you need to let other people start testing it. Once you start to get usage feedback, you begin the Iterative Development phase on those initial features, while you also do Initial Development on other Important features. So every feature has an Initial phase, when it is first built, and most go through an Iteration phase, during which they are revised and polished to make them smooth and cooperative. The first half of implementation consists mainly of Initial Development, and gradually you shift more toward Iterative Development of existing features until all the features are implemented and polished. This chapter focuses on Initial Development, and as you'll see, some of the examples took place after we had collected information from the usage study on related features we had already implemented.

This phase is an exciting time when your technology starts to come to life, but it also involves a lot of heads-down development to get the basic system working as designed. It seems pretty straightforward, except that as features start working, you find that certain aspects of your design won't work the way you'd hoped, so you have to adjust. This phase is when collaboration between the designer and engineer becomes especially close, as you work together to resolve problems so that both parties' concerns are addressed as well as possible. It usually takes some work to understand the crux of each other's concerns, but once you do, you can usually find an alternative approach that is acceptable to both. If an engineer designed your technology's user interface, that engineer needs to play the role of the designer when issues arise. Of course, that can be difficult if the issues involve that engineer's features, which is why it helps to have someone dedicated to the designer role. If you can't manage that, perhaps another engineer on the project can play the role of user advocate on technical issues that arise in the engineer-designer's features.

In the following sections, we discuss examples from Hubbub, focusing on unanticipated issues that affected the user interface and how we handled them. We describe some cases where we resolved the issues on engineering grounds, working around them in the UI, and some cases where we did the reverse. Sometimes UI issues arose that Ellen hadn't anticipated in the UI Spec. Other times Alan didn't foresee the implications of his decisions for the UI, but later we discovered unanticipated effects (not always negative, as it turned out). We discuss these types of examples and others, focusing on how we tried to resolve the issues by balancing the cost of engineering with the value of the usability improvement. These examples illustrate some lessons we've learned about managing this delicate balance, and about the process of collaborating to make these decisions.

Issues Resolved on Engineering Grounds

Initially, Alan and Dipti were able to get the Core features working as planned. After all, we'd spent a lot of time planning the UI design and architecture to make sure that these features could be implemented. But then a few issues started to arise — issues that affected either subtle aspects of Core features or more obvious components of Important features (which got less attention during our planning phase). In the majority of cases, we were able to modify the UI to accommodate the engineering issue while still behaving like a butler.

Example: Edge Cases Versus Common Cases
A simple example arose because of the Palm's memory limitations. The UI Spec indicates that users can scroll back through any conversation to its beginning. They can also hold multiple conversations at once, putting as many as they want "on hold" while they view other screens. This concerned Alan. Here's how our discussion went:

Alan: I'm a little worried that if we keep around all the messages from all the conversations, we might run out of memory. Do we have to let people scroll back all the way to the beginning of their conversations?
Ellen: Well, on the small Palm screen we can't fit as many messages, so I think people will be scrolling back more than they would on the PC. Plus, they might miss some messages that arrived in another conversation. They need to be able to scroll back to see what they missed.
Alan: I'm not objecting to people scrolling back, I'm objecting to people being able to scroll back indefinitely.
Ellen: Well, how far back can you let people scroll without worrying about running out of memory?
Alan: How about something like 100 messages per conversation, about 15 or 20 screens?
Ellen: Oh, 100 messages would be okay. I was expecting you to say something like 10 or 15. I think it would be pretty rare for anyone to need to go back that far on a Palm.
Alan: Okay, good. As long as we're limiting their maximum size, I'm happy.
Ellen: If they try to go back further, the messages just aren't there, right? There's no annoying error message popping up, complaining that we've run out of room. [Solve Problems; Don't Complain or Pass the Buck]
Alan: Right.
Ellen: Great. What would happen if they had 100 messages in a conversation and they scrolled all the way to the beginning and stayed there as new messages came in?
Alan: The text would scroll up, pushing the oldest message off the top.
Ellen: Okay, that's good.

This conversation was representative of many we've had. Alan is concerned about the edge cases — someone having dozens of conversation screens open, each with thousands of messages in them, and never closing any of them. He's worried about having no limit at all. Ellen is thinking about the common case — figuring that Palm users may have as many as five or six simultaneous conversations at the outside, with few of them going longer than, say, 50 messages. Neither of them says so explicitly. Instead, Alan just asks about scrolling back to the beginning of conversations, which Ellen thinks is important in her scenario. By getting specific about numbers, we realize that we're worrying about different orders of magnitude. Setting a high limit by Ellen's standards makes both of us happy because Alan gets his limit and Ellen handles the vast majority of cases. Remember, you might be able to construct a scenario of the rare case happening, but you don't have to design for that case, you just need to handle it. In other words, those cases shouldn't cause the system to break, but don't sacrifice the user experience in the common case to handle those rare cases.

Collaboration Guideline

When rare but possible cases arise, remember that you don't have to design for those scenarios, you just need to handle them gracefully.

We've seen many cases when a designer shows or describes a design to an engineer, who assumes it has to be implemented literally as described, and then declares that it can't be done. While it may be impossible to implement as described, you can usually find a design that would provide the important attributes of the feature. If the engineer can explain which aspects of the design they object to, and if the designer can explain which parts are critical for the experience they're trying to create, they can usually find a variation that works reasonably well for both. This is why it helps for designers to develop a general understanding of the relevant technical issues. If they don't, they will have trouble communicating their needs in terms the engineers can work with. On the other hand, engineers should respect the designer's judgment on issues relating to user behavior. Since everyone is technically a "user," many people are tempted to assume that they know how users behave, but it is the designer's job to know, so their judgment should prevail unless solid evidence indicates otherwise.

Collaboration Guideline

When conflicts emerge between design and engineering goals, get concrete and specific about your concerns. Try to clarify the crux of the engineering concern and the key elements of the user experience. Don't assume you're imagining the same constraints on the feature. And don't assume the feature has to be implemented literally as first designed. Instead, work together to find an alternative design that is acceptable from both perspectives.

Collaboration Guideline

Designers should take time to learn the basics of the technical issues affecting their system so that they can understand the engineering constraints and communicate user needs more effectively. Engineers should assume that the designer knows more about user behavior than they do, even though they are users too.

Example: Implementation Effort Versus Usability Value
It is very common to have to decide whether the effort required to implement a feature is justified by its value to the user experience. A problem like this emerged early on when Dipti was learning how to implement applications using the Microsoft Foundation Classes. The design of the PC Main screen called for a separate "Self pane" at the bottom where the user's own entry would appear, as shown in Figure 9.1.

Figure 9.1.The initial design of the Windows Hubbub Client included a separate Self pane for the user's own entry so that it would stand out and would not scroll off the screen. However, this proved to be a bear to implement and we agreed that the value of the feature wasn't worth the effort, especially since the Palm didn't have a Self entry area.

The goal of the design was to let users see how they appeared to others at all times. The reason for this is that people are less likely to feel that their privacy is violated if they can see and therefore control the information others can act upon. The important thing was to make sure users could see their own entry, and the split pane had the nice attribute of making sure it never scrolled out of view. After a little while, Dipti showed Ellen an interim version of the client with the Self pane partially implemented.

Ellen: I noticed that the Self pane has a few problems. Do you know why it's gray instead of white? Also, I noticed that you can resize the pane, but it should stay a fixed size.
Dipti: Well, I tried to make it so that you can't edit the name, but that made the pane gray. It could be just my ignorance, but I'm also having trouble figuring out how to make one half of a split pane a fixed size, and prevent it from growing when you resize the window.
Ellen: How long have you been struggling with this?
Dipti: Um, a few days? [Meekly] Okay, a week.
Ellen: Oh, geez. This isn't worth that much time! You know, we've already decided to put the Self entry at the top of the list on the Palm (since it doesn't support the concept of panes at all), so we could just do that on the PC. Would that make all the problems go away?
Dipti: Yes! Yes!
Ellen: Okay, let's do that. It'll mean that your own name can scroll off the top, but the most important thing is that the information is available, and usually people keep the list scrolled to the top anyway. Keeping the name in view sure isn't worth all the effort this turned out to be.
Dipti: That's great. Now I can go battle Windows over some other feature!

Here was a case where the effort was not worth the value of the design. Probably this design could have been implemented more quickly if Dipti had been further along her learning curve, but the engineer's level of experience is just another variable. We didn't know up front that this design would prove to be problematic, but once we found that it was, we modified the UI to avoid the engineering issue.

Effort versus value is a common tradeoff. It's often difficult to anticipate the problems you'll encounter, so it helps for the designer and engineer to stay in close touch so you can jointly decide to adjust the UI if the initial approach turns out to involve more effort than it's worth. Some engineers will take it as a challenge to make the software bend to their will, but it's more important to spend your energy on the work that is most likely to help users.

Collaboration Guideline

If the effort required to implement a feature outweighs the value it provides the user, redesign it so that it's easier to implement or don't offer it.

Example: Implementation Time Versus Usability Value
Related to implementation effort is implementation time. Often, implementation time comes into play when the engineer starts to plan the details of a feature's implementation, especially when you're deciding among alternative approaches. You want the value of a feature to be worth the time it takes to implement, because time spent on one feature is time not spent on another.

This example came up after we'd finished the Core features and were starting on the Important features. The UI Spec indicated that a user could turn off the sounds of individual bubs, and that those settings would be remembered across all of that user's clients.

Alan: How important is it that setting the mute state on one client sets the mute state on all of that user's clients?
Ellen: It's somewhat important. Someone might install Hubbub on their work machine and spend time deciding which bubs to turn on and off. Then when they install a client at home, they'd be pretty frustrated if they had to do it all over again. [Remember What They Told You] Why do you ask?
Alan: Well, it's pretty easy to save mute states per client, but it'll take a lot more time to save them across all clients.
Ellen: Any sense of how long it'll take for each?
Alan: To do it locally will take just a couple of hours, and we just have to modify both the PC and Palm clients. If we have to do it across all clients, it'll take at least a few days if not a week. It involves adding a new message to the protocol, adding message re-sending to the server so it can be sure the state change is reliably delivered to all clients, and updating both clients to deal with the changes.
Ellen: Hmm. That's a lot of extra time. I'm not even sure how many people will run Hubbub in multiple places.
Alan: Are you sure we need to do this? I could even imagine that someone might want different settings for different clients, say on their Palm versus their PC.
Ellen: That's possible. I suppose we could do the per-client version now, and then we'll see if we need to save it across clients once we give it to people.
Alan: Good plan. (Excellent! I'll have to remember that "change to the protocol" excuse...)
Ellen: [in project manager role]: What's the cost of doing the per-client version now and then changing it later versus just doing the cross-client version now?
Alan: Not much. We're going to want the clients to save the state locally for startup anyway, so we wouldn't be doing throwaway work.
Ellen: Okay, good. But don't think I'm going to forget to check whether we need to save across clients...

As it turned out, during the usage study we found that it wasn't necessary to save per-bub mute status across clients. Although some people were surprised at first that their settings weren't preserved on another client, as Alan guessed, they soon found it handy to set them differently on different machines. For example, one usage study participant on the East Coast worked with colleagues on the West Coast, three hours behind her. On her work machine, she turned on the sounds of most of her colleagues. At home, she turned off the sounds of many of her East Coast colleagues, figuring she didn't need to stay in touch with them after work. But she did listen to the sounds of her West Coast colleagues because it helped her stay in touch with them while they were still at work. This is just the type of scenario that's hard to predict in advance.

In this case, we saved time by implementing the simple version of a feature, figuring we would build the more complex version if it became clear that it was worth the effort. We were fortunate that the code to do the simple version would still be needed for the complex version. It would have been a harder decision if the complex version would entirely replace the simple one, but it still might have been worth it.

Collaboration Guideline

Time spent on one feature is time not spent on another. Spend your time on the features that you're confident will add the most value for users.

This is also a wonderful example of the value of studying the system in use before releasing a product. Knowing we'd be getting real user data during the usage study made it easier for the team to reach agreement, and in the end, it saved us the implementation effort of doing the complex version of this feature. There were other cases when it turned out that we did have to handle the more complex case, but at least we knew that the time and effort were well spent. Still, it's surprising how often the simple version of a feature is sufficient.

Collaboration Guideline

If you're not sure of the value of a feature, build a simple version of it and find out from usage testing whether a more complex version is needed.

Collaboration Guideline

People like to work on things they believe will be used. Once you have real usage data indicating that a feature is needed, it's much easier to reach agreement that the effort is justified.

Example: Expediency Versus Ideal User Experience
In all the cases where we made changes to the UI based on engineering concerns, the changes were relatively minor. There was only one case where we agreed to make a major change to the UI for technical reasons. This involved moving the account administration and permissions components to the Web rather than implementing them on each client.

Alan: Why don't we just do the administration stuff on the Web? Otherwise, we'll have to do it separately on both clients. Everybody uses the Web for this stuff now. [Follow Conventions]
Ellen: Well, if we do it on the Web, Palm users can't do things like add or remove bubs or set permissions while they're away from their PCs. Also, I think it's rude for an application to change the page of your browser when you choose a menu item. What if you were looking at something important? [Don't Impose]
Alan: You can hit the Back button.
Ellen: If you realize that's what just happened. And besides, you might be on a page that was generated, and sometimes you can't go back and restore your context. Remember that time you were filling out a form, you had gotten all that data together, and then when you had to refresh the page it didn't restore the data? How would you have liked it if that page had been changed under you by another application? (Got him there!)
Alan: How about if we pop up a new browser?
Ellen: No, that doesn't work either. Many people display their browsers in full-screen mode, so a new browser just looks like another page, and even worse, the Back button is disabled since this is the first page in that window. So then they're even more confused. [Be Predictable | Don't Mislead]
Alan: How the heck are they using Hubbub if they're using their browser in full-screen mode? (Ha!)
Ellen: You've heard of multitasking, right? [in project manager role] Never mind, we won't be getting to this feature for some time. We don't have to resolve it right now. Let's keep going and see where we are when it's time to implement the administration features.
Alan: I can live with that.