Do you need a use case or a target audience?

Do you need a use case or a target audience?

A use case means considering how your product will be used by a hypothetical individual who represents a part of your user base - for example, a tech-savvy 35-year-old project manager who is eager to do all her administrative reports in a shared web-based environment instead of working in Microsoft Word and sending the reports as email attachments (note that the use case may be more or less specific). If you're building a product to serve this person, you've got some specifics to work with regarding probable expectations, the amount of guidance and hand-holding needed, and so on. By developing additional use cases describing other probable users (and these are developed by talking with the client - you may even have access to the users themselves) you will have done the groundwork for making a design that suits the users. A target audience is more of a passive recipient, not a true user. "Anyone working in acquisitions" for example. Without a real understanding of the users, the product will be generic and bland. You'll be doing the least you can - putting the product out there in another gray blob among thousands of gray blobs that meet the requirements but are ultimately forgettable. Understanding the difference between a user and an audience is important - are you showing them something or are they doing something?

This distinction is not unique to the web - a hands-on constructivist learning product based on paper or in the classroom can just as easily be dulled into a passive presentation, but web- based products provide constant opportunities to make the choice whether to lecture or to engage. Can the user get in there and really use it -whatever it is - without being told at length what it is, what to do, and how to do it? Less telling the user about the product and more of the user using the product is the goal.

Collaboration - synergy or too many cooks:

Every stakeholder has an opinion. So they should. But if every stakeholder is pushing and pulling the design of a product in a different direction - even if every stakeholder has some knowledge of design, and every stakeholder won't - the result will function poorly and please no one. Like users, stakeholders will tell you what they think they want with little idea of what is actually needed. If you can make them understand that their knowledge of engineering or sales or contracts does not qualify them as art directors or graphic designers - and the good ones will know this already - then you will be able to proceed more efficiently. Beyond the subject matter experts, your colleagues - managers, artists, programmers - will likely have views that they will feel should be accepted gratefully and integrated into the design. Compromising here - to keep the peace in the office or out of friendship - will compromise the design.

Management will often announce an initiative to promote collaboration. Sometimes they'll rearrange the workspace to serve this goal, without realizing the effect an "open" or "collaborative" workspace can have on getting the actual work done - distractions and interruptions can become the rule rather than the exception. In that case you'll find yourself looking for ways to get the work done despite all the collaboration. Don't take this to mean that good ideas cannot come from anyone, anywhere. But you have to retain the power to pick and choose. If you're designing the product, be sure you make the decisions. Individuals decide. Groups decide to meet again.

Honesty

The importance of honesty in design:

Beyond the obvious concerns of conflict of interest or complying with nondisclosure agreements, you have to be honest about your capabilities and your expectations - first with yourself, and then with clients and colleagues. The consequences of deceiving yourself or your partners in the effort, whatever that effort may be, can be quite serious. The professional, financial, legal, and personal costs are worth taking some care to avoid. Be able to assure yourself that every decision you make was made because it was the right thing to do - it's too easy to talk yourself into spending time (yours and the user's) and the client's money on an unnecessary feature that you personally liked or wanted experience with. Did you do it because it was right for this product at this time, or did you do it just because you could?

Perception, rightly or wrongly, is also a factor under this topic. Does your work seem honest? Designs that are unnecessarily complex give the impression that the designer is trying to conceal something - incompetence, perhaps. Conversely, a clean, simple approach is reassuring to both the user and the client - as well as being more effective. They should never wonder if what they're seeing is really what they're getting. Your work and your approach to the work should be simple and straightforward.