Designing from Both Sides of the Screen, by Ellen Isaacs and Alan Walendowski, is written by an “interaction designer” and a “software engineer,” and is appropriately subtitled “How Designers and Engineers Can Collaborate to Build Cooperative Technology”. This book may be particularly useful for planning software projects that have the luxury of one or more designers and engineers, but I think that it could be helpful even when the same people must serve in both roles.
Many books about the process of software development seem to focus on corporate development for a particular customer with whom the developers have direct access, so I was pleased to see that this book focuses on development from the perspective of writing software for unknown customers out in the real world.
The book is divided into two parts. The first part gives general guidelines for designing software that acts more like a kind butler than an evil robot. The second part (about two-thirds of the book) details a process for designing and implementing a software application. An appendix gives a nice summary of all of the guidelines mentioned throughout the book.
There are three main tenets of “being a butler.”
Respect physical effort by minimizing the number of “clicks” required of users to accomplish common tasks, smoothing out the user’s “flow”, and remembering the explicit and implicit information that the user provides.
Respect mental effort by removing complexity, making common tasks prominent, hiding infrequent tasks, and minimizing the need for “preferences”.
Be helpful by focusing on what works best for the user rather than what is easiest for the engineer.
Their software development process consists of five steps.
Understand the users’ needs by observing how they currently do the activity you want to support and by examining existing products that do similar things. Create a “task list” of the things that users will be able to do with your product, and then create the list of “functional requirements,” which describe what the product will do to support that task list. Finally, ruthlessly prioritize each functional requirement as “Core” (enough to start rudimentary testing), “Important” (required to ship), and “Nice to Have” (not required to ship).
Design the user interface without being overly concerned about what is “technically” possible. Use the prioritized functional requirements to similarly prioritize the task list, and then further organize the task list into four groups that indicate how often the task will be done and how many users will do the task – “Frequent by Many,” “Frequent by Few,” “Occasional by Many,” and “Occasional by Few.” Using this information, organize the functional requirements by “screen,” such that frequently used tasks require fewer “clicks” and popular tasks are more prominent. Make a “task flow diagram” to show the relationship among the various screens. Design the layout of each screen and create a mockup of each of them, making sure that each task is supported appropriately. Create a User Interface Specification that uses text and images to explain how each of the tasks is accomplished.
Design the architecture to support the user interface design, making modifications when necessary to address system constraints, simplicity, ease of maintenance, etc. Once it is clear how the product will work, create a detailed “feature list” from the prioritized functional requirements. Estimate the development time for each feature, and then triple the total time to determine the completion date. (Really!)
Initial development involves (finally!) writing code to implement the “core” features. Resolve issues through discussion between the designers and the engineers. Once the product is to the point where it can be reasonably tested for usability issues, initial development is complete.
Iterative development is the cycle of implementing “important” features, fixing bugs, doing usability testing (by using the product directly and by doing usage studies with potential users), and adjusting the specifications as necessary, until the product is good enough to ship.
This was an easy book to read with plenty of good advice. I hope to return to it when I find myself early in the design phase of my next software project. I may even try to follow their development process, though it’s a bit more elaborate than anything I’ve done in the past. I don’t think that a small software development team needs a complex, formal process for development, but the process in this book might be straightforward enough to help the team stay focused throughout the development of the product.