Terminology and Jargon
09/07/2008 in News
I’m currently studying an OU course in UI Design and Evaluation. Over on the course message board we’ve been having an interesting discussion about the terminology / jargon that the course materials use – in particular the concepts of task scenario, concrete use case, use scenario and essential use case:
a task scenario is related to a specific case, ie it is ‘concrete’
a concrete use case is not related to a specific case, ie it is abstract
a use scenario is a predicted task scenario for an as-yet unwritten system
an essential use case is less specific and higher level than a concrete use case
The students with a development background find this terminology particularly problematic because terms like use-case already exist with a definite and slightly different meaning in OO programming. It’s less of a big deal for me – I’m not a programmer so in my head, they mean what the textbook says they mean. Even so, as a writer I can see that the concepts and their definitions are a bit on the messy side. This is an area of the course that everyone seems to be struggling to learn and retain.
I’d be interested to know how much use these terms get from people doing usability in the real world. If you’re communicating with people from different disciplines, the last thing you need is terminology that means something different in their discipline. I can also see how, as a field that often has to fight to be taken seriously in industry, the language of programming may have been appropriated to add gravitas.
Your thoughts please…
pete bagnall said on 16/07/2008
I generally try to avoid much of the jargon and just speak plain english, and be explicit when explaining things. Partly that’s because I’ve crossed a few of the boundaries from geek to designer, to HCI practitioner, back to geek, over to…. well, you get the idea. But the upshot is that all the conflicting terms are well and truly mangled together in my head.
That said though, I generally understand use cases to means what developers think of as use cases, part of UML and all that side. Scenarios I tend to understand to mean things with Personas in them. For me scenarios covers everything from the very vague “Bob needs to make sure he gets up in the morning, so he does magic with his waker-upper device” right though to “Bob needs to get up for an early meeting so he picks up his alarm clock and turns the alarm time knob until the hand poinst at….”. Both those are scenarios to me. I heard someone say, very rightly that you get problem/solution pairs forming so the scenario gets richer through the design to include the solution as well as the original problem and the problem and solution interact with each other changing both.
I’ve not heard those terms used like that in the real world, but that may have more to do with the little corner of the real world that I inhabit than anything else!
At the end of the day, over complex jargon is a barrier to communication in my book, so as I say – I try to avoid it when I can.
I’m not sure that really very helpful sadly!
Rachel said on 17/07/2008
Well, it wasn’t really a question – more an unfocussed venting of spleen!
Jargon is part of every profession – and effective jargon makes communications between professionals easier, provided it’s the *same* jargon.