User:Kleinfercher/Specification Abstract Prototype
Specification of Abstract Prototypes[edit]
Intention[edit]
Abstract prototypes should reflect the workflow of a specific process. The aim of an abstract prototype is to define the process a user will run through to achieve a certain goal and/or the systems behaviour. The abstract prototype should not make any suggestions on the user interface. The specification should be abstract enough to describe a process separated from the user interface but still defining all the required characteristics of a certain process.
Basic Concept[edit]
......
The Entities[edit]
- The User
- Scientists
- Librariens
- Administrators
- Metadata Editor
- ...
- The Intention
- User Intention
- What are the specific characteristics of this user group?
- Why does he use the system?
- What is the expected knowledge level?
- This info should be a link to the description in CoLab (TODO).
- Process Intention (process specific)
- Why is the user performing the task?
- What is/are his goals?
- What is his expected outcome?
- What are his expectations of the systems behaviour?
- Action Intention (task specific)
- To achieve a certain goal the user may subdivide the process into several action units. Each action unit is a step further to the expected outcome.
- Why does the user split the process into action units?
- What does he expect this action unit?
- What is the outcome this action unit?
- How does this action unit contribute to the success of the process?
- The Action
To achieve a certain goal the user may subdivide the process into several action units. Each action unit is a step further to the expected outcome.
- The Outcome
As a result of the performed actions the user will see the outcome and can compare his initial intention to the actual outcome. The user will either be satisfied by the outcome or will try the process again with different actions. Can the system detect that the outcome will not be the desired one it should try to give the user hints how to change the actions for a better outcome.
- The System
The system entity should contain information of the internal processing/ handling of the user input.
Additional Blocks[edit]
- Message
- Common: For common feedback to the user
- Error: For error feedback to the user
- Further Expectation
This entity can contain information which is not covert by the original process, like what the user probably wants to do next or what the next system state could be.
The Entities' Attributes[edit]
- Status
Describes the status of the Entity. A selection of: Proposal - In Design - Ready to Implement - Implemented
- Description
- Metadata involved
The Metadata should be a link to a corresponding description in CoLab.
- Action Quantifier
Describes the quantifier of the Entity. A selection of: Nice to have - Mandatory - Important - Very Important
- Action Quantifier Base
Describes the base of the quantification of the Entity. A selection of: User input - Discussed in Group - Own Estimation
Entities Overview[edit]
Example of an Abstract Prototype[edit]
Pros of this Abstract Prototype Specification[edit]
- Specification of the user group
- Described intentions for every step in the process
- Actions/Intentions can be used to define user test
- ...
Cons of this Abstract Prototype Specification[edit]
- Higher amount of work in the early design process
- ...