By Gordon Rugg and Sue Gerrard
This is the third post in a short series on semi-tacit and tacit knowledge. The first article gave an overview of the topic, structured round a framework of what people do, don’t, can’t or won’t tell you. The second focused on the various types of do (explicit) and don’t (semi-tacit) knowledge. Here, we look at can’t (strictly tacit) and won’t knowledge.
The issues involved are summed up in the diagram below.
By Gordon Rugg and Sue Gerrard
This is the second in a series of posts about explicit, semi-tacit and tacit knowledge.
It’s structured around a four way model of whether people do, don’t, can’t or won’t state the knowledge. If they do state it, it is explicit knowledge, and can be accessed via any method. If people don’t, can’t or won’t state the knowledge, then it is some form of semi-tacit or strictly tacit knowledge, which can only be accessed via a limited set of methods such as observation, laddering or think-aloud.
This is summed up in the image below.
The previous article in this series gave an overview. In the present article, we focus on do and don’t knowledge, i.e. explicit and semi-tacit knowledge.
Continue readingBy Gordon Rugg and Sue Gerrard
Tacit knowledge is knowledge which, for whatever reason, is not explicitly stated. The concept of tacit knowledge is widely used, and has been applied to several very different types of knowledge, leading to potential confusion.
In this article, we describe various forms of knowledge that may be described as tacit in the broadest sense; we then discuss the underlying mechanisms involved, and the implications for handling knowledge. The approach we use derives from Gordon’s work with Neil Maiden on software requirements (Maiden & Rugg, 1996; reference at the end of this article).
In brief, the core issue can be summed up as whether people do, don’t, can’t or won’t state the knowledge. If they do state it, it is explicit knowledge, and can be accessed via any method. If people don’t, can’t or won’t state the knowledge, then it is some form of semi-tacit or strictly tacit knowledge, which can only be accessed via a limited set of methods such as observation, laddering or think-aloud. Because of the neurophysiological issues involved, interviews, questionnaires and focus groups are usually unable to access semi-tacit and tacit knowledge.
The image below shows the key issues in a nutshell; the rest of this article unpacks the issues and their implications. There are links at the end of the article to other articles on the methods mentioned in the table. The image below is copyleft; you’re welcome to use it for any non-commercial purpose, including lectures, as long as you retain the coplyleft statement as part of the image.
By Gordon Rugg
There are often problems when a concept has a name which looks self-evident, but which is actually being used with a specific technical meaning.
This is the case with the terms User Centred Design (UCD) and Person Centred Design (PCD).
So what are these approaches, and why are they so different from other approaches to design, and why do these names lead to confusion?
In brief, User Centred Design and Person Centred Design with uppercase are names for methodologies containing specific methods and concepts. They’re terms of art, used with specific non-obvious meanings, hence the common confusions relating to them. So, what are the reasons for these approaches having arisen, and what is in them?
By Gordon Rugg
In a previous article, we looked at what happens when you take two concepts that are normally viewed as opposites, and instead treat them as two separate concepts. We used the example of what happens when you treat liking and disliking as two separate concepts, and ask people to rate items in relation to both liking and disliking.
The result is that people are willing and able to do so. The image below shows types of response that we’ve seen in real data.
Item A has been rated low both for liking and for disliking; it’s just boring, with little to be said for or against it.
Item B has been rated high both for liking and for disliking; it produces strong but ambivalent feelings. An example that we saw involved university departmental websites, where some were strongly liked because they signalled high quality, but simultaneously strongly disliked because that same signal of high quality was viewed as implying unforgivingly high expectations.
Item C has been rated high like/low dislike by some participants, and low like/high dislike by others. This is informally known in the UK as the Marmite effect, where people either love something or hate it, with few people in between.
This approach of uncoupling apparent opposites is well established in some fields, but isn’t yet widely known outside them. We’ve been using it for a while in software evaluation, where it’s invaluable for improving software mockups before committing to the final design. We’ve also blogged about ways of using it to represent expressive and instrumental behaviour; handedness; and gender roles, going back to the literature where we first encountered it, in Bem’s work on androgyny (Bem, 1974).
The advantages of using this approach are clear when you see examples. In the next section, we’ll look at the background theory on which it works. We’ll then apply it to an apparently paradoxical finding about facial attractiveness, to show how the underlying issues can be swiftly and easily teased apart via this representation.
By Gordon Rugg
Treating liking and disliking as opposite ends of the same scale looks so obvious that few people ever think about it. They’ve been viewed as opposites since at least Classical times, when Catullus wrote about the paradox of loving and hating the same person. However, this approach doesn’t actually work very well when you try applying it systematically in contexts like surveys or evaluation or market research. There are usually pros and cons that you’re asking the respondent to compress down into a single number, and respondents usually don’t look very happy about it.
So what happens if you instead try treating liking and disliking as two separate scales? The answer is that it gives you a lot of powerful new insights, because liking and disliking are often not opposites.
By Gordon Rugg
Sometimes, product development is straightforward. The client tells you what they want; you produce it; they’re happy with it, they pay you, and everything is fine. This is known in the field as the waterfall model of development; once the client has signed off on the requirements, the process then moves irrevocably onwards, like a river going over a cliff.
When you and the client are dealing with familiar territory, this approach usually works reasonably well. Sometimes, though, things don’t work that way. You’re particularly likely to hit problems when you’re developing something that’s new territory for you and/or the client.
One common problem involves the client changing their mind part-way through development.
Another involves the client being unhappy with what you produced.
Communication problems are another frequent source of trouble, with you trying to make sense of just what the client wants, and getting more and more frustrated.
If you’re in that situation, or you think there’s a risk of getting into it, you might want to try iterative non-functional prototyping. It’s a lot simpler than it sounds, and it’s a fast, cheap, efficient way of getting to the heart of what the client wants, particularly when clients don’t actually know just what they want at the start. It involves looping through mockups systematically until the requirements are clear.
This article gives a short introduction to the core concepts and the process. It should be enough to let you get started; there’s supporting material elsewhere on this blog which goes into more detail about the underpinnings, which I’ve linked to within the article.
Waterfalls and loops
Images from Wikimedia Commons: Attributions are given at the end of this article
By Gordon Rugg
The new version of the Hyde & Rugg website is now live, here:
Among other things, it contains a resource section which pulls together our articles on a range of topics, including academic craft skills for students, elicitation methods, requirements, design, and education theory.
There’s also a section about our research, plus a section on the codes we’ve worked on. Again, these pull together our previous blog articles into a structured framework.
Over the next few months, we’ll be adding more material, particularly in the sections on academic craft skills and on our research.
We hope that you’ll find the site a useful complement to this blog.
By Gordon Rugg
This article is the last in a short series about finding out what people really want. I’ve explored that topic via discussion of idealised dream buildings, to see what regularities emerge and what insights they provide into people’s dreams and desires.
In today’s article, I’ll pull together strands from those discussions, and see what patterns emerge.
Detail from: “Neuschwanstein Castle above the clouds” by Arto Teräs – Own work. Licensed under CC BY-SA 4.0 via Wikimedia Commons – https://commons.wikimedia.org/wiki/File:Neuschwanstein_Castle_above_the_clouds.jpg#/media/File:Neuschwanstein_Castle_above_the_clouds.jpg
Continue reading
By Gordon Rugg
If you’re designing something that’s going to be used, as opposed to something decorative, then it’s a really good idea to make it fit for its purpose.
How can you do that? Observing the users is a good start.
“Observing” is a broad term that includes various specialised forms of observation and analysis. In this article, I’ll describe a simple way of doing basic observation of users, which involves watching out for four key alliteratively-named actions:
It’s simple, but it’s powerful, and it usually catches most of the main problems, and it gives you a good start towards designing something that the users will like.
Not great art, but useful: Four things to watch for in task analysis
Sources of original images are given at the end of this article
hyde and rugg 
