Stakeholder analysis can be pretty straightforward. If you’re in-terviewing members of the organization as users of the system, refer to the ethnographic methods in Chapter 5.
Create a clear statement of what you need to accomplish for the project to be considered a success by the organization. These are the business requirements. Design and development are how you satisfy the business requirements. It’s best if everyone who cares about the project agrees.
The goal of gathering and documenting business require-ments is to ensure that all the stakeholders agree on the purpose and limitations of what you’re doing. You want to increase your chance of success, connect what you’re doing to the goals of the business, increase collaboration, and save costs, particularly those associated with changes. Note that business strategy must remain constant for the duration of a project.
Requirements must be:
• Cohesive. The requirements all refer to the same thing.
• Complete. No missing information. No secret requirements that didn’t make it onto the list.
• Consistent. The requirements don’t contradict each other.
• Current. Nothing obsolete.
• Unambiguous. No jargon. No acronyms. No opinions.
• Feasible. Within the realm of possibility on this project.
• Concise. Keeping them short and clear will increase the chances that they are read, understood, remembered, and used. Aim for no more than two to three pages.
The document should not contain specific solutions or design requirements. The type of organization determines the level of detail required in the business requirements documentation.
Depending on the political situation at the company for whom you’re conducting the research, you may have one version for the core team and a more summarized (or polite) report for broader distribution.
What to include in your documentation
Problem statement and assumptions
What needs to be solved or improved from a business perspective?
Goals
Every project begins with a rough set of goals, or concepts of success. Every individual in an organization sees them a little bit differently. Gathering these and reconciling them is essential to a functioning project.
Success metrics
What are the qualitative and quantitative measurements that tell you whether the project is hitting the mark? These should support the goals.
Metrics can include things like “boosts reputation of Fantastic Science Center among peers,” or “increases online sales in the store thirty percent by the six-month point.”
Completion criteria
How will you know you’re done? It may seem obvious, but it’s always good to validate. Otherwise, the project will never be finished!
Scope
Scope refers to the amount of work included in any project.
“Scope creep” is what happens when more work just keeps getting tacked on and the scope grows uncontrollably. The best way to avoid scope creep is to document what is included in as much detail as possible and in language everyone understands.
(Historically, designers and engineers have sparred mightily over the definition of a “template.”) And note who is responsible for what. Scope is a boundary, so it’s also very useful to note that which any of the stakeholders might assume to be included but
oRganIzatIonal REsEaRch 73 is out of scope. Not touching the logo this time around? Note that! Not changing the registration process? Write it down.
Detailed scope documentation makes for happy teams and func-tional projects.
Risks, concerns, and contingency plans
Want to increase your chances of project success? Then ac-knowledge anything you’ve uncovered that might lead to failure or unmet expectations.
A designer conducting research might pick up on a lot of information that matters to the project process as well as to the design approach. Some organizations are more functional and well resourced than others. Every organization has its chal-lenges. If the team understands and acknowledges these, they will be able to work around them more effectively. Maybe key decision-makers will have limited availability. Or perhaps two departments who need to collaborate very closely have histori-cally had a poor working relationship.
All of this information gathering will allow you to anticipate potential problems before they arise. This is an area in which the practitioners (designers, writers, developers, etc.) and project managers should collaborate very closely. If these challenges are not openly acknowledged, which is sometimes the case, be very sensitive in how you talk about them. For your work to succeed, you have to address them.
For example, you might find that the Fantastic Science Center media relations department is unavailable through the end of the year because of a big event, but you’re required to get ap-proval from the head of media relations on several aspects of the design. This is a terrific thing to know about in advance so you can plan around it.
Getting everything done on a tight schedule is often a major shared concern. A clear, simple—and, most importantly—pub-licly documented process for gathering feedback and making decisions helps everyone stay on track. And, if you have heard different concerns from different groups, it’s best to address that head-on. The need to keep the total project cost down might be what you heard from operations, while the product team
3. Drafts campaign copy
6. Sends approved design
7. Pushes campaign live Editor
Designer
VP Marketing Writer
4. Collaborate on campaign design
Producer
1. Sends brief 2. A
ssigns brief
5. Feedb
ack & approval
Fig 4.1: a workflow diagram can describe the current situation or illustrate your recommendation based on what you’ve learned about the organization.
oRganIzatIonal REsEaRch 75 mentioned the need to have a user experience that compares favorably to a major competitor. The most appropriate solution will address both. Maybe it requires focusing on the highest-priority features to be identified through user research.
Verbatim quotes
The specific words used are highly valuable in revealing an in-dividual’s personal perspective and attitudes. If possible, share these without attaching identifying information.
Workflow diagrams
Who will need to be told about how things have changed and in what format? A workflow diagram is a good companion to this document (Fig 4.1).
If you’re working on an internal project or a new customer-facing product that’s likely to change internal workflow, diagram the current and proposed workflows. Throughout the project, you can use these diagrams to track any workflow ramifications and make sure that the organization is changing sufficiently to accommodate the new design.
Unpack the baggage
A solid understanding and honest assessment of an organization and its business is necessary for the success of any significant design project. Organizational habits and capabilities are just as relevant as target user behaviors and needs, although they’re less frequently included as fundamental topics of design research.
And the true nature of workflow and interpersonal relationships is just as ripe for ethnographic exploration.
Even just the process of conducting research can be beneficial if only because it provides the motivation to open atrophied or nonexistent communication channels. Performed with tact and rigor, organizational research can neutralize politics, clarify requirements, and improve the odds that changes will be fully understood and take hold.