Multilayered paper prototyping for user concept modeling
- 1. UKOLN is supported by: Multilayered paper prototyping for user concept modeling Emma Tonkin – Research Officer DC 2009 – Seoul, Korea
- 2. Problem statement This is a talk about how to get your user population to work with you. (Actually, this is just a bit of text on a Powerpoint slide. The talk is happening over there )
- 3. Prerequisites for communication Required: Common ground The opportunity to meet Something to talk about
- 4. User-centred metadata? “ User-centred design for metadata structures?” Is metadata about the user, really? Indirectly...
- 5. User conceptual models A simple conceptual model describes user perceptions of how an object or system operates. Difficult to comprehend/reason about – abstract generalisations
- 6. Caveat An abstraction learnt in the absence of examples and scenarios may present specific difficulties in terms of evaluation - without provision of context of use, the tendency is to generalise on the basis of an abstract model Exploration of a conceptual model is greatly facilitated by the existence of examples and scenarios of use.
- 7. Conceptual model= domain/data model? Not necessarily; lots of simple conceptual models can/should overlay one data model Exploring the way people think about things in different contexts is just part of the puzzle
- 8. Conceptual, logical, physical models Conceptual model – 'this is how I am thinking about it, right now...' Domain model – conceptual model, but the term usually implies a completed, decontextualised overview Logical model - representation of data in terms of a given technology ('this is how it looks, in Dublin Core') Physical model – database-level detail ('this is how it looks, in DC + utf8 + on a big-endian system + using our implementation over a mysql data store')
- 9. Critiques of prototyping in the conceptual domain Hard to evaluate a model – you're likely to evaluate the interface by mistake Interface criticisms may not apply to logical model, poor interfaces will be detrimental to making a good evaluation Models are immune to criticism?
- 10. If not through the user interface, then? Paper prototyping? Cardboard boxes? Molecular models? Just about any simple, easily usable surrogate can support some level of discussion Think of it as something to point at whilst you discuss... Aim: reduce load on working memory, facilitate chunking (ie. recoding information)
- 11. User-centred design methods in Information Architecture Investigated several existing methods Ethnographic methods/contextual enquiry Free-listing Card sorting
- 12. Ethnographic methods & contextual enquiry “ researching human activity through study of user activity in context, observation, interview techniques and examination of related artifacts.” Powerful, reduces bias, deals well with the unexpected Time-consuming, expensive, results sometimes hard to quantify or apply to a design process Various specific methodologies/frameworks exist formalising this, such as contextual enquiry
- 13. Free-listing Borrowed wholesale from cognitive anthropology Simple individual exercise: “Name all the X's you know” Similar to Rosch's well-known “listing things in the category X.” Result: quantitative data (term + frequency)
- 15. A Quick Aside Vocab/ontology generation is a busy research area in general Many methods and approaches exist for identifying things/concepts/ideas, from unsupervised methods over existing datasets to crowdsourcing Lots of possible data sources
- 16. Card sorting Common approach to eliciting information about site navigation, taxonomy design and menu structure Open card sorting: Sort cards into arbitrary groups. Closed: Sort into predefined groups Complex relations can also be represented with simple encoding schemes (adhesive coloured dots?) but a bit messy...
- 17. Card sorting (2) Flexible: potential uses limited by imagination! Cheap Comparison between card sorting outcomes – quantitative data, diffs Can be used as basis for scenario-based testing
- 18. Prototyping complex (multi-entity) data structures? Created a workspace for exploring multilevel relations Very simple (layered plastic sheets on card + OHP pens!) Create, erase, redraw...
- 20. Method Individual free-listing Collation – joint term list (copied onto sticky notes...) Collaborative work: Arranging sticky notes into groups (result: vague approximation of domain model) Exploring the model (scenario-based testing)
- 22. Why the links? Relations between entities/terms/ 'things' Named relations often proposed during discussion, especially through exploration of scenarios
- 23. Analysis Potentially time-consuming, mitigated by setting constraints/ensuring clarity of assigned task Quantitative analysis of results possible Scenario-based exploration of model can be evaluated as a form of task analysis Communication with participants during collaborative development of shared model
- 24. Cost Why bother with users? Data models are part of the user experience, for end-users and developers alike Getting it right will save money and improve uptake of standard Clarifying requirements -- reduce future costs Undiagnosed over-enthusiastic software engineering can overcomplicate simple problems
- 25. Current work Reducing the cost of this approach Much of the time spent is in analysis of results Software-driven equivalent MRVoBI: Metadata Registry Vocabulary Building Interface Visual builder prototype – cheaper means to solve the same problem, enabling automated quantitative analysis
- 27. Future work Linking with registry-backed vocab/AP development tools, such as IEMSR's AP creation tool Integrating this work into an agile AP development process, as discussed elsewhere...
- 28. Acknowledgments Paul Walk James Farnhill Andrew Hewson Tom Richards Alexey Strelnikov Greg Tourte
- 29. Questions?