This is a handbook of definitions and examples of information dimensions found in interview data that can be used as benchmarks in the rating process. The quotes here are examples of characteristics included in the coding scheme. This handbook should be used with the rater’s own notes compiled during the various training sessions. A methodology is provided below the summary of the dimensions.
Each dimension presented in the handbook has two sub-levels associated with it. Definitions of the dimensions as well as the sub-levels are provided. Examples of quotes that correspond to each level are then provided for reference. These examples are used as benchmarks by the rater during coding in order to categorize sentences/ segments into the appropriate category.
NOTE: A single sentence or segment of text can be categorized as belonging to more than 1 dimension in this coding scheme. Additionally, a segment may be associated with no, one or both of the sublevels.
- INTERNAL (TO ENTITY)
- EXTERNAL (TO ENTITY)
- ABSTRACT
- CONCRETE
- DOMAIN SPECIFIC
- CROSS-CUTTING
- MEANS (EFFECTUAL)
- ENDS (CAUSAL)
- SYNCHRONOUS
- ASYNCHRONOUS
Information Source refers to the origin of the information with respect to the individual or the individual’s organization that generated the idea. Partially describes idea ownership.
Information that comes from within the individual or the individual’s organization’s own cognition. Information has no to minimal inspiration from beyond the designer/organization at the time of the information gathering or idea generation.
EXAMPLE: Past experiences with products, autobiographical knowledge gained from experience or expertise (i.e., cannot be traced to a specific instance/ event where the information was obtained from another source), personal heuristics, individual preferences, intellectual property, etc.
QUOTE: "Well, with [open source OS] we've had to build it from scratch because it's brand new, so there is a lot of code in there that was originally proprietary… We do start a lot of projects where some of the code is internal, and we think that we get some advantage from making it open”
Information that comes from outside the individual or the individual’s organization’s own cognition. Information has most, if not all, inspiration from beyond the designer/organization at the time of information gathering or idea generation.
EXAMPLE: Examples of other successful products, episodic knowledge gained from a past experience (i.e., can be traced to a specific instance/ event where the information obtained came from another source), recommendations from other designers or colleagues, best practices obtained from guidelines, etc.
QUOTE: “We took the Linux kernel code and we decided that we were going to make all of these modifications to it for the [our 64-bit processor] we were working on”
Abstraction of Information refers to the level of abstraction of the information. Describes the extent to which the information deals with concrete events and details versus abstract ideas and concepts. Partially captures the level of detail found in the information (low detail signals abstraction, high detail signals concrete).
Information that is highly conceptual and deals with ideas and concepts instead of concrete details.
EXAMPLE: Information that deals with general information about a design process, etc.
QUOTE: “And some of the code is directly related to the work that [our company] does and the hardware drivers. But we also do a lot of work that helps us in a more indirect way. We have a guy who's done a whole bunch of power optimizations in the Linux kernel... whose job is completely dedicated to that and to making things faster and more efficient and a few other things really around power consumption”
Information which deals with concrete details and instantiations.
EXAMPLE: Information that deals with specific features of the product, specifications, requirements, etc.
QUOTE: “If we’re doing massive audio processing, low latency audio processing requires a couple gigaflops of CPU and we’re talking low latency in terms of 166 microseconds, it’s not going to happen in a user task, at least not with [our product]”
The Generality of Information deals with the level of generalizability of the information to other design tasks and projects. The extent to which the information is directly related to the domain of interest, as opposed to other more distant domains.
Information that is highly related to the domain of the design engagement (whatever is being designed).
EXAMPLE: When designing a video playing application (e.g. QuickTime, Windows Media Player, VLC), inspiration is sourced from other video playing applications.
QUOTE: “To provide a graphics driver for Linux, we chose to leverage the same graphics driver code base – the core code base that's used on all the other platforms. So, the core of our code for [our open driver] for kernel-level support… is common across [multiple platforms]”
Information that is relevant and applicable across many design problems.
EXAMPLE: Designing new training materials of a software that will be used by employees working in different departments.
QUOTE: “Translation is big for a lot of projects. You know, it's written in English, and people everywhere else want to use it. And so, translating is a good way to contribute to projects”
The Effectuation of Information refers to the extent to which the information deals with the resources available to the designer versus with the end goal(s) of the design. Describes whether the information is the “means” or the “ends” of the design process.
Information that deals with resources available to the designer during the design process. Available resources determine the design decisions.
EXAMPLE: Design decisions are made based on the current domain of design expertise, available prototyping facilities, financial/social/technical capital, etc.
QUOTE: “What we get is 90% of the system, so [we] do less than 10% of the work. We then leverage that investment to provide client value. If we were doing Linux on our own, we would have to do that other 90% instead of doing other things for our clients and stockholders”
Information that deals with the end goal of the design process or the needs that the product aims to fulfil. The end goal of the design shapes the design decisions.
EXAMPLE: Design decisions are made based on the customer needs of designed product, other competing products, trends in the market, etc.
QUOTE: “It had to be based on circumstances that were involved and you just needed to solve that customer’s mission. If that was the piece of code you needed, you’ll come up with the right way to do it”
The form in which the information is obtained, or the manner in which the inspiration is articulated. These levels can co-occur, for example when a website or other medium (asynchronous) is used to organize a meeting in person (synchronous).
Information that was obtained in real-time. In other words, there is an instant interaction between the sender and the receiver of the message, and that interaction can include verbal and non-verbal cues.
EXAMPLE: In-person conversations, phone calls, conferences, real-time video meetings, etc.
QUOTE: “We invite a bunch of people who are working on key components of the Linux kernel and we bring them in and we talk and tell them exactly what [our company] is doing, why, and what we'd like to see in the kernel and how we can work better together to do that”
Information that was obtained from communication channels that allow for a delay in response.
EXAMPLE: Emails, chat, blogs, trace data, publications, etc.
QUOTE: “We've had some requests for people to use software that they found in a blog posting. And without a license attached to it, you just didn't know where it came from”
This is the approach that we have found to be most useful when coding, as well as helping others get up to speed with the coding process. Note that this is a time-intensive process that is mentally taxing. Each interview takes roughly 1.5 to 2 hours to code, and post-coding discussions may take up even more.
After reading through the coding handbook, make sure you have a working understanding of the dimensions. It is okay if you do not have a deep understanding, as this will come during the coding process. However, a solid base understanding is required to increase the quality of the coding.
Before you start actually coding, create a 'cheat sheet' in which you write down all 5 dimensions and their 2 sub-levels on a piece of paper. Use this cheat sheet every time you code a segment, essentially using it as a checklist to make sure you did not accidentally overlook a dimension.
When coding independently with multiple coders: Go through the document that needs to be coded, and determine which segments are to be coded and which are not.
The coding itself can be done on paper or directly in Nvivo. In either case, keep the dimensions next to you on a separate piece of paper as you code. After reading the segment, write down which dimension levels you identified based on this first pass. Underlining or otherwise marking the sections in the segment that support why you picked that dimension level will make the post-coding discussions go smoother. For all dimensions, it is important to keep in mind what the perspective is (who is speaking and for whom), the context, as well as the direction.
For each segment that you code, look back at the 'cheat sheet' and ask yourself if you see the first dimension on it. If yes, write that dimension down, and underline the section in the text where you base that on. Next, or if that dimension was not found, look at the next dimension and repeat the process until all dimensions have been covered. When in doubt on the dimensions or something in the segment, go with your best guess but mark the section so that it can be discussed later with the other coders.
After the coding has been completed in Nvivo, the coders will meet to discuss their coding results. The goal of this meeting is to resolve questions, and to further understanding of the dimensions. This is done by primarily looking at the disagreements in the coding, but more importantly why someone coding the segment the way they did. This will build and deepen the shared understanding among coders, and should improve the agreement rates in subsequent coding texts.