Argument against UML: UML are just presentation drawing tool (Power Point Plus), even class diagram is the same category

Argument against UML: UML are just presentation drawing tool (Power Point Plus), even class diagram is in the same category


I have been feeling that way for a long time, except class diagrams or ER diagrams.

Then, there are two things:

(1) Users cannot really understand class diagrams. It is much easier to list those table names, and put columns there, and (most importantly) put some example data. In other words, simply put the output (including the heading) of the “select * form XXXtable where rownum <5”. Of course, if the table is too wide, you have to cut it a few times, so that the width of the document is printable (details, details, I know).

You may say: you can train users. Yes, however, the key part of it is that UML does not give you a way to list example data. That is fatal.

(2) The document must be readable to users. “Design only” or “Developer only” document is not that useful (I would say actually harmful!) for most projects, even large project. My stand is that, if the document is developer-only, then, I would quote legendary XP: the code is the documentation – so, we do not need the document!

As a result, from now on, to me, my stand is that even class diagram is just a nice-to-have beautiful drawing tool. The bottom-line thing is, the code (and some reverse engineering capability to generate beautiful diagram from the code), and the listing of “select * form XXXtable where rownum <5” (including heading).

So, the core document is all plain text based, summary use cases, use case scenarios, and a “glossary” which contains listings of “select * form XXXtable where rownum <5” (including heading).


OK, the title is misleading or intentionally provoking ;-), UML is useful, you need to know it. The key point is, if you really know it, then, you would not need to show-off. It is just a presentation tool – note that you need presentation tool even when there is only yourself or one another person.


Also, do not get me wrong -- in the document, you can put in a lot of UML diagrams – the document should certainly be ready for “presentation”. However, the core part of the document should be “Mom, look, no diagrams!”

As a matter of fact, this applies to even mockups. I am the first one to emphasize the importance of mockups. However, mockups are, well, just mockups. As a result, in the document, we need to keep the ad hoc nature of those mockups. They should be ad hoc, ugly, and even “unprofessional” – the “unprofessional” look of those mockups means that you are indeed a very knowledgeable professional! The key thing here is to make them fast – you must be very responsive to users, and you must invite users to participate in the drawing, be transparent to them. Then, users will “forgive” the ugliness, and even appreciate the ad hoc-ness of your mockups – after all, they are theirs’ baby also!

Put it in more tangible terms: in the beginning, we need to be able to draw electronic mockups, without using IDE and screenshot. I understand that there are many drawying tools. However, to enable users to participate in the drawing, we need to be able to draw screen design using Word, and be able to do that very quickly.

My trick? Using tables, nested tables: it is simple and fast. Users can immediately “get it” and participate.

Of course, very soon, you will update the ugly tables with real screenshots -- but in random order and still with a lot of ad hoc style – ya, intentionally keep it sloppy, until the last final version – it is almost a mind game, but it is important to let users know that UI is less important than business rules – users will always pay attention to UI, and we need always to remind them that UI is just the skin, and the muscle and the bone are more important than skin, even it is the face skin! Sometimes, during the process, periodically, you can “leak” a few business rule bug to users, to get users’ attention back to business rules, and remind them that those bugs are more important than “where to put the button”! The last version should be accurate, so that it looks as a user manual. However, unless you have a technical writer, do not try to “enhance” the screenshots. For example, except for very busy screens, do not try to split the screen in the document – it does not worth it. It prevent you from updating it continuously and therefore hurts the product or the accuracy of the very document!.

The key thing is, UI is NOT the focus – mockups are not VB6’s UI driven approach! Ya, I know, I just cannot help mentioning VB6ers recently. Think about it, all those arguments again visual pictures are to correct VB6-ers’ terrible instinct to be attracted by visual things. To such an extent, I even have to say that the “visually” in “design visually” is not that important than the fact that you must do “design” – do not let the “visually” hurt the “design” – right, that is the exact point I have been trying to make in this blog -- UML and mockups, they are visual, so, VB6-ers will twist them into something that can hurt the essence of design, I see through it now! I guess very soon I will be an expert of mentoring a VB6 team to “get it”.