Together with “drafting a design” this phase is the one where the software designer will be most intensively involved with his teammates, most notably the client/end user and the software developer. This involvement represents itself iteratively in both phases. The reason “discussing the design” has it’s own phase is because it just has to happen and have it’s place in a project plan. The beginning of a project is where the strategic course is planned.
One of the greatest reasons software projects fail time and time again is because people are not involved or have the feeling they weren’t. So we as software designers, have to yank these people to the drawing board and ask “tell me what you want, I need to know, is this what you want?” or “this is what we came up with, so and so it is a problem for the problem you are currently facing, what do you think? What have we overlooked?” Let me give you a recipe for the number of meetings I usually need to come up with, and discuss a design. Let’s say a client has some challenge and knock’s on my door. From the moment of the first knock to a the moment he agrees with a scope usually the following happens, no exaggeration:
Meeting #1
We discuss something I call “initial needs”. They are not requirements or anything resembling them, but give me and my senior software developer a clear enough view of what will be necessary to cover these needs with an appropriate technical solution. I usually get a “requirement document” or “design”, a written document containing a couple of pages with text about the problem area and related business rules. This document could be discussed in a separate meeting if required.
Meeting #2
After we, the senior developer and myself, heard the client ask: “So what do propose you could do?” we took over and came up with a crystal clear concept design and proposed a good technical solution because of our combined knowledge about what would be necessary to make a good quality software product. During a second meeting we discuss our proposed solution with the client who gives me ten to twenty percent extra functionality to translate into “real” requirements. The client feels he deals with professionals and hurries back to his boss because he wants a go on the financial proposal so we can get busy. That is I’ve reassured him that his extra wishes fill find their way in a revised design but requires no further meeting.
“Don’t you need more time to clarify certain things? I mean, my clients usually are extremely ambiguous in the way they speak about what they want.”
Good question. My clients are exactly the same, like children in a candy shop, wanting to have everything they can put their hands on. I’ve got a question for you before I answer the above one:
“What do you do with children when they come up to you, hands filled with candy?”
Answer: you give them an apple stating it’s healthy.
I thought I was the professional when it came to software designing, not the one paying me, or else he wouldn’t have hired me. Now I don’t want you to actually start bleating that in your clients face, just feel it. If you feel it, you act the part. Seeing yourself as the professional designer means you make a professional design, something your clients will be happy with. Now I can’t do that all by myself, I need a senior developer who knows his business when it comes to make the sensible technical choices and discussing those with me. But in the end, honestly, I don’t need somebody telling me what a good design needs to look like, that’s my area of expertise.
What is clarification anyway? If you want a portrait of yourself you don’t discuss with the painter for hours on end what the portraits supposed to be, do you? Well, with software designing we do and that’s okay because it’s a risky business with high stakes involved. But ask any software developer who has a couple of years dealing with clients under his belt and you’ll hear the same argument over and over again, which is that clients should stay on their side of the line, not interfering with the software developers business. So it is with software designing, clients can pick the colors so to speak, but let professional designers deal with the rest.
Scope Creep
One more very important is that the product in this phase should be a version 1.0 of your design. v1.0 means that you have a an agreed upon scope and there will be no more adding functional issues. As a designer, you have a responsibility to guard this. If you don’t take this responsibility it’s your ass, because you’ll keep adjusting the design till kingdom come. Remember the ten percent timeline for a concept design, you’ll won’t make it. So guard it, and if you can’t handle that, don’t just sit and whine about it, learn fast enough do something about it, find somebody who can it or do both. I’ll turn meetings into battlefields if I’m forced to and think it’s necessary for the good of the client.
“If you like your children to stop wining now and again, keep feeding them candy to shut them up, but that’s dealing with the pain short term. You’ll end up being responsible for them being diabetic in their teens.”
If that’s okay with you, start over beginning with page one because you must have landed directly on this page. When dealing with clients, chances are your not each other friends so stop treating each other like you are more concerned about maintaining the status quo than the truth. Trust me, you will be rewarded when maintaining your congruity. If you say “no” nine times but “yes” the tenth time, children are very quick to learn and start nagging you until you give in, because they know you will. So they not only end fat and diabetic, you’ll end depressed because these fat monsters will be out of control draining you of every ounce of energy you’ve got. I agree, that’s not what I call a compelling future. Standing your ground when you know what’s right is.
Related posts: