Interviewing Users of Data

Interviewing data users is a vital step in Requirements Analysis and business rule development. Examining the existing database and reviewing paper-based records gives the designer a picture of what the organization currently stores. But it does not tell the designer what the organization needs to store, how the data is actually used day to day, or what problems people encounter with the current system. Only interviews with the people who produce and consume data can surface that information.

End users, managers, and other stakeholders hold knowledge about how data flows through the organization, what inconsistencies they have learned to work around, and what capabilities they wish the system had. This knowledge is rarely documented anywhere. It exists in the heads of the people doing the work, and the only way to capture it is to ask. Without interviews, a database designer will build a system that solves the problem as they understood it from the existing records — which is almost always an incomplete understanding.

Why Interview Users of Data

The purpose of interviewing data users during Requirements Analysis can be understood through five distinct goals, each of which contributes something that no other requirements gathering technique can provide.

1. Identify user requirements. Interviews reveal the expectations of different stakeholders. Different roles within the same organization have different data needs, and those needs do not always appear in the existing database or in management-level descriptions of the business. Insights about data access patterns, validation rules, or workflow dependencies emerge from the people doing the work rather than from those overseeing it.
2. Uncover implicit knowledge. Users often know undocumented practices, exceptions to stated business rules, and informal workarounds that the current system has forced them to adopt. This tacit knowledge, once recorded, ensures that the new database reflects how the organization actually operates rather than how it is supposed to operate on paper.
3. Detect data anomalies. Frequent users of a data system notice errors and inconsistencies that do not appear in system reports or database exports. A sales clerk who enters orders every day will know that certain customer records are duplicated because the same person sometimes orders in-store and sometimes by mail. A fulfillment staff member will know that shipping status fields are sometimes left blank because the update step is easy to forget. Interviews surface these anomalies so that the new database design can address them through structure and constraints rather than hoping users will remember to follow procedures.
4. Encourage user acceptance. Involving users in the requirements process builds a sense of ownership in the resulting system. When stakeholders see that their input has been incorporated into the database design, they are more likely to adopt the new system, follow its business rules, and report problems accurately when they arise. A database imposed on users without their participation tends to generate resistance and workarounds from the first day of operation.
5. Support change management. A new database almost always alters existing workflows. Order entry procedures change. Reporting queries look different. Data that used to be maintained in a spreadsheet now lives in a table. Early interviews reveal where these workflow changes will cause the most disruption, which allows the designer and the organization to plan training, phased rollouts, or transitional procedures before the system goes live rather than reacting to problems after implementation.

Who to Interview

The Lesson 2 discussion of Requirements Analysis established the principle of interviewing both producers and users of data. Producers are the people who create and enter data — order entry clerks, purchasing staff, marketing coordinators. Users are the people who query and act on data — managers, analysts, customer service representatives. Both groups are essential, and they will give different answers to the same questions.

For Stories on CD, Inc., the interview plan covers four distinct roles. Bob Martin handles purchasing and the distributor relationships. He is the person to interview about what information the company needs to track for each distributor — contact details, lead times, product lines carried — and about how purchasing decisions are currently made. Jane Martin manages marketing and the customer mailing list. She is the person to interview about what customer information the brochure campaigns require, how the mailing list is currently maintained, and what distinctions the company makes between active customers and prospective customers. The store manager oversees in-store sales and inventory. They are the person to interview about what product information sales staff need at point of sale and how stock levels are currently tracked. The fulfillment staff process mail-order shipments. They are the people to interview about the order fulfillment workflow — what information is needed to pack and ship an order, how shipping status is currently recorded, and what happens when a shipment is returned or delayed.

Each of these interviews will surface requirements that the others do not. No single stakeholder has a complete picture of the organization's data needs. The designer's role is to assemble the complete picture from the partial views that each interview provides.

Interview Techniques

Interviews can be conducted as individual sessions or as group meetings. Individual sessions work best when the designer needs detailed operational knowledge from a specific role. A one-on-one interview with the fulfillment staff member who processes returns every day will produce more accurate information about that workflow than a group session where a manager's description of the process dominates the conversation.

Group sessions work best when the designer needs to understand how different roles interact around a shared process. A group session with both the order entry staff and the fulfillment staff can reveal handoff points in the order workflow that neither group would have described clearly in isolation, because each group assumes the other handles the transition and neither thinks to mention it. Keep group sessions to five or six people at most. Larger groups fragment, and the most senior voice in the room tends to suppress the operational detail that the junior staff members hold.

Within each interview, a mix of open and closed questions produces the best results. Open questions — "Walk me through what happens when a customer calls to place a mail-order" — surface workflow knowledge that the interviewee would not think to volunteer in response to a checklist. Closed questions — "Does every order have a shipping status, or only mail-orders?" — confirm specific facts and resolve ambiguities identified during the open questioning phase.

Recording the interview visually is more effective than taking written notes alone. Sketching a preliminary entity list or a rough data flow diagram on a whiteboard as the interviewee speaks gives them something to react to. When the designer draws a box labeled "Customer" and connects it to a box labeled "Order," the interviewee can immediately say whether that representation matches their understanding — and if it does not, the correction will surface information that a purely verbal interview would not have drawn out.

Requirements Analysis in Practice

After analyzing existing business objects and rules through database examination, the next stage is to put those preliminary findings in front of the people who work with the data and ask whether the picture is accurate. The interviews serve three purposes at this stage: validating what the examination found, identifying what it missed, and surfacing requirements for capabilities the organization does not currently have but will need.

The three key goals of requirements interviews are: understanding how data is currently used and perceived, identifying additional informational needs that do not appear in the existing system, and anticipating future growth requirements that will affect the database design.

For Stories on CD, Inc., the interviews produce findings that the flat-file examination alone could not have revealed. The examination of Ted's system showed that distributor information was not stored in the database. The interview with Bob Martin revealed that distributor contact details are maintained by Jane on Rolodex cards — a paper-based system that Jane manages as part of her role. Without that interview, the designer would have known that distributor data was missing from the database but not where it currently lived or who owned it. The interview turns a gap observation into an actionable requirement: migrate the Rolodex data into the Distributor table during implementation.

The interview with Jane Martin revealed a requirement that appears nowhere in the existing system. Jane prepares CD descriptions in a word processor for inclusion in the seasonal marketing brochures. Those descriptions are not stored in Ted's database — they live in document files on Jane's computer. The interview established that adding a description field to the Products table would allow the descriptions to be maintained in the database and pulled directly into brochure production, eliminating the manual copying step that currently consumes significant time at each mailing cycle. This requirement would never have been discovered without asking Jane directly what she does with product information.

The interview also surfaces a future requirement. If the Martins anticipate expanding to international mail-order at some point — a possibility they raise during the interview — the designer must avoid implementing address fields with constraints that assume a U.S. format. A state field defined as a two-character U.S. state code and a ZIP field defined as a five-digit number will need to be restructured the moment the first international order arrives. Documenting this possibility during Requirements Analysis means the schema can accommodate international addresses from the start, even if the feature is not activated immediately.

What a Good Interview Uncovers

A well-conducted interview uncovers four categories of information that other requirements gathering techniques routinely miss.

The first is hidden data sources. For Stories on CD, Inc., Jane's Rolodex cards are the canonical example. Data that the organization needs but that has never been captured in any automated system will not appear in a database examination. It appears in conversation with the people who maintain it manually.

The second is undocumented processes. The fulfillment staff at Stories on CD, Inc. have developed informal procedures for handling mail-orders that arrive during the holiday peak — holding back certain back-ordered items, splitting shipments, applying manual discounts for delayed orders. None of these procedures are documented anywhere. They represent business rules that the organization enforces informally, and they need to be captured during Requirements Analysis so that the database design can support them explicitly.

The third is future requirements. Organizations change. A business that currently sells only in the U.S. may expand internationally. A company that currently tracks only physical product inventory may add digital download products. Interviews that ask stakeholders about their plans and their growth expectations give the designer the information needed to build a schema that will accommodate those changes rather than one that will need to be restructured when they occur.

The fourth is conflicting stakeholder needs. Different roles within the same organization sometimes have genuinely incompatible requirements. The marketing function may want to retain customer records indefinitely for historical analysis. The legal function may require that customer data be purged after a specified retention period. These conflicts cannot be resolved in the database design without first being surfaced through interviews with both parties. A designer who interviews only one stakeholder group will build a system that serves that group's requirements while inadvertently violating the other group's constraints.

From Data to Information to Knowledge

Understanding why interviews are valuable in database design requires understanding what a database is ultimately for. A database stores data — raw facts. But what organizations need is not data alone; they need information derived from data, and ultimately knowledge derived from information.

For Stories on CD, Inc., raw data is a table of customer records: Customer ID, name, address, customer type, and order history. That data on its own answers the question "who are our customers?" Information is what emerges when the data is queried and organized: "customers in the 7-to-10 age group segment purchased 340 CDs in the October mailing cycle, compared to 210 in the previous cycle." That information answers the question "how are our customers behaving?" Knowledge is the insight that the organization draws from the information: "the October mailing to the 7-to-10 segment outperformed the previous cycle because it featured three new releases in that age group — we should prioritize new releases for that segment in future mailings." That knowledge answers the question "what should we do?"

Interviews with data users are the mechanism by which a designer discovers what information and knowledge the organization needs from its database — not just what data it needs to store. Bob Martin does not tell the designer "I need a distributor table with a phone number column." He tells the designer "when I need to reorder a title that's going out of stock, I need to be able to look up which distributor carries it and call them immediately." That statement describes a knowledge requirement — the ability to make a fast, informed purchasing decision — which the designer then traces back to an information requirement (a query that shows stock levels and distributor contacts for each product) and ultimately to a data requirement (the Distributor and Product tables with appropriate linking).

The next lesson covers data flow diagrams — a technique for mapping how data moves through the organization that complements the interview-based approach to requirements gathering.

Data Flow - Exercise