Tuesday, March 11, 2008

Cooper Response - Part V

by: Binding Designs, LLC

Part V of The Inmates Are Running the Asylum, “Getting Back in to the Driver’s Seat”, consisted of three chapters: “Desperately Seeking Usability,” “A Managed Process,” and “Power and Pleasure.”

In Chapter 12, Cooper brings up an interesting point of how the programmers have more power than the designers. He is saying that the common seat-at-the-table solution does not address putting design in front of programming. It makes sense to have a sketched-out design that the developers of a system should follow. The designers, however, don’t always realize the restrictions of programming. If there were no timelines that programmers had to follow, then any design could be made. Usually programmers make software a certain way because it is the easiest way. This could obviously affect the usability of a system. Besides just not making a system more user-friendly to take the easy way out, sometimes it is the only way to get a goal accomplished. For example, developing software for a BlackBerry, a designer could make a perfect application on paper. But, the tools allowed would not possibly allow to be done what is specified to be done in the design. Software will not have the most effective user interface because of the limitations. Designers usually do not have the limitations that programmers do. Back to the BlackBerry example, a designer could, to improve the user-friendliness, say: “just put the menu up there at the top.” A programmer has the BlackBerry development kit and should say: “there is no code in there to: ‘just put the menu up there at the top.’” It would be a huge programming project (task) to complete a simple design (goal). A multi-disciplinary team would eventually make a system come out better. A lot more new struggles would arise from integrating other disciplines into the team. If all members were properly aware of all the aspects, then it would make it easier for everyone. A programmer might not understand that the designer does not understand what the programmer is doing or vice-versa. If a carpenter wants to design a system and then have the programmers implement it, then the carpenters might not know exactly what the software/hardware can do.

In Chapter 13, “A Managed Process,” again, discusses about the ‘designers vs. programmers’ on the issues of usable systems. Also, he brings others into the equation such as sales, management, and marketing. Cooper starts going off about the interaction designers getting more into the work or to “put themselves in harm’s way.” Typical designers usually are way out of the system and only draw up plans that might not work. Interaction designers would be closer to the code and know what is actually going on behind the scenes. Cooper states for the interaction designers to document the design to get it built. It should be documented in very great detail and examples set up to demonstrate exactly how the system would behave. It should be described “in detail to give the developers confidence that the solution is robust enough to survive implementation.” He emphasizes how design is like a written battle-plan. Another point brought up is that designers come in after the underlying functionality is built. A better way to approach is to have the designers put the design on paper before implementation. The designers should be at a lower level designing the code and implementation, not just the very high level layer of graphical designs and user interface. Basically, it seems as though there should be the high-level designers, low-level designers, and the implementationalists. Cooper states that the designers specify the inside of the system from the outside of the system. This can’t always hold because in some situations the designers outside of the system need to know how the inside of the system works or they are going to be designing who knows what. Any pattern of pixels can be displayed on a monitor; the designers could specify exactly how the pictures (including letters) should display and behave. Figuring that the designers knew that much, than maybe the designers would not need to know how the system works from the inside. They should just know that it does work.

No comments: