Develop Proof of Concept Prototype
Document Type: Task Guidelines Document
Version
1.0
Description
First draft
Changed By
Richard
Ashwell
Date
6/4/06
Index
Index .................................................................................................................................................................... 1
1
Inputs .......................................................................................................................................................... 1
2
Outputs ....................................................................................................................................................... 1
3
Overview ..................................................................................................................................................... 1
4
Add Interface Elements .............................................................................................................................. 2
5
Group Interface Elements ........................................................................................................................... 2
6
Partition the Prototype ................................................................................................................................ 2
7
Synchronise with Use Case Flow ............................................................................................................... 2
8
Step Flow Activity Diagram ......................................................................................................................... 3
9
References ................................................................................................................................................. 4
1 Inputs
Stakeholder input
2 Outputs
Proof of Concept Prototype User Interface
3 Overview
The development of a Proof of Concept Prototype User Interface is a vehicle for discovering requirements by
providing the stakeholder/user/process owner with hooks upon which to hang ideas. It should be created
alongside the use case description in a workshop environment. The analyst develops the screen by asking
the stakeholder what they would like to see on it and drawing it in front of the stakeholder.
As interface elements are added to the prototype, they are labelled and organised in a way that will be
intuitive for new users.
If the area available is insufficient, then the prototype will have to be broken down into sub-interfaces and the
interface elements redistributed and re-grouped.
© CRaG Systems 2006
Page 1 of 4
Printed: 28/07/2017 05:26
Develop Proof of Concept Prototype
Document Type: Task Guidelines Document
While the screen is developed the use case document is updated so that the flow of the use case and the
interactions described reflect the design of the screen and vice versa without referring to the technology of the
interface.
Index
4 Add Interface Elements
Fields can be drawn with a simple box, labelled and representative data added. Make sure the box and the
text are sufficiently large to be easily visible. Drop-down boxes can be indicated with a downward facing
triangle. Scroll bars in a large area can be indicated with a long thin rectangle and two triangles. Buttons can
be shown with two concentric boxes and radio buttons with to concentric circles.
5 Group Interface Elements
Group elements together inside a box and add a label if it helps the understanding of the interface. Organise
the elements in such a way that the use of them will follow the flow of the use case in an intuitive way i.e. from
left to right and top to bottom. Leave space for the name of the screen and any company logos.
6 Partition the Prototype
If the interface is too small to fit everything on it, then create sub- interfaces a transfer interface elements to
them. Think about exactly how the sub-interface will be activated and modify the flow of the use case, if
necessary, to include reference to the change of interface. This can often be done by organising the subscreen to implement an alternate flow or a sub-flow.
If the size of the sub-interface is substantial, then it may be worth decomposing the use case on the use case
diagram to reflect the composition of the interface. <<include>> and <<extend>> relationships between the
use cases show whether the sub-interfaces will always be used or optionally based on some condition or
event, such a pressing a button.
7 Synchronise with Use Case Flow
Run through the whole of the use case flow, including all sub-flows and alternate flows. Check that the flow of
the interface follows the flow of the use case and make adjustments until the two are consistent. Do not
explicitly refer to the screen elements in the use case but just to the information being entered. Use labelling
on the interface to ensure that the elements referred to in the use case description are easy to find. This
approach will help to ensure that the interface is intuitive when in use.
© CRaG Systems 2006
Page 2 of 4
Printed: 28/07/2017 05:26
Develop Proof of Concept Prototype
Document Type: Task Guidelines Document
Index
8 Step Flow Activity Diagram
Add Interface Elements
Group Interface Elements
too big?
[no]
[no]
[yes]
Partition the Prototype
Synchronise w ith Use
Case Flow
Complete?
[yes]
© CRaG Systems 2006
Page 3 of 4
Printed: 28/07/2017 05:26
Develop Proof of Concept Prototype
Document Type: Task Guidelines Document
Index
9 References
© CRaG Systems 2006
Page 4 of 4
Printed: 28/07/2017 05:26