1 Experimentation setting model VHO study cluster Spring 2005 Mervi.Ranta@hut.fi, Henrik.Asplund@hut.fi PM&RG Product Modelling and Realisation Group Department of Computer Science and Engineering Helsinki University of Technology P.O.Box 5400, FIN-02015 HUT, Finland
Experimentation setting model Target users Experimentation environment Scenarios Services Use cases Realization
Experimentation setting model Target users Experimentation environment Models in innovation prototyping Background Scenario Definition Service Typical sources Use case Proposed structure Realisation Modelling issues of innovation prototyping Challenges for future research
Target users What users/user groups is this experimentation targeted to Size of the target group/groups Define your basis of segmentation Demographic Age, gender, marital status, household size Interests and hobbies Early adapters conservatives Market segment Possible named group or persons that you have in mind Constraints or requirements on the users/user groups Control/comparison/peer group
Experimentation environment Needed environments, locations or equipment Requirements and features Possibly needed staging and arrangement Arrangements Moderators, actors, technical personnel Implementation and modification Needed implementation and modification work to realise needed prototypes Needed time Reservation of environments For preparations For experimentation
Models in innovation prototyping: scenario, service, use case and realisation Scenario is a detailed story about situations and actions of a user Use case is a description of interaction of system interfaces. Scenario Service Use case Realisation Service includes information on media containers, stakeholders, features, user needs, provision chain etc. Hardware, software, description of system architectures, networks
Potential confusions of the modelling concepts Here, the concept of scenario does NOT refer to Vision (sight, thing seen in dream or trance, foresight ) Here, the concept of use case does NOT refer to Usage guide Either of them refers here to A title or few sentences describing a vague situation Here, the concept of service does not refer to consulting etc. service sector Thus, please forget for a while your first intuitive thoughts on the concepts to allow us discuss scenarios, services, use cases and realizations Models for structuring design data The separate concepts with own objectives
Scenario
An example of the definitions of a scenario The defining property of a scenario is that it projects a concrete description of activity that the user engages when performing a specific task, a description sufficiently detailed so that design implications can be inferred and reasoned about. Using scenarios in system development helps keep the future use of the envisioned system in view as the system is designed and implemented; it makes use concrete which makes it easier to discuss use and to design use. [Carroll: Scenario-Based Design Envisioning Work and Technology in System Development, Wiley & Sons, New York 1995]
Scenario in innovation prototyping Scenario is a story about the situations and actions described in colloquial language, conventionally from user s viewpoint. Contains concrete details on participants, time, places, objects, conditions etc. Approach and emphasis Scenarios concretise services to reveal common denominators. E.g. typical sources are observation, project or assignment plan, literature hobby, sci-fi interest, SCENARIO Entertainment for a train trip Scene 1: At 8.30 on a spring morning Lena Scene 2: Lena enters the train that departs at 8.45. While on the train Lena enjoys music SERVICE USE CASE REALISATION
Scenarios typical sources in innovation prototyping Realizations, use cases, services -> SCENARIOS Authored by technology experts, content providers, service designers etc. Ideas from experts, design team members etc. Engineers as innovators Pelle Peloton Explaining possibilities of technology, business ideas, content formats etc. Explicating a common goal Using scenario for negotiating and expressing the common goal Ensuring a shared understanding and focusing the efforts SCENARIOS -> services, use cases, realizations Authored by scenario writers, user study experts etc. Idea generation Systematic idea generation methods and sessions E.g. scifi literature, movies etc. as sources User studies Contextual design, participatory design etc. Observation, interview, focus group etc.
Proposed structure for a scenario 1/2 Title of the scenario Context* Participants* Non-human participants* Locations* Background* Respondents Original sources and inputs Imagination or fact based Reliability * See next slide for details Scenes Number Starting time Location Participants Gadgets and objects Content Type Background or main interest Free or paid Story Picture Basis for the scenario
Proposed structure for a scenario 2/2 Context Project Event Participants Name Age Home location (optional) Occupation Hobbies (optional) Non-human participants Name Interest Home location (optional) Locations Name Features of the location Where does the location belong to? Which locations does it contain? Background Issues Start situation Time Special conditions
Service
Why the concept of a service was chosen to innovation prototyping Focusing on functions and added value instead of just physical gadgets and appearances Emphasizing whole service provision instead of just the physical end device or gadget In mobile and ubicomp environments services are less fixed to certain gadgets Gadget is a tool for service implementation Example: car is a gadget, transport is a service Service is not bound to a certain gadget Service sets constraints to attributes of a gadget Gadget may be used for different services The key of service model lies in binding scenarios and use cases together
Service in innovation prototyping Service refers to the entirety that fulfils user needs in the scenarios. Service includes information on media containers, stakeholders, features, user needs, provision chain etc. In the case of divergent services different manifestations are allowed and even encouraged. Approach and emphasis To discover group of user needs and to structure functions and features Finding realisable entireties that allow experimentation SCENARIO SERVICE Basic music services Purchasing entertainment music Enjoying high quality music Special music services Music samples Tagging music pieces Awakening service USE CASE REALISATION
Service typical sources in innovation prototyping Realizations, use cases -> SERVICES -> scenarios Authored by technology experts, service designers, content providers, operators etc. Grouping of logically connected functions Potential compositions of the capabilities of realizations Describing available functions, features, value and service provision Scenarios -> SERVICES -> use cases, realizations Authored by scenario writers, service designers, user study experts etc. Possible answers to discovered needs, problems and enhancements Potential compositions of needs and functions Describing required functions, features, value and service provision
Proposed structure for a service Functions Name of the service Name Description Description Explanation and user s mental models Task models and metaphors Features Manifestations* Name Stakeholders Descriptions Converted into use case stakeholders Logical structure of the system or can come from use cases Modules Objects Profit model Gadgets, interaction devices, things Additional discussion User needs Authors Description Group member Parts of the scenario Specialization Media container Context E.g. music, text, image Project * See next slide for details Event
Divergent services - motivation Manifestations* Stakeholders Objects User needs Media container Function Features Beyond adaptation Different manifestations of the service for different contexts Not just adaptation but also function and objective change According to the combination of User s context, roles, situations Gadgets, terminals, interfaces Environment capabilities, borrowable devices Networks, utilizing handovers, heterogeneous networks, simultaneous access
Use case
An example of the definitions of a use case Definition: The specification of sequences of actions that a system, subsystem, or class can perform by interacting with outside actors [UML Reference Manual, Rumbaugh,Jacobson, and Booch] Purpose: to define a piece of behaviour of a [system or subsystem or class] without revealing the internal structure of the [system] [UML Reference Manual, Rumbaugh, Jacobson, and Booch]
Use case in innovation prototyping Use case describes typical and reoccurring functions and interfaces of the system and its stakeholders. Approach and emphasis Use cases are components for reuse and they express, suggest and inspire new possibilities. Experts write use cases from different viewpoints, e.g. mobility management, user interface, operator. SCENARIO SERVICE USE CASE Mobile music player: Token provision Music selection Music in networks: Handover decision Mobility management REALISATION
Use case typical sources in innovation prototyping Realizations -> USE CASES -> services, scenarios Authored by technology experts, content providers, operators... What technology and other realizations enable Network technologies, mobility management... Software components, architectures Available content, media carriers, content formats... Interaction devices, user interfaces, terminals... Explaining capabilities and consequences of realizations Scenarios, services -> USE CASES -> realizations Authored by service designers, scenario writers, usability experts... Requirements for the development of realization technologies Services are processed into required use cases Interfaces between users and the system Interfaces between parts of the system Scenarios indicate user needs features and constraints Explaining requirements for realizations
Proposed structure for a use case Name of the use case Part of the scenario(/service) Participants Primary actor Actors Stakeholders Conditions Preconditions Postconditions Flows Basic flow Trigger Alternate flows Authors Name Specialization Additional discussion Context Project Event
Realisation
Realisation in innovation prototyping Realisation means the implemented gadgets, software modules, protocol stacks etc. that are needed for a particular experimentation. Approach and emphasis Realisations are built to establish experiment settings for scenarios and services. E.g. research resources and facilities such as platforms, gadgets and various playgrounds SCENARIO SERVICE USE CASE REALISATION
Realization typical sources in innovation prototyping REALIZATIONS -> use cases, services, scenarios Authored by realization and technology experts (network, software, hardware, content...) Defined according to technological knowledge Software, hardware, network etc. specifications Scenarios, services, use cases -> REALIZATIONS Authored by service designers and technology experts Requirements for realizations are extracted from use cases REALIZATIONS <-> REALIZATIONS Communication between experts of the different disciplines involved in the realization Definition of system s architecture and interfaces in detail
Considerations for a structure of realization Requirements System architecture Specification Hardware Software Network Realizations are modelled according to the practices of each discipline or engineering field Collecting methods for technical reporting and design Sets of common and corresponding models Relations and dependencies between models of different viewpoints
Examples of realisations travelling service Devices Desktop PC PDA Handsfree Architecture of the software system The system s architecture derived from the logical structure Networks GPRS, UMTS, LAN, WLAN,... Manifestations Viewing the time tables Requires big screen Provides a lot of information Viewing next possible routes Needs only a small screen Context aware I m in a hurry Requires voice and very simple small screen Context aware The manifestations share a part of the realizations but they may require some special modules Promising approach: component based architecture
Modelling issues of innovation prototyping
Modelling objectives in innovation prototyping Reaching beyond intuition Colloquial language vs. concept definitions Recognizing professional ontologies Model vs. picture Coherent definitions of core concepts of innovation prototyping Determining the relation to existing alternative concept definitions Basis for capturing and relating viewpoint models The objective is to allow different ontologies and support balanced brokering (instead of aiming at a single common ontology) What kind of structuring and analysis tool the designers need How to gather and relate different viewpoints? How to capture the rationale and dependencies of the design information presented as scenarios, services, use cases and realizations?
Chronological freedom The order of generation of scenarios, services, use cases and realization is not fixed In innovation prototyping the temporal order is free and does not exclude interleaving the work of generating different constituents of the innovation prototype A scenario may be the starting point for design written to reflect the meaning of use cases or services A service is related to several scenarios and vice versa. A use case is related to several services and vice versa. A use case may be extracted from a service or scenario a focus for defining services or scenarios Realizations are separated by use cases from the service and scenarios to avoid technological commitment.
Chronological freedom: Ämppäri 1. The available network was WLAN 2. A colleague (Jari Malinen) proposed MP3 player service 3. Reusing the MART node as a basis for an embedded system 4. Generating (three) music listening scenarios 5. Generating the use cases (providing token, music selection, listening ) 6. Realizing the Ämppäri prototype Scenario (4) Music listening scenarios Service (2) Ämppäri service Use case (5) Ämppäri use cases Realization (1) WLAN (3) MART node (6) Ämppäri prototype
Example of chronological freedom
Problem orientation vs. solution orientation INNOVATION PROTOTYPING Problem orientation Scenarios concretize services to reveal common denominators Scenario REQUIREMENTS ENGINEERING Solution orientation Scenarios and use cases are used for validating the user needs Discovery of service features and design principles is the ultimate goal Use cases are components for reuse and they express, suggest and inspire new possibilities Realizations are built to establish experiment settings for scenarios and services Service Use case Realization A product has to fulfil the user requirements on the service Use cases/scenarios ensure a product matching user needs The right product is the ultimate goal
Balanced brokering of viewpoints Different viewpoints of disciplines, fields etc. Common vs. tailored models Allowing expert ontologies Coherency, dependencies, constraints SCENARIO topic users video scenes storyboard SERVICE functions manifestations features USE CASE Etc. Usability Network Hardware Software name draft details REALIZATION software tools application technologies architecture
Questions
References Carroll: Scenario-Based Design Envisioning Work and Technology in System Development, Wiley & Sons, New York 1995 UML Reference Manual, Rumbaugh,Jacobson, and Booch