Ethnographic Video as Design Specs
Jacob Buur, Euan Fraser, Soila Oinonen, Max Rolfstam
SPIRE Research Centre, University of Southern Denmark
Alsion 2, DK6400 Sønderborg, Denmark
buur@mci.sdu.dk; eufra09@student.sdu.dk; sooin09@student.sdu.dk; maxr@sam.sdu.dk
ABSTRACT
Ethnographic video is used extensively in some industrial
corporations to document field studies and to convey an
understanding of what is ‘out there’ to HCI designers and
developers of new technologies. The basic assumption is
that ethnography through questioning the prevailing
conceptions of ‘users’ and their practices can encourage
development engineers to solve the right problems with
socially sustainable solutions. However, engineering is
solution-driven, with the currency of negotiation being
requirement specifications and solution principles. While
providing ethnographic insight and recommendations is
surely ideal and appropriate in many cases, there are
situations, in which a bolder engagement is called for to
ensure an impact on the development process. In this
paper we explore how video can function to initiate
‘requirement specs’ discussions rather than just as
inspiration or field data. We investigate how video specs
can support an engineering development process, and
help set clear limitations for which solutions might work,
and which might not, while retaining some of the richness
of the field studies.
Author Keywords
Ethnographic video, user studies, requirement specs,
collaborative design, design material
ACM Classification Keywords
H.5.2 User Interfaces: User Centered Design. D.2.1
Requirements/ Specifications
INTRODUCTION
For many engineers and computer scientists the term
product specifications (or product requirements) has a
magic ring to it. It represents a clear decision on which
direction a development project needs to take. It is
understood that before the point of the specification, all
the ‘fluffy negotiations’ take place: The discussions with
the customer etc. Once the ‘specs’ are in place the real
engineering can begin: The solving of problems to
produce a design that stays within the specs. As we shall
see, newer literature has a more nuanced perception of
how specs relate to engineering practice, but the focus of
this paper is: If this is the prevailing understanding in
industry of how decisions about product designs are made
– how does user research fit in?
The ISO standard 13407 on Human-Centred Design
Processes for Interactive Systems is quite clear on this
OZCHI 2010, November 22-26, 2010, Brisbane, Australia.
Copyright the author(s) and CHISIG
Additional copies are available at the ACM Digital Library
(http://portal.acm.org/dl.cfm) or ordered from the CHISIG secretary
(secretary@chisig.org)
OZCHI 2010 Proceedings ISBN: 978-1-4503-0502-0
49
matter: It recommends a 4-step iterative process of (1)
studying use context, (2) specifying requirements, (3)
producing designs, and (4) evaluating designs against
requirements (ISO 1999). But with a move from task
oriented, model based user studies towards ethnographic
research of people’s practices, some of what ethnography
does the best – ‘to enable designers to question the taken-
for-granted assumptions embedded in the conventional
problem–solution design framework.’ (Anderson 1994) –
is difficult to align with requirements engineering.
A CASE OF PARTICIPATORY INNOVATION
In the case discussed in this paper, we collaborate with
DanChurchAid, a non-governmental organisation (NGO)
that provides relief aid to developing countries, and four
Danish manufacturers of alternative energy sources, like
solar panels and fuel cells. The goal is to develop a
sustainable energy generator that can replace noisy and
fault-prone diesel units in camps in developing countries,
the concrete example being camps for de-mining
operations in Angola. The distance between de-miners
(‘users’) in Angola and development engineers in Den-
mark is as huge in kilometres as in perspective. The pro-
position here is that video can help bridge that distance.
The project ‘Sustainable Energy for De-Mining Operati-
ons’ runs over a period of 1.5 years, in part with public
funding. The project is organised as a participatory
innovation effort in the sense that care is given to
involving the voices of potential users and other people
with a stake in the new product, and focus is on the
building of new business relationships. SPIRE is involved
as partner with responsibility for the study and involve-
ment of users throughout the innovation process and for
the design of the user interface of the generator.
In this paper we look at two of the team workshops in
which we engaged video to create design concepts and
requirements of the energy generator. The first workshop
in the very beginning of the project was focused on
design concepts based on video specs edited from
‘borrowed’ footage from Congo. The second workshop
came 6 months later, after the team had made a fieldtrip
to Angola. It aimed at pinpointing requirements, based on
a video wall of short clips from Angola.
The research focus of this paper is to investigate how
ethnographic video can support the process of determin-
ing design requirements?
Our research method is action research in the sense that
we both participate in the project by organizing activities
to support the team in overcoming immediate challenges,
and document and analyse the actions to contribute to
general knowledge within the scientific field.
THE ROLES OF DESIGN SPECS
The project brings together team members from different
disciplines, each with their own tradition of relating to
specifications. We will briefly outline these traditions in
the following.
Mechanical engineering specs
The companies in the project are for the most part
embedded in a mechanical engineering approach to prod-
uct development. In mechanical engineering specificat-
ions are typically seen as precise, measurable, and
detailed targets that establish what constitutes success or
failure in the development of a product. They resolve
complex trade-offs among product characteristics and
minimise subjective interpretation of customer needs.
The completed specifications shall represent an unambig-
uous agreement on what the team will attempt to achieve
through product development (Ulrich & Eppinger 2008)
(Pugh 1991). General goals and implicit requirements
need to be ‘translated’ into product relevant parameters,
at best quantified or defined in the clearest possible terms
(Pahl & Beitz et. al. 2007). There are attempts to system-
atize this ‘translation’, most prominently the ‘House of
Quality’, a matrix that maps the ‘Voice of the Customer’
(quotes from customer or user interviews) onto product
design parameters (Hauser & Clausing 1988). There is
also a general understanding that specifications must be
‘locked down’ and changed only through appropriately
sanctioned procedures (Pahl & Beitz et. al. 2007). Bucci-
arelli concurs that boundaries are necessary for design to
proceed, but questions Pugh’s notion that specs are
sacrosanct, ‘given’ and ‘clear’. On the contrary he claims
that specs are never clear as not all participants in the
design process will read them in the same way (Bucci-
arelli 1994). In contrast to other authors who adopt a
predominantly theoretical stance, Bucciarelli has based
his work on studies of the actual practice in engineering
projects: ‘Nothing is sacred, not even performance
specifications, for these, too, are negotiated, changed, or
even thrown out altogether, while those that matter are
embellished and made rigid with time as design
proceeds.” (Bucciarelli 1994). There seems to be a dilem-
ma between the textbook procedures of requirements-
before-design and the actual development practices.
Software requirements engineering
The case team also counts members with a software
engineering approach to development. The fuel cell and
solar panel companies both develop control software, and
the second university partner brings expertise in the
development of power grid management software. In
software engineering, requirements are often seen as a
binding ‘contract’ with the customer about what the
system should satisfy, even to the extent that formal
specification languages have been developed to prove that
a given piece of software does the job it was specified to
do. Approaches have also been developed to include
‘social aspects of work’ (Viller & Sommerville 2000) and
‘soft goals’ (‘Requirements that are not only implict, but
also subjective, context specific, imprecise…’) (Jureta
50
et.al. 2006) in requirements formulation. To counter
‘spaghetti programming’ software engineering in the
1980s developed elaborate procedures for documenting
requirements in several steps along the ‘waterfall’ model.
This, on the other hand, led to a critique of the specific-
ation approach for not being able to react to customers’
needs, as ‘people don’t know what they need until they
see it’. Advocates (in particular in the Participatory
Design community) of this line argued strongly for
prototyping and creative design as a way of getting user
feedback early (Löwgren 1995). According to Schrage
there are simply two different cultures in software
engineering: ‘Specification-driven cultures draw heavily
from market-research data before they move concepts
into the prototyping cycle. In prototyping cultures,
prototypes are often used to elicit market feedback before
final production.’ (Schragge 1996). He quotes David
Kelley, IDEO, for arguing that ‘organisations intending
to be innovative need to move from specification-driven
prototypes to prototype-driven specifications.’ The
‘prototyping culture’ has developed into agile approaches,
like Extreme Programming, that break with the
requirements focus and bank on faster iteration cycles
with repeated prototyping to obtain user feedback. In HCI
it is common to work with use scenarios of how people
will operate the prospective product or system (Carroll
1995), and along with use-cases (Alexander & Maiden
2004) this method is spreading as a way of capturing
requirements: ’The context provided by real-world
scenarios is useful in bringing into consideration issues
that lie outside the idealistic boundary we might
otherwise have been tempted to draw around a system
description.’ (Benner et.al. 1993).
Video as design material
Video is applied intensely in HCI and interaction design
projects to bridge user research and design, in particular
video from short-term ethnographic studies (Hughes et.al.
1997). Two of the SPIRE researchers bring this tradition
to the project team. When it comes to the role of
ethnographic studies within HCI, Dourish (2006)
criticizes that their usefulness seems to be evaluated only
on their ‘Implications for design’, i.e. if they produce
recommendations directly applicable to design. He argues
that ethnographic studies should also contribute with
models for thinking about the context and practices. Our
research is based in the perception of ‘video as design
material’, i.e. that for the purpose of user-centred design,
video may be regarded as part of the design process itself,
already from the point of co-authoring video in the field
with users, rather than as ‘hard data’ to be analysed for
‘ethnographic interpretation’ (Buur et.al. 2000). Our
focus is less on the video medium itself and what it
communicates, as on the activity we can organize around
it. By pretending that video is the requirement, how will
the negotiation in the design team unfold? What can the
rich, visual context descriptions on video offer when ‘The
design must fit here!’ is focus of the negotiation?
Public procurement of Innovation
The sustainable de-mining project can also be understood
as a case of procurement of innovation. This is the
background of the third SPIRE researcher. When a public
or private organization requires an innovative solution to
a problem, procurement is a challenge. If the required
good is well known, the requirement may be specified
precisely in a tender call and a supplier selected based on
lowest price. But in the case of innovation, where the
solution is yet unknown interactive learning between
procurers, suppliers and other stakeholders is crucial in
order to reach the final solution. This means that the
process cannot be regarded as the result of anonymous
market search as would be the case in procurement of
well-known off-the-shelf products, but as the result of
user-producer co-operation and information sharing
(Lundvall 1988). In a sense requirements are set for who
is to be invited to participate, as the focus shifts from the
product to the competencies of potential partners. Lantz
& Holmlid (2010), for instance, argue strongly for
interaction designers to be involved in the process of
procurement to ensure a focus on users. The assertion we
maintain here is that video may facilitate such interactive
learning between procurer and supplier(s), even in the
pre-procurement phase.
DESIGN SPEC VIDEOS
From the outset the plan was to bring the team to Angola
on a field visit some months into the project, but even Figure 1. DVD cover showing four of the eight ‘video specs’.
before that we, the authors, wanted to open a concrete
discussion about design opportunities and constraints. At min. the participants would watch a new video spec to
the project kick-off meeting we noted that the team of fuel discussions. First, the project team saw the video Life
mostly of engineers was more than happy to plunge into among Mines, a rather dramatic movie created by cross-
solutions thinking. Rather than postpone this discussion editing scenes of how mine clearing happens with the
with a cry of ‘User studies first!’, we undertook a search story of a young mine victim. This was aimed to provide
for suitable video footage from NGO camps that might general motivation for the design task.
work as a framing for such a discussion, so that ideas Sketching based on Video Specs
wouldn’t be grounded solely in Western preconceptions Each of the two 6-man teams had an experienced SPIRE
of life in the developing world. We made contact with a designer at their table to help them visualise ideas. These
TV photographer, who had visited de-mining operations sketches were then pinned on large boards to serve as
in Congo two years previously. Although his footage was inspiration for the second part (building a scale model).
shot for a different purpose (a TV programme on NGO During the sketching session the teams watched three
activities), we were able to find suitable material on the video specs: First Humble Heroes, a portrait of de-miners
14 hours of his raw footage to edit a set of eight video presented as ‘user requirements’. Then Daily Struggle, a
specs, each providing concrete background for crucial video about the tough conditions in the camps
requirements decisions: User operation, maintenance, (‘maintenance requirements’), and finally Voices of the
transport, instructions etc. Eight graduate students in a Compound’ about how daily life after work is
course on video in design completed the actual sorting accompanied by the constant hum of the generator
through the material, the finding of themes with the (‘environmental influences’). Each of the video specs
Video Card Game (Buur & Søndergaard 2000), and the were accompanied by a short question meant to challenge
editing of the 2-min videos under expert guidance of the design thinking, see Figure 1. We documented the two
TV photographer. teams in action on video for later analysis of their
The video specs were used in a full-day workshop, in conversations lead to design ideas.
which the participating companies also demonstrated How do video specs influence designs?
their technologies to each other. The goal was to generate In many instances there is a clear link between the videos
an overview of possible solutions directions and if the participants see and what they discuss. Sometimes the
possible pick a concept to complete a mock-up in time for images lead to very literal translations into ideas. After
the Angola trip. On the day we organised two design having seen locals carrying packages on top of their heads
sessions in which the 12 participants worked in two in Daily Struggle this conversation unfolds in one team:
mixed teams: In the first hour they were encouraged to
JP: Then a string of people could carry it.
sketch ideas for the energy generator, in the second hour
they built a scale model of their best concept. Every 10

51
LR: So maybe we should include an indent in the bottom
side of the box – to carry it on your head!
PV: But then suddenly we are not talking about one big
box with everything inside, but a number of smaller ones.
JP and LR are both university researchers, whereas PV
comes from one of the companies. Here, the video image
leads the team to reconsider the concept of ‘one big box’
they initially preferred, to think of a modular system
instead. In fact the team slowly gravitates towards this
concept and in the end presents it as their solution.
Another literal translation is seen in Figure 2. Having
seen motorbike transport and bicycle packing on video,
one team sketches a portable motorcycle generator. The
other team sketches the energy generator as a boat with
wheels, after having seen transport along flooded roads.
Both ideas are soon abandoned, however, as unrealistic. If
we see the video imagery as inspiration for new ideas, it
supplements what experience a project team would
usually draw on closer to home. When discussing
simplicity of user maintenance, for instance:
LR: I come to think about photocopiers, when paper
get’s stuck inside (…) many of the newer models have a
very clear coding with numbers and icons.
In this case the video spec initiates the discussion of a
local maintenance challenge, but the team draws on many
other experiences for ideas of how to overcome it.
Ideas and requirements are intertwined
It is rather clear to see that what happens in the session is
not a 'clean' process of generating design concepts based
on requirements. There is a constant discussion back and
forth between ideas and requirements: What is really
needed? As the participants explore various ideas they
come up with new questions about the environment, the
people, and the practices in the camps. The weight limit,
for instance, is strongly dependent on which means of
transport are available: If trucks can come through to the
camp area, the weight is much less crucial than if the
generator needs to be transported by motorbike or by
local carriers. This is in contrast to requirements engin-
eering thinking that stresses requirements before solut-
ions, whereas newer literature accepts that analysis
cannot be separated from design (Löwgren 1995); requi-
rements and imagined solutions are closely intertwined.
Empathy at play
We observe that the team members gradually develop
respect for the de-miners on video. What role does
empathy building have on design? In HCI and interaction
design literature it is frequently suggested that identifying
with users through for instance personas and user
portraits is an important encouragement to design for user
needs (Grudin & Pruitt 2006, Ylirisku & Buur 2007). In
the beginning of the session – before the teams have seen
the first video spec – there is lots of talk of what 'they'
must do out there, and how technically unqualified 'they'
might be. But some of the videos manage to foster
empathy with the de-miners and respect for their skills.
After Humble Heroes – the video in which you can
actually see the sweat on the de-miner’s brow, when
finding a mine – one team is very quiet at first.
52
Figure 2. Literal translation of ideas: An image from a video
spec – and a sketch from the design team session.
PH: On the video this guy just found a mine, and then
another guy came to examine it.
MC: It’s almost like seeing a physician.
DS: He certainly has knowledge about mines.
PH: I don’t know how educated they are… but they
definitely know how dangerous this job is. (…)
JLB: If there was suddenly no power, I would feel a bit
distressed.
RA: It would help with a more reliable energy supply.
You would even make the job more attractive.
By comparing the expertise of the de-miners to something
they know (a physician), and by identifying (I would feel
distressed), the team starts building respect for them, and
they realize that what they are about to develop, may have
a very concrete impact on the work of the de-miners.
Education level is also the topic in the other team, where
the conversation equally moves from a nondescript ‘they’
to an increasing respect for what the de-miners do:
PV: Is there a Dane or a European present that’s in
charge? Someone with a technical background?
MO: I don’t think we can expect that.
LR: They did use this mine detector. That was quite
technical. So they aren’t entirely without knowledge.(…)
MO: And we heard that they need to complete a course.
LR: Of course they need training. Everybody needs that.
MO: Yes, everybody needs that.
It seems that the participants build empathy through
learning more about what de-miners do and seeing
moving images of the people and how they react.
Empathy relates to user knowledge, but may not come
automatically with increased knowledge. The way the
short video is photographed (face close-ups) and edited
(suspense) adds drastically to the process. Empathy is not
usually treated in requirements literature. Engineering
development is seen as objective, rational, independent of
personal preferences. We can speculate along with HCI
literature that empathy with users is crucial for the
success of a project like this (or any user-focused
development task for that matter), but all we can see here
is that empathy is in fact at play.
Building scale models based on Video Specs
During the sketching session it became clear that a major
trade-off between power, size and weight was required:
To design a combination of energy devices (like solar
panels) of sufficient size to provide the required energy
level, yet still easily transportable in difficult terrain. In

Figure 3. Two generator design concepts: The modular
system (left) and the all-in-one container solution (right)
planning the workshop we anticipated that the teams
would want to discuss quantitative requirements: Dimens-
ions, weight etc. To encourage that we asked the teams to
build a model to scale of their favourite generator concept
in the second 1-hour session. We prepared cardboard
pieces in 20:1 of solar panels, batteries, fuel cells etc.
During the building session we showed four videos, again
interspersed with 10 min. design intervals: Pack me Up
showed a range of scenes bordering on the grotesque, of
how much you can pack in a boat, on a truck, on a
motorbike, or on a bicycle in a developing country
(‘dimensional requirements’). “Roads” showed various
means of transport on very rough roads and tracks
(‘transport requirements’). After this video we added toy
trucks, motorcycles and figurines to the tables, in the
same approximate scale as the solar panels. The third
video Pushing the Boundaries showed examples of the
tough conditions equipment might need to operate in
(‘handling requirements’), culminating in a scene of a 4-
wheel drive vehicle being loaded onto three canoes and
ferried down a river. The last video Writing in the Sand
showed various ways of communicating between NGO
and locals, primarily through images. Through the
sessions the video specs made it increasingly difficult to
reach a viable concept – the generator would need to be
transported in canoes and on motorbike, stand very coarse
treatment, be assembled and operated based on picture
guides etc. The teams developed two different concepts:
• An all-in-one container that would unfold to provide
the complete generator function (but require a small
truck for transport), and
• A modular system with smaller, mobile units; easily
transportable (but would require some intensive
training to set it up and make connections).
Again we video documented the two teams in action and
analysed how they engaged with the material to build
design concepts.
Quantities play a role, but !
In engineering literature it is suggested that requirements
should be quantitative, to allow for easy assessment of
concepts against the requirements. At this stage of the
team discussions, it seems rather premature to fix
quantitative limits of, for instance, the dimensions of the
solar panels. The team that is now swaying towards the
modular concept discusses this:
JP (while cutting a ‘solar panel’ in two pieces): Do you
work with folded solar panels?
53
LN (who arrived late and hasn’t seen video yet): No, you
can’t do that. It’s tempered glass. They are completely
impossible to fold.
LR: Yes, but can’t you break it down into smaller
elements? For instance 0,5 x 1 meter? (…)
LN: What is wrong with a 1 x 2 meter solar panel? How
big is the container you've planned?
PV: Well, maybe there isn't going to be a container...
MO: We’ve seen examples where there are no roads!
In this case, LN’s position, although well argued in her
own technical expertise, is not taken as fact by the team.
It is challenged by the other team members because they
can make reference to the videos they have seen.
Similarly, in the other team that favours the container
concept, the video Pack me Up draws attention to the
weight issue:
PH: This (container concept) would be big and heavy!
(…) If you’ve got the panels that’s like 20 kilos each…
you’ve got batteries and you’ve got a fuel cell and…
RA: 400 kilos… 400 kilos! (…)
PH: you don’t need to put it ON the car; you can pull it
after the car, like a trailer. (…) Or motorbike.
RA: The diesel generator is supposed to be around 40
kilos… So we’re talking something like twenty times the
weight of that!
DS: We split it up in modules that are less heavy…
By struggling with their design concepts up against the
‘requirements’ visible in the videos, the participants
gradually expand their knowledge of camp particulars,
but also struggle with the differences between their own
preconceptions of what a camp is like, their technical
positions, and what the video brings. Overall, the project
members were pleased with the outcome of this
workshop. It formed the baseline for the field trip to
Angola some months later, in which 6 of the team
members visited de-mining operations and various NGO
camp setups. Also the decision was made to prepare
mock-ups the size of two ‘modules’ to bring along for
testing local handling and transport.
VIDEO WALL OF REQUIREMENTS
The second workshop we report on followed two months
after the Angola trip. In between there were several
meetings, but the discussion of how to design a
sustainable generator had not come to a conclusion yet.
We, the authors, decided to organize a second session
based on video (now our own footage from Angola), but
this time with a focus on requirements setting. The
challenge was to create a workshop programme with
enough structure to make the collaboration progress, but
open enough to allow people from other backgrounds
(NGO-employees in particular) to put forward their points
of view. For this session we picked 18 short clips that
each showed a dominant user activity relating to energy
generation, and created a video wall activity. A video wall
is a small software application that runs a number of
looped videos at the same time on a computer screen. The
images can be moved around and labelled like post-it
notes (Buur et.al. 2004). The activity we devised was
simple: We asked each of two teams to discuss what
requirement each video clip might represent, to label the
requirement, and to place it on the screen as a must-have,
should-have, or could-have requirement. After 30 min.
each team had created a map of requirements, see Figure
4. Also this session was documented on video and
subsequently analysed to understand how video
influences the negotiation of design specs.
Naming requirements as a team challenge
Based on the team’s discussion the facilitator needs to do
two things on the screen: Place each clip in the must-
have, should-have, or could-have column, and add a label
with a short description of the ‘requirement’. Much of the
time is spent trying to come up with a precise
‘requirement wording’ for aspects that have been
discussed in previous meetings. For instance this
discussion of Clip 10: Locals walk along road.
CH: This is about contact to the local population.
LN: If the local population sees something is possible,
then they’d also want to have it?
JR: Capacity building – that’s interesting for the business
case too.
LN: If the generator stays there after the de-mining
operation they can start planning what to use it for
afterwards.
PV: Rural development?
CH: Local development?
LN: Second life of the installation?
This collective search for words ends with the elegant
formulation ‘Local capacity development’, which the
facilitator notes on the label on the screen with nods of
consent from all members. One shouldn’t underestimate
the importance of wording. While struggling to find the
right way of expressing a new requirement, the team
members bounce suggestions off each other and expand
their shared understanding of what is important in this
project. The video wall activity provides the framing for
this discussion: Each video clip in itself may not need to
precisely ‘represents’ a requirement; the team will make
sure that only the most important requirements are
accepted. And the fact that there is a label to be filled in
encourages the team to form consensus on ‘what are we
talking about’ and find a short formulation that says it.
Figure 4. Video Wall activity: Video clips are labeled and
arranged as requirements according to their importance.
54
Must/should/could-have negotiation
In the video wall session participants are asked to, in the
language of Ulrich and Eppinger (2008), prepare a metric
by assigning each requirement a relative value, in this
case by deeming the feature a ‘must-have’, ‘should-have’,
or ‘could-have’. This challenges the participants to
consider through discussion what level of priority should
be placed on the requirement. The relative value setting
causes a fair degree of debate within the teams, perhaps
not surprisingly when we consider Bucciarelli’s notion
that:
‘Design and design decisions depend, then, upon the
values and interests of the participants.’
In one of the teams, the debate mainly occurs between
PH, manager of an engineering company, and AC,
operations manager for the NGO, DanChurchAid. In
Clip 6: Battery charging, we see an operator preparing to
charge the detector batteries at night. This leads the team
to discuss ‘Simplicity of connections’ and PH takes a
pragmatic approach, maintaining that this is a ‘should-
have’ not a ‘must-have’. He likely anticipates that ‘simp-
licity’ may require expensive non-standard components in
the production process. AC on the other hand has a more
idealistic standpoint, thinking of what would be best in
the field rather than the factory:
AC: No, I’d tend to say it’s a must-have because again,
you want to keep it as simple as possible and eliminate
the risk of fault or improper use.
On this occasion AC manages to convince PH that he is
right. The video footage allows AC to argue, with the
help of a common, visual reference point, for what is best
for the users. The negotiation over the value, supported
by evidence from the video, also means that the metric is
debated and examined in such a way that the customers
voice is kept at the forefront of the discussion. Ulrich and
Eppinger (2008) employ a working assumption that: ‘a
translation from customer needs to a set of precise,
measurable specifications is possible and that meeting
specifications will therefore lead to satisfaction of the
associated customer needs.’ Whilst this is logical, it
means that the translation process is crucial to the
outcome meeting customer needs. The discussion and
references prompted by the richness of the video material
provides a strong base for the translation of needs to
metrics that still contain a strong sense of the voice of the
customer. Ulrich and Eppinger (2008) concede that the
translation process is imprecise, and for that reason the
loosely structured negotiation and debate prompted by the
video wall seems to be a more appropriate format for this
translation than regimented methods such as the Needs-
Metrics Matrix (Ulrich & Eppinger 2008) or the House of
Quality (Hauser & Clausing 1988).
We see more evidence of the video allowing the
customers’ needs to be retained and placed at the centre
of the negotiation in AC’s arguments following Clip 7:
Loose sockets, where an operator tries to connect loose
electricity sockets to power the camp’s appliances:
AC: The way we have it here is we are trying to design
something, or come up with criteria that is going to give
us the most efficient use of the machine. So therefore we
want to have it as… to meet our requirements as best as
possible. If you don’t have it… if you allow them options
then the chances are they are going to plug something in
the wrong way.
However, after Clip 9: Checking lights, in which the
operator walks around the camp to verify all connections,
PH interestingly manages to convince AC that a more
practical approach would be best:
PH: Find a simple way of telling. That could be a light…
AC: Yes.
PH: Green or red… should-have.
AC: I’d say must-have.
PH: No… no, no, that’s a should-have because you will
be able to operate it without.
AC: Ok, that’s true, I agree.
Here PH’s logic and pragmatism is more powerful than
AC’s desire to have the perfect product. Especially in the
negotiations between PH and AC the institutional tension
is evident, as any new proposition will affect these two
stakeholders in opposite ways. For AC, any new idea or
claim leading to improvement is relatively cheap, while
for PH, being the engineer, in most cases the ideas mean
additional cost. The open-natured discussion, common
reference points, and equal footing created by the video
means that the participants can effectively and rationally
negotiate across discipline boundaries. This debate and
relative grading means that there are few compromises or
halfway houses. In this case, agreement is always
reached in the end, after the metric has been evaluated in
the negotiation. This might satisfy Ulrich and Eppinger’s
(2008) call for ‘unambiguous agreement’ on what the
team will attempt to achieve through the products
development, yet this agreement does not place such strict
‘boundaries on the subsequent designs’ as Pugh (1991)
advocates, meaning the metric can still be debated,
explored, reformulated, and re-understood.
DISCUSSION
It would be clear that our collaborative ‘process
mechanics’ did support the team in determining design
requirements with a strong focus on user practices – to an
extent that would not have been possible without the
ethnographic video. The video spec activity showed how
edited videos presented as ‘hard requirement
specifications’ support designing. The video wall session
showed how short video clips support requirements
elicitation. The use of video means that the participants
are able to experience in a very vivid way some of the
conditions, issues, and contexts the product innovation
will come up against. This elicits a high degree of
empathy from the participants, and struggling with early
prototype decisions endows them with a significant
amount of user knowledge.
So let us re-examine the core proposition: What exactly
constitutes a ‘video spec’? Do we run the risk of
55
promoting ‘ethnography tourism’ in the words of
Crabtree et.al. (2009) with thin descriptions of the field
and gross generalisations? Rather than edited ‘insights’
that communicate a particular analytic interpretation, or
small ethnographies that explain broader rationales, our
video specs mirror practices that we encourage the
developers themselves to render significant through their
design moves. We engage the ethnographic eye in
compiling images of practices and environments that the
fieldworker find cardinal to the success of the innovation
on the drawing table. We choose to work with a set of
short videos, themed by requirements categories. There is
a good deal of work left in determining how such themes
are best selected, but Viller and Sommerville’s (2000)
concept of ‘concerns’ seem like a promising starting point
for further experiments.
The video recordings for the first design workshop were
actually not recorded for the particular purpose, and even
came from a different country. Does the ends justify the
means? Could we have picked random YouTube video
material? A comparison with the footage shot in Angola
shows that indeed the practices and environments in the
camps in the two sites were comparable. If anything, then
the Congo photographer in some ways was able to get
closer to the actual practices of demining. The contribut-
ion of the Angola material was most of all to widen the
scope of the project. Where our initial pick of footage
focused on the concrete activities in the camp, the Angola
ethnography confirmed this, but also added an under-
standing of the broader motivations of management and
the surrounding community to accept sustainable solut-
ions. The existing ‘generator culture’ has severe implicat-
ions not just for the generator design but for the entire
processes of introducing and running it. So yes, we
believe it possible and advantageous to employ video
material shot for other purposes for engaging a design
team in familiarising with a new use context, provided a
check against the actual field is foreseen.
In Figure 5 we compare the video specs and video wall
activities to other specification methods. We characterize
them according to their grounding in (objective) market
data or (subjective) user empathy, and whether they
support a specification-driven or prototype-driven
process. The House of Quality, for instance, is based on
market data and supports a specifying approach, whereas
Use Cases tend to support the generation of ideas for
prototyping. Neither does much in terms of building
empathy with users. Personas and Video Portraits of users
on the other hand are dedicated to fostering empathy, but
may not have a clear role in supporting either specifying
or prototyping. The video spec and video wall activities
each fill in a space in the empathy half that is presently
sparsely populated. With the experience from this case we
suggest that specifying vs. prototyping is not a question
of either-or, but both-and. Or, in David Kelley’s words,
‘prototype-driven specification’ (in Schragge 1996).

Figure 5. Characterisation of design spec methods in relation
to their aim and grounding.
CONCLUSIONS
Ethnographic video cannot in itself set requirements for
the performance of a new product; such measures need to
be negotiated between members of the development team.
What video can do is provide very strong support for this
negotiation of requirements. As part of an appropriate
activity ethnographic video can:
(1) Provide an incentive (a framing) for the various
participants in a project to – in the words of Bucciarelli
(1994): ‘move beyond the secure confines of object
worlds and engage one another on more common and
less ordered ground for the design to proceed.’
(2) Help shift the discussion from a seemingly objective-
rational determination of requirements to a dialogue about
practices based on empathy for the potential users.
(3) Offer an ordered process of negotiation, creating
consensus about specs through the interlinked activities
of finding, naming and prioritising design requirements.
The video spec process allows designers to more closely
formulate concepts and prototypes alongside specificat-
ions in an iterative, fluid and bidirectional process. Seen
in the broader light of the increasing attention on public
procurement as a means to generate innovation, we see a
potential for video in bringing customers and potential
suppliers together in pre-procurement processes to
discuss requirements with a strong user focus. Research
methods-wise the consistent reactions on the video
activities in the two teams leads us to believe that we may
generalize our findings beyond the single case.
ACKNOWLEDGMENTS
We are indebted to our project collaborators, to TV
photographer Esben Grage for his recordings from
Congo, to the IT Product Design graduate students 2009
for the editing of the video specs, to Roeland Vugts for
preparing the video wall, to Tamim Shakeel for recording
parts of the Angola material, and not least to the NGO
employees and de-miners in Congo and Angola.
56
REFERENCES
Alexander I., Maiden N. (2004) Scenarios, Stories, Use Cases.
Wiley
Anderson, R J (1994) Representations and Requirements: The
Value of Ethnography in System Design. Human-Computer
Interaction, Lawrence Erlbaum Associates vol. 9 pp. 151-182
Benner, K., Feather, M., Johnson, W., & Zorman, L. (1993).
Utilizing scenarios in the software development process. In
N. Prakash, C. Rolland & B. Pernici (Eds.), Information
system development process (pp. 117--134). Netherlands:
Elsevier Science Publishers.
Bucciarelli, L.L. (1994) Designing Engineers. MIT Press.
Buur, J; Binder, T and Brandt, E. (2000) Taking Video beyond
‘Hard Data’ in User Centred Design. PDC, New York.
Buur, J; Jensen, MV; Djajadiningrat, T. (2004) Hands-Only
Scenarios and Video Action Walls – novel methods for
tangible user interaction design. Proc. DIS, Boston
Buur, J and Søndergaard, A. (2000) Video Card Game: An
augmented environment for User Centred Design discussions.
Designing Augmented Reality Environments, Helsingør.
Carroll, J. (1995). Scenario-based design. Wiley
Crabtree, A., Rodden, T., Tolmie, P., Button, G. (2009). Ethno-
graphy considered harmful. In Proc. ACM CHI, New York:
pp. 879-88.
Dourish, P. (2006) Implications for Design. Proc. ACM CHI,
Montreal, pp.541-550.
Grudin, J. & Pruitt, J. (2002). Personas, participatory design,
and product development: An infrastructure for engagement.
Proc. PDC 2002
Hauser, J. and Clausing, D. (1988) The House of Quality.
Harvard Business Review, Vol. 66, No.3, pp. 63-73.
Hughes, J., O’Brien J., Rodden, T., Rouncefield, M., Blythin, S.
(1997) Designing with Ethnography: A presentation
Framework for Design. In Proc. DIS, ACM, pp. 147-158.
ISO (1999), ISO13407 Human-centred design processes for
interactive systems, European Standard, Internat-ional
Organization for Standardization (ISO).
Jureta IJ, Faulkner S, Schobbens PY (2006) A More Expressive
Softgoal Conceptualization for Quality Requirements
Analysis. In: Proc. 25th Int. Conf. Conceptual Modeling, ER
'06, Springer, Tucson, Arizona, pp 281-295
Lantz, A. and Holmlid, S. (2010) Interaction Design in
Procurement: The View of Procurers and Interaction
Designers. CoDesign 6 (1) pp. 43-57.
Löwgren, J. (1995). Applying design methodology to software
development. In Proc. DIS, ACM, New York, pp. 87-95.
Lundvall, Bengt-Åke (1988): Innovation as an interactive
process: from user-producer interaction to the national system
of innovation In Dosi et al. (1988)
Pahl, G; Beitz, W; Feldhusen, J. and Grote K.H. (2007) Engin-
eering Design. A Systematic Approach. Springer, London.
Pugh, S. (1991) Total Design: Integrated Methods for
Successful Product Engineering' Addison-Wesley Pub
Schragge, M. (1996) Cultures of Prototyping. In: Winnograd, T.
Bringing Design to Software (Chapter 10). ACM Press
Ulrich K. and Eppinger S. (2008) Product Design and
Development. McGraw-Hill.
Viller S, Sommerville I (2000) Ethnographically Informed
Analysis for Software Engineers. Int. J. of Human-Computer
Studies vol. 53, pp.169-196
Ylirisku, S. and Buur, J, (2007) Designing with Video. Focusing
the user-centred design process. Springer