I recently finished reading The Inmates Are Running an Asylum book by Alan Cooper, which dives deeply into the question of how software design should be performed. There are great many interesting ideas and a lot of thoughts that anyone working in a software company may want to consider. Even though I can't agree with the views of the book to the point, I liked it and will try to cover both the thoughts that fascinated me and those that seemed questionable.
At the core of the book lies a simple idea that when we are going to manufacture something - possibly that's a piece of software - we should design it upfront and do that properly. Design at its core means establishing the overall structure of the product mainly from the point of interactions with users - down to UI design, but well beyond it. The term 'properly' is an equally sophisticated thing and expands to many different recommendations, warnings and tools. Some that stand out are: finish working on the design before you start coding; detach designers from coders; use certain techniques to channel design and limit the scope effectively.
The idea that we should put some effort into design before development can hardly surprise anyone. Even those who preach that a programmer should just hack the code till the product is born would likely agree that certain amount of careful and structured thinking has to precede creation of the first lines of code. The explicitly stated suggestion that coders should not do design and even that the designers should better be somewhat isolated from those who program is more controversial. Still, it makes a lot of sense, because programmers (and I speak of myself in particular) tend to focus on implementation details and reduce the domain to the level of their apparent technical capabilities. This strongly affects the point of view and ability to see what we are going to build, for whom and why - we mostly pay attention to how it is going to be built. At the same time, software should be designed not just to be buildable, but to deliver value in an easy to use manner. Our ability to provide value to the users is usually limited by poor understanding of their needs - that's something that most of the programmers faced at least once during their career. With usability we fail in a more subtle way - we make the thing easy to use, but only for the folks that look like ourselves, because that's what our experience and customs drive us to. In most cases, however, the users are people with a very different background, so we unwillingly make sure that they have hard time with our product. While these claims may raise some disagreement, they look valid, even though are not always the best to follow from the practical point of view.
At the same time, I couldn't agree with denouncing of the act of prototyping. The reasoning for claiming it bad is that prototypes tend to stick and in many cases to become the first version and the core of the final product, being least suitable for that due to their nature. That happens because programmers don't like to throw their creations away and managers, avoiding what looks like wasted effort, like it even less. While it definitely can be very hard to get rid of the code that is already written, I still don't think that the technique of prototyping a part of the solution should be disposed of. We should simply use it with care and be ready to dump weeks of our work into a waste bin because the goal of a prototype is not to serve as an actual basement for the final version, but to provide grounds for decision making that brings us to the finished product.
What makes the book very practical and valuable is the design tool that Alan offers - personas. The idea boils down to making up a narrow set of characters that depict future users of the product and allowing these fictional dudes to wholly drive the design process. Interestingly, the book suggests that the design team should give each persona a name and photo, assign user roles and thoroughly describe their background. Such characters would allow to speak of the product in terms of the needs of concrete, although unreal, people who are expected to use it. I must admit that I have never tried this approach, but it seems very powerful to me, because it gives a framework to ask proper questions about the thing in the making and to ensure that design stays on the right track, as we develop the product exclusively for our personas. This means that if there is no persona that needs a particularly fancy button, the button will never make it into the final design. The book goes even further with this suggesting that in most cases it is not right to subside to the customer's attempts to squeeze another feature from the development team unless our personas justify it. This idea rests on the assumption that a good design based on the right set of characters would cover the needs of the user, while anything that is injected into the product in spite of the design will give birth only to inconsistencies that will eventually ruin the software. Sure, rejecting client's request is a tough thing to do, but there is something to the idea of declaring clearly what your user looks like and staying by that declaration - it could certainly make some of our creations more consistent.
While I liked most of the core ideas in the book, it still raises concerns in regards to its practical applicability. The problem with the entire design framework presented by Alan Cooper is that it requires great upfront costs with the possibility of getting nothing but experience as an outcome. The biggest share of these costs comes in the form of the time spent without delivering any kind of a marketable product. In the modern world, when everyone strives to squeeze time to market as much as possible, it is difficult to take a path that promises to double it (in the best case). It also seems nearly impossible to incorporate this design and development methodology into an existing process - it can work great from the beginning, but when there are established constraints of an existing product, anyone trying to inject a serious design into a working motor will likely fail.
Overall, I definitely recommend this great practical book to anyone working in the software industry, as it gave me a new perspective into the development process and explained some very useful tools like personas. It also conveys greatly the idea that usability is born - or buried - deep under the hood of any software and can't be just added on top of a finished product, which is something that you want to keep in mind. Finally, a ton of examples - both related to software and beyond the industry - show that many things that we use nowadays are designed poorly and are still hard to use, which means there are lots of opportunities for making the world a better place.
