Iteration 4 of the Velocity Credit Union App
After getting feedback about Iteration 3 of my Velocity Credit Union (VCU) app , I decided to take a step back by taking a better look at best practices in app design. Accordingly, I bought myself a copy of Web Form Design: Filling in the Blanks by Luke Wrobleswski and settled in for a good read with my pencil ready to mark down the rules of thumb that I had been overlooking while redesigning the Velocity Credit Union (VCU) app.
This was helpful in a variety of ways, but I’ll focus here on the two that had the most influence over how I redesigned my VCU screens for the 4th iteration of the VCU app.
In earlier iterations of my VCU app, I created many success screens, but I hadn’t put a lot of thought into how I should indicate when users had input invalid information into the forms on my app.
As you can see in the screen below (Iteration 3: Invite a Friend Incorrect Inputs, Screen 2), I highlighted the field with an incomplete phone number and called it a day. However, after reading Wroblewski’s writing, I realized that this error message could be much clearer.
For my redesign (see Iteration 4: Invite a Friend to P to P, Screen 8.1), I doubled the visual emphasis on the invalid phone number field by adding a red error message that states, “incomplete phone #.” In addition to drawing the eye more strongly to the problem field, this message more clearly communicates in context what has gone wrong: the phone number the user has input cannot possibly be correct because it is too short. This also implies the fix: the user needs to add the digits she skipped the first time round.
I considered also changing the size of this input field so that only a phone number with the correct number of digits could fit there, but this would have meant that I would have needed to separate out the phone input field from the email address input field. I ultimately decided that it was more important to make it absolutely clear to users that you could use your friend’s email address or phone number to invite them to P to P. Having separate input lines for both with some kind of radio dial (or other means of indicating you only need to enter one piece of information) would have added unnecessary visual clutter for an input that users will already be very familiar with.
Providing a Clear Path to Completion
My art background is in fine art, not graphic design. Consequently, all my prior training emphasized the importance of using the elements of art to achieve balance and coax the viewer’s eye to travel all over the canvas. In web form design, however, the goal is not provoke a leisurely investigation of the intricacies of a painting, but to enable people to accomplish their goals as quickly as possible with as little confusion as possible.
In Iteration 3, my flow for setting up a recurring transfer did not set up a clear path to completion. As you can see in Iteration 3: Transfer Every Month, Screen 1, the checkbox to indicate whether you would like this to be a recurring transfer is at the bottom of the screen, so you have to hunt for it. In the subsequent screens in the flow, you can see that there is no obvious way to take back that choice to tap on the “Make this a recurring transfer” checkbox. In the next screen (Iteration 3: Transfer Every Month, Screen 2), the user is presented with many possible actions. Should she click on the calendar? On the “Transfer every ________” drop down menu? The “on the __________” drop down menu? There is no visual hierarchy to help the user out. Moreover, if the user selects the correct option and taps on the the “Transfer every ________” drop down menu, it overlaps with the “Next” button, creating visual clutter and anxiety about whether you could accidentally hit “Next” before you’re done. Finally, “Next,” which is the default choice people would hopefully select after completing this form, is on the right side of the screen, forcing the user’s gaze to travel all over the place (See Iteration 3: Transfer Every Month, Screen 4).
For my redesign of this flow, I made many changes. First, I put a radio dial input at the top of the screen that defaults to a single transfer but lets the user immediately indicate that they would prefer to do a recurring transfer (See Iteration 4: Transfer Money Every Month, Screen 1). Selecting “recurring transfer” hides the calendar and gives you just one logical next step: to hit the “Transfer Every _________” drop down button (See Iteration 4: Transfer Money Every Month, Screen 2). Your selection there reveals just one new option: to click on a day on the calendar (See Iteration 4: Transfer Money Every Month, Screen 4). There is already a default selection that matches the day the user is filling out this form, but she can select another day in the month. Finally, I moved the “Next” button to the left side of the screen so that the user does not have to read the “Cancel” option before getting to the button they most likely want to use.
My other goal for this week, aside from iterating on my existing screens, was simply to build more screens to get a more comprehensive idea of what my app should look like in all its possible states. I concentrated on building out the Bill Pay section of the VCU app, which brought me up to a total of 191 screens in all my flows. Here are a few more of the new bill pay flows:
This coming week, I plan to tackle the Alerts section of the app, so stay tuned for that in Iteration 5.