I just met up with a very business-like client who’s the total non-technology savvy person, and I must say it has been a very fruitful experience to understand the thinking of how non-techno people think.
Basically just drawing back on my previous blog, the idea of a User-Role-Centric Solution and Approach to the problem. Apparently it came to very good use as I subtlely veered her into that thinking, or maybe she already is thinking using that approach. Anyway, that’s really besides the point. But that approach actually made her able to come up with fantastic ideas for what she actually wants in her business or logic-wise. Note that we were actually talking quite non-technical here and more of what she wants to do, or what service she wants to provide the user. By thinking along that terms, she could come up with quite alot of business processes that she wants implemented, like her Invoice process, her Customer process, and so on.
From my point of view, this is actually quite a good way to draw out what your client actually wants for the solution, and how she wants it done. In my case, I would have never thought about enabling the invoice to be output into an excel file then making it available for printing, nor would I have known about how she wants herself to view the payment reports, nor would I have thought about how she wants to keep her customers by adding some added-value/services to her business, and so on. And she also has a better understanding and quite a clear understanding of how the solution works by us listing down the functionalities of what each type of person can do, without alot of the techy details. The most techy thing would be to describe the process of how the system works. As in, the user enters something, and the information is submitted into the system, and thus the system will inform the admin staff and send back a confirmation email to the user. Something along that lines. Very basic techy stuff. Nothing on like how it actually works.
Of course, the document must have these things available, in a bit more details, but that’s for another section. I actually have a Project Guidelines document which I’ll put up some time this week for you guys to look at. It’s quite interesting. But some things I might want to emphasize. Know your clients, and write your document accordingly. Safest way to do it, think in a business sense.
Till next time,