Story Board:
<Solution Title>
Month DD, YYYY
Disclaimer: The Graphical User Interface (GUI) designs and business flows included in
this document are intended as a rough-draft proof of concept, and do not represent final
application designs. Their intention is to allow readers to envision many of the known
requirements in the context of GUI mocks or an application prototype, enabling
meaningful discourse with the customer about the application vision. As these GUIs are
reviewed with groups of actual users during iterative feedback sessions, the designs and
contents will change.
Solution Approach/Overview
• <This page will contain a very high level description of the solution, and
may have a high-level architecture (ux architecture) diagram. This is the
top-most picture of what we are building.>
2
Solution Users
There are a number of users of the proposed USACE application.
Primary Users:
The primary users of the system include:
•User Role 1
•User Role 2
•User Role 3
Secondary Users:
There are other users who interact with the system, but are not part of the primary
organization. This include:
•User Role 4
•User Role 5
•User Role N
3
Story Board Parameters
Story Board Parameters
•The purpose for laying out Story Boards is to present a prototype of solution elements
visually to significantly improve the speed and effectiveness of Solution Design – so the
Story Board is intended to result in modifications.
•The User Experience Architecture is focused on creating the underlying virtual
architecture (automated forms/case file organization, inboxes and ad-hoc routing
capabilities), rather than hard-coding complex business routing rules that are likely to
change or require some flexibility. This is a best-practices approach, especially for a first
phase of any solution.
•The GUIs presented herein are early mocks, considered “Concept Mocks” as the main
goal is to identify the right conceptual functionality of the GUI. Final GUI designs will
require multiple SME interaction sessions.
•The GUI mocks do not address every process and sub-process that needs to occur within
the proposed solution, they provide a “style guide” against which more detailed and
robust functionality can be expanded in a conventional manner.
4
<Feature: i.e. Access to the System>
<Screen/Action: i.e.
Login>
Example GUI Mock… preferably with watermark
disclaimer about it being a concept mock…
5
• <Key capability: i.e.
Application will be
accessible using a web
browser via a standard
login window by the
users, who enter user
name and password.>
• <Key capability: i.e. Users
will have role-based
access and permissions,
and possibly different
views of system
information.>
<i.e. Oversight: Prioritization of Projects>
<i.e. Mngt Project
Review>
Example GUI Mock… preferably with watermark
disclaimer about it being a concept mock…
6
• <i.e. Managers would be
able to review all projects
and manage prioritization
of queues.>
• <i.e. Need to view by
project or by owner.>
• <i.e. Managers also have
access to additional
information about each
structure from system x.>
• <i.e. Projects can be
assigned a Generic Budget
Estimate, and other
properties (meta data).>
<Key Feature: i.e. Oversight: Creating Study Plans>
<i.e. Study Plan
Completion & Review>
Example GUI Mock… preferably with watermark
disclaimer about it being a concept mock…
7
• <i.e. Once the users have
coordinated and agree on a
xyz Plan, a Review would
occur before making the
final submission for
funding.>
• <i.e. Forms would allow for
online signature and
routing.>
<i.e. Oversight: Executing ABC Plans>
<i.e. Coordination with
Organization B>
Example GUI Mock… preferably with watermark
disclaimer about it being a concept mock…
8
• <i.e. By using an
infrastructure of inboxes, a
project can be flagged for
review, or forms passed
among reviewers, as one
avenue to manage
coordination between
organizations.>
• <i.e. Additionally, a
potential request for
information from User D
could exist, allowing the key
user to build the “case file”
for each project.>
Questions:
.
Document Acceptance (may not be needed)
The following identifies the minimum list of individuals required to provide acceptance of this
document.
The top-level customer requirements as stated in this document are hereby acknowledged,
approved and accepted as delivering and satisfying the concept of a Storyboard and UI Mock Ups
document for the project.
Role
Name of Acceptor, Acceptance Date and
Method
<Customer > Project Manager
Name
<Partner> Project Manager
Name
EIM Project Manager
Name
10