Once we’ve locked in a set of requirements, we can start designing! We’ll begin by creating a list of use cases, and storyboards (scenarios).
If you haven’t already, check out the other posts in this series: It’s easier than you think, lets build a web app
Our primary user flow will look something like this:
App-Makers employee: logs into the system, creates customers, searches for customers, updates customers, creates email templates, sends emails to groups of customers.
App-Makers Administrator: sets up users of the system.
For each Use Case – we’ll put together a storyboard:
Use Cases | Storyboards |
---|---|
App-Makers employee: Log into the app.
An employee must be registered to use the app. Employees can sign-in using the ‘Log-in’ button. This button should appear on the home page. |
After selecting the Login button:
|
App-Makers employee: Create a Customer
Employees can create a new Customer by using the ‘New Customer’ Button. |
After selecting the ‘New Customer’ button:
|
App-Makers employee: Search for a Customer
Employees can search for a customer by using search filters. |
Select the search input box:
|
App-Makers employee: Update Customer details
Employees can update customer details by selecting a customer record (may require filtering first to locate the correct record). |
Select a Customer record to edit:
|
App-Makers employee: Create an Email Template
Employees can create a new Email Template by using the ‘New Email Template’ Button. |
After selecting the ‘New Email Template’ button:
|
App-Makers employee: Send an Email to a group of Customers
Employees can send an email to a group of customers by selecting the relevant customers and adding them to a group. |
After selecting the ‘New Group Email’ button:
|
Admin: Set up new users
Administrators can add a new employee to the app |
Add a new user in the app. |
Now that we have an idea of how we’d like App-Makers employees to use our app, we can further support the storyboards by developing wire-frames. Storyboards and wire-frames are often created in parallel, and changing one normally leads to changes in the other.
In the next post we’ll create preliminary mockups (wireframes), to get a virtual walk-through of how we want our app to behave.
Functional Interaction Design – Part 6