All database and app design starts with knowing what they are about. What is the purpose of the database? Who are the users? What features do they need? Which data do they want to collect? How do they go about collecting that? What kind of interfaces are they used to? In research, these questions questions are the same, but the answers are quite specifically shaped by, well, the research and the context in which it is performed.
Three particular techniques are used to get the answers to these questions : document studies, interviews, and more interviews. ( See for example Hernandez, M.J. (1997) ‘Database design for mere mortals : a hands-on guide to relational database design’ ) I mentioned interviews twice here because they are extremely important. However, there is a third technique called participatory observation which I practiced by accident.
In this post, I will introduce the three techniques, and point out why with me you are in good hands: in short, I have been a researcher with 15 years of practice in these techniques. Secondly, I have been studying scientists – which is a field of social science. Thirdly, I have been building my own database applications to support my own research.
Document studies
There is no method book that definitively describes document studies. Partly, it is a matter of content. Finding out about that is a matter of critical reading. What does it try say or do? Is it informing, convincing, asking the reader? How is it structured and how is it achieving what it tries to say or do? What is the style of writing and how does it related to the other questions? And perhaps the most important question to keep in mind about content : what is not in there ( that one would expect to find ), and why is it not there?
Partly, it is a matter of context. When was the document written? By whom? Who published it? Who ordered it to be written and why? Can the document be trusted to be original? How did it arrive in the hands of the reader? And so on. The answers to these questions provide a sense of trust and relative value of the document to the reader.
In research, for the purpose of developing an app or database examples of such documents are research plans, and textbook introductions, method books, annual reports of the institute, the research application that finances the development of the database, journal papers or research reports of earlier, similar research. Older data files or data collections are incredibly telling about how a particular research is being done and how the database should be designed. Not just the files that are prepared for publishing, but also the ones or the versions that were used during the research. And perhaps most important of all: field notes, log books and other kind of ‘private’ texts of the researchers. Handing over such documents may cause some anxiety on the part of the researcher. But not to worry, I will treat them with care, respect and respect for your academic integrity.
Document studies are usually done before the interviews. This way the investigator learns ‘the lay of the land’ as much as they can. So that the interviewee’s valuable time is not wasted on what is already written down.
Interviews
Interviews add further insight to the document study. Documents may not tell the whole story. For starters, they may not cover the totality of doing the research for as far relevant for the database design. They may not completely explain all the details that can be essential for the database design. They may not even provide the outlines and backdrop of the research because their authors took these for granted. Another disadvantage of documents is that they may be prescriptive or descriptive, but do not necessarily reflect the reality of doing research. Researchers may do things differently, or somewhat differently for their own reasons. This is not about research fraud, but about honest research practicalities. Researchers may deviate from what is written down without violating the validity of their study, but with big relevance for the design of the database or application. If the database does not support them or does not allow them to make deviations, they may simply not use it.
What holds for document study, holds for interviews as well. They are a bit of a dark art. There are different kinds of interviews. For example the survey interviews which have a strict and fixed protocol of straight forward questions, possibly multiple choice questions, that will require nothing else than an answer. They are difficult to design but relatively easy to perform.
The type of interviews that is at stake here, for the design of a research database application, are on the other end of the spectrum : so called semi-structured in-depth interviews. They have a protocol of open ended questions, asking ‘what?’, ‘why?’, ‘how?’, or ‘please elaborate on so and so?’ They are semi-structured because they serve a clear purpose and have a protocol, i.e. there is a set of questions that the interviewer would like to address. The in-depth part sits in the what, why and how questions, but also in the possibility that the interviewer may deviate somewhat from the protocol. If something is not clear, or puzzling, they can decide to first ask about that before moving on with the interview.
A result of this is that as boring as a survey interview can be to the interviewee, as interesting could the semi-structured in-depth interview be. Whereas survey interviews are a one-way street in which the interviewer asks and the interviewee answers, semi-structured in-depth interviews can go both ways. The interviewees may very well end up with a take-away themselves: having a nice conversation, or a discussion and have an insight.
I mentioned interviews twice, in part to stress their importance, but also because they may come in two rounds. First, interviews are done to understand the demands that are placed on the design of the database. Secondly, there may be a set of interviews that aim to ask for feedback on preliminary design versions. In the case of so-called agile development, the first round may be quite short, and several iterative follow-up rounds may follow for feedback. The follow-up rounds are not just about feedback, but in part have the same function as the first round. It is just that most people more easily talk if they see where things are going.
My research experience
From the above, it hopefully becomes clear that I know what I am talking about when it comes to document studies and interviews. I have been a social researcher and historian for about 15 years and worked on maybe a dozen bigger or smaller research projects. All these projects were about document study and interviews. I have seen tonnes of documents of a wide variety : archival sources, survey reports, parliamentary debates, laws and regulations, annual reports, consultancy studies, scientific articles and books, maps, meeting notes, professional journals and magazines, and much, much more. Also, I have done about 150 semi-structured in-depth interviews.
The field that I worked in, and have a PhD in, is called ‘science studies‘ or ‘science and technology studies’. Many of my projects were about interviewing scientists from all disciplinary groups ( from nano technologists to philosophers ) and all levels of seniority ( from PhD students to faculty deans ) about their work, their project applications, how they run their research groups and laboratories, about their dealings with research councils and policy makers and about the evaluations that impacted their careers. So, I may not know about your particular field of study, but I have a pretty good idea about the situation that you are in, and I know how to ask you the right questions.
Thirdly, I have designed my own FileMaker Pro databases to support my research. They are typically not the type of software one would by off the shelve, but they surely helped me organize and analyze my data. Besides these, I have worked for about seven years as an in-house developer on a multi-user database for a research project on Swedish innovations at Lund University. This is where I picked up a third technique: participatory observation
Third technique : participatory observation
‘Wait, wait, wait! Why are you clicking this button now, and not earlier?’ This could be a question that I asked a colleague whom I saw working with the database that I have been developing. They could be doing something differently from what I intended or expected, whereas I knew exactly what they should be doing. No interview and no document could give me with the type of insight that participatory observation provides.
As the name indicates, with participatory observation, the investigator participates in a particular social setting and observes what people are doing. Afterwards or during the observation the investigator may ask questions about what they observe. When it comes to software design this can be used in addition to the two rounds of interviews.
In this case, I knew exactly what the colleague should be doing, not because I interviewed them but because I learned to do the work that they were doing before developing the database. At that time, part of my job was doing the data collection. I did realize that that gave me the in-depth knowledge needed to design the database. That plus reading all the project material available, and the many meetings and discussions with my supervisor and colleagues. What I did not realize was that it could be used as an explicit first-round design method.
Rubber Boots Data 
Leave a Reply