Open Payments - Report Reviewing Web App Storyboards

The Open Payments project has two components: a web app and a mobile app. In this contest, we're asking you to design storyboards for the web app. The main purpose of the web app is to review and edit payment records that were collected with the mobile app. We have a set of wireframes that we'd like you to follow with some modifications. We also have a UI kit that we'd like you to use for payment fields that occur in several places in the wireframes. The rest of the design decisions are up to you.

Round 1

Submit all screens described below, noting the omissions from the wireframes.

Round 2

Revise and refine your submissions in response to checkpoint feedback.

Functional requirements

We are building a web app with a width of 1000 pixels.

All wireframe screens are required with the exceptions noted below.

There are two user roles:

• report reviewer: views and edits payment records
• administrator: can view and edit payment records; also has administrative powers

In the administrator's screens, we are removing two features:

• "Monitor" tab: delete the "System" sub-tab
• "Setting" tab: delete the whole tab

The fields of the payment form appear in two places:

• detailed payment view: click on the top row of the table in the main view
• advanced search form: click on the "Advanced" button at the right of the basic search form

The user will see the same payment fields in both places. However, the user functions are different.

Some payment fields are set with a dropdown list that looks like this:

"1" = "Covered"

Please remove all quotation marks from the dropdown lists. For example:

1 = Covered

The names of the payment fields appear in a feature just above the table:

• Manage Field Selection: controls the selection of columns visible in the table

In the wireframes, the payment field names shown in the field selector are incorrect. They should match the field names shown in the payment forms.

The profile screens for both user roles must be simplified. Please discard everything except three fields:

• user name
• email address
• password

There should be one button labeled "Change profile". Clicking that button will activate the editing view. Please duplicate the password box in editing mode so that the user has to enter the new password twice. Please add styling for two error conditions:

• passwords don't match
• password is weak

When the user clicks on the "Export Data" button, a small interface appears. Please add a button labeled "Choose export location". That button will activate a standard file picker provided by the operating system, so you don't have to design it.

We are adding one more user feature called annotation. This lets the user add a note to a field shown in the detailed payment view. This note should function like a tool tip. An icon appears next to the field if it is annotated. The user hovers over the icon and a pop-up appears with the full text of the note. By default, fields are not annotated. The user can add a note, edit a note, or delete a note for any field in the editing view of the detailed payment form.

 

Branding and styling requirements

There is no corporate branding. Instead of the title, place the title "Open Payments" in the top left corner. Remove the title from the top right.

The styling of the payment form should be based on the supplied UI kit. As noted above, the fields in the detailed payment view and advanced search form should look somewhat different so that users know whether they're looking at a payment editor or a search form. Therefore, please use the green color palette for the detailed payment view, and use the blue color palette for the advanced search form. For the green palette, use green on white rather than white on green.

For the fields of the detailed payment view, please show six states:

• required field, standard view
• optional field, standard view
• required field, editing view: without focus + with focus (entering data)
• optional field, editing view: without focus + with focus (entering data)

Almost all fields are required, so please don't make them very bold or brightly colored. Required fields should have regular styling. Optional fields should have lighter styling.

In addition, show a design for data validation:

• a border or symbol to indicate that the field contains invalid data
• a pop-up note explaining why data validation failed

The styling of the rest of the web app should be complementary, not identical, to the styling of the payment fields.

In the payment table, please show three kinds of cell styling:

• required cell containing a value: regular styling because this is the expected status
• required cell without a value: draw attention to these fields because they should be corrected
• optional cell: lighter styling; no difference if it contains a value or not

Also show two kinds of row styling:

• complete payment record: all required cells have been filled
• incomplete payment record: some required cells have not been filled

An incomplete payment record is not an error condition. It will occur quite often. Make these rows look different but not distracting.

Our web app must comply with Section 508, which calls for software that accommodates people with disabilities. Areas of low color contrast must be avoided, for example. Please review the attached Section 508 compliance plan.

 

Target audience

The web app will be used by the employees of a healthcare manufacturer.

 

Judging criteria

Completeness: Did you cover all of the requirements?

Aesthetics: Are your storyboards attractive and usable?

 

What to submit

Submission: PNG images of your storyboards.

Source: Source files.

Preview image: 1024 x 1024 screenshot in JPEG or PNG format.

 

Final fixes

You may be asked for minor changes to meet the stated requirements of this contest.