Reflection: Teamwork

Coming from a position where I was a one-woman design team, I thought that I would struggle more working on a team for projects at AC4D. While it is true that things can get lost in translation when first learning how to effectively communicate between team members, ultimately, if you can stay open minded and find techniques that work for your team, the benefit of different perspectives on the final result outweigh the struggles endured during the process.

Regardless of the talents you possess, you will always have some gaps and blind spots in abilities and experiences. In order to fill those gaps and see beyond what you know, you have to partner up with others who have different strengths and opinions than you. To achieve something spectacular, you need the ability to build upon ideas. This comes through working on a team.

Below is a small diagram showing the opportunity areas for creative collaboration when working with others. These are the areas that fuel great design and progress.
Collaboration_Diagram-01
This past week, I was under the weather and it was amazing to have teammates who graciously picked up the slack so that I could rest and recover. Since we are able to communicate effectively and have built a foundation of trust, we were able to stay on track and collaborate remotely.

I used to think that I would want to go back to working on my own, but as we have moved into Q2 where we are working on a project on our own, working on a service design project in a team of two and working on a final research project in a team of three, I realize that I really do enjoy working on a team. With a team, you are not limited to your own ideas. Different experiences and backgrounds increase the creativity of individual team members and the group as a whole.

Last week, I got a lot of great feedback on the main flows I’ve been focusing on for the last couple weeks on my Schwab bank app redesign.  The menu buttons were too thick and seemed to contain redundant and unnecessary information.  

Old menu
Misty_OldMenu

New menu
Misty_NewMenu

 

Other feedback from critique was that the grey text spacing was too dark and called attention to page breaks.  

Old Home Page
Misty_Home_grey_spacing

New Home Page
Misty_NewMenu


I refined my old designs and took an iteration to the field

Hamburger menu comment:
“The hamburger menu is redundant. It should just be a back button.”

Misty_SendMoney_hamburger

Although only one individual gave this feedback, comments about back buttons and hamburger menus have come up in class a few times, so I decided to iterate on this and try another version in the field, this time, with the help of html to test using my computer.

New back button option

Misty_DepositCheck_back

Typo comment:
“Ok, so we’ve got a problem here. I put it in for 950 and it says it’s a $100, so that doesn’t make sense.”  

SendMoney_PaymentSummary_wrong

The participant had entered check for $950, but the displayed page read $100.  While this was a pretty easy mistake and fix, it was the main item that confused everyone I tested on.  When plugging my wireframes into html, I’d forgotten to fix a screen that I was testing and the amount of deposit that I asked participants to use didn’t match the amount on the screen.  

 

Here is that correction.
27_Schwab_Checking_Deposit_Complete

“Notify doesn’t specify direction… I’m assuming this is on? Yeah. I don’t know. The right side is off, the other side is on? It usually turns green. I’m gonna assume it’s on.”

13_Schwab_settings_LowBalance_Noficationon

The second biggest point of confusion in my app redesign was that the notification box did not turn from grey to green.  Three people I tested were confused by this.  After receiving this feedback, I researched and found that my formatting was consistent with other apps. My suspicion is that this is an issue of the app being too realistic, since I received a few other comments about color.  I look forward to the group’s feedback on this today.

Mobile Banking App: Iteration & Intuition

Over the past several weeks, we have been learning how to explore and redesign an app through wireframing. Wireframes are a visual display of what a user will interact with on a screen.

We are now at the fourth iteration. To get here, we first explored the current app structure and touchpoints, mapped them in a concept map and then began working through hero flows or typical tasks that users would want to accomplish.

Once these flows were built out, we tested them through “Think Aloud Testing.” This is a very simple method where we ask participants to attempt to accomplish a task while talking through what they are doing. While it is a simple method, it can be hard to keep from helping someone when they are stuck; however, these are the opportunities we are looking for to better improve the user experience. If your product is not intuitive to how someone would think to work through a task, then the process needs to be re-evaluated and redesigned.

In this last round of testing, I took my handy sign and, with the permission of the owner, sat at a coffee shop to intercept participants.

IMG_6875

I gave my participants various tasks to walk through and recorded their comments and issues they encountered. Many of the issues I recorded were that the accordions were hard to understand and areas where users wanted to make edits weren’t active and they didn’t understand why that information was there and not actionable. Below are their comments:

Banking_Wireframes_Iteration4-43 Banking_Wireframes_Iteration4-44
This information informed some of the changes I made. Along with user testing feedback, I also incorporated suggestions proposed during formal critique last Tuesday. Many were similar. Some of the comments were:

  • That the wizard steps at the top of the screen were confusing and didn’t make sense with the arrows
  • That there are too many wizard steps in the Deposit a Check flow and they could all be incorporated on one screen
  • That the accordions were confusing
  • That the Add a Payee and Pay a Bill flows should be broken apart

In this redesign, I decided I needed to expand my tasks and kill some of my darlings, including the Discover circle logo that I had incorporated into the tab bar.

The first step in this redesign was to draw. I started by sketching out new screens with Mate Flair pens. This helped get my ideas down quickly and work through changes without spending precious hours in Illustrator.

IMG_6858

Below are my new flows. You will see that additional screens have been built out and the wizard flows have changed quite a bit. This is my attempt to make the steps more simple so that they are more intuitive and less time consuming for users. I also wanted to incorporate the same sequence of flow through each task so that there is a cohesive feel for each task. In addition, I have added some screens to show what might happen in the unhappy situations like your username and password being wrong or your check photo not reading your endorsement on the back.

Banking_Wireframes_Iteration4-88
Banking_Wireframes_Iteration4-89
Banking_Wireframes_Iteration4-53
Banking_Wireframes_Iteration4-90
Banking_Wireframes_Iteration4-91
Banking_Wireframes_Iteration4-92
Banking_Wireframes_Iteration4-93
Banking_Wireframes_Iteration4-85
We have two more weeks of Q2 which means we have two more iterations to go! Check back next week to see how these new flows do during testing and the additional screens that will be built out.

NFCU v4.1

Last week I wrote about the drastic change I made to my banking app. While the architecture of the app was sound, the visual design and terminology was less than desired. Over the past week I completed the redesign and added an additional task – reoccurring payments.

Changes

Below are two examples of the changes I made to the app.

Visual Design
The biggest change is that the app actually feels like a mobile app and the navigation better aligns with iOS standards. As you can see below, I also removed the color, making it more about representing the intention and interaction rather than the finer visuals elements (e.g. color).

201 v4 Feedback-03

Insufficient Funds
In order to offer an edge case or scenario where the app didn’t work, I created a task where one would attempt to pay a friend more than what was in her checking account.

Recurring Payments
We were asked to add recurring payments to the list of tasks our app is to complete. This task is difficult because there are several steps which complicate the flow of completing a payment. I borrow several ideas from other apps but as you will see below, the task remained a bit confusing.

201 v4 Feedback_2-03

Testing

I interviewed 3 different people in an effort to identify any issues with my redesigned app. By using a talk aloud testing model I identified some glaring issues within several tasks.

One issue that recurred throughout each task was that I had pre-populated several of the fields I had asked them to complete.

“looks as if there is a $3,000 payment”

NumberPad Entry
After typing in the indicated amount, two of the users missed the “done” button and were unsure of how to complete the entry task.

Recurring Payment
There were several issues within the newly created recurring payment task.

While they were to tap the “Manage” tab, two users attempted to access the recurring payment screen by tapping two of the other tab bars and ultimately gave up.

“Now I’m going to hit this again”

When the “Manage” tab was explained one user responded by saying,

“I have no idea what that means”

Additionally, one of the users was confused by the fact that there was both a “Manage” tab button and a “Next” button.

Deposit

When attempting to deposit a check, one person was confused by the fact that the bar that indicated which account the money would be deposited included the account balance.

201 v4 Feedback_3-03

 

Seeking Feedback

This evening, during our critique session, I will be seeking feedback on the changes visual design I have implemented and the from my user testing.

In particular, I am looking to better understand the following.

General Flow of the App

Am I missing any steps or how can i avoid any extraneous steps?
How can I improve the shapes to create more space / make it feel less compressed?
Am i missing anything?
Is it confusing to have the balance information in the “From”?

Recurring Transaction
The recurring transaction seems to be the biggest problem. In particular I will be seeking feedback on

How to best access the recurring setup screen?
Am I adding too much on one page?

Logic and syntax

 

Problem area: Selecting a contact is confusing and doesn’t follow ios conventions

“Oh, uh, I guess I’ll scroll through and find the gas company. Or… no? I… type?”

Screen Shot 2015-12-03 at 5.03.09 PM

Proposed fix: Use screens for selecting contacts in other apps as a guide for finding and editing recipients:Screen Shot 2015-12-03 at 5.04.14 PM

Problem area: Scheduling recurring payments feels cumbersome and out of order.

“This is a monthly payment, so i guess I schedule it for the first? I don’t know. Repeating is below. I’m selecting repeat monthly. Uh… There’s no… options.”Screen Shot 2015-12-03 at 5.07.38 PM

Proposed fix: Make “repeat” a toggle button. Have options for recurring payments show up only when “repeat” is on:Screen Shot 2015-12-03 at 5.08.06 PM

The sending money section has been really making me struggle, and I’ve had the hardest time figuring out why. I feel like I’m on repeat, going over and over one section, unsure if anything is changing or getting any clearer.

This morning, right after sitting with my coffee, I sleepily started making a to do list for the day. I didn’t get very far when I realized I was trying to create this app in a way that didn’t really make sense to me:

 

Screen Shot 2015-12-03 at 5.09.45 PM

Dyslexia isn’t all about spelling. I make connections differently than other people. I see systems differently. This wireframing process has been a process of translation that I am very familiar with in life. I feel like every action I’ve taken is an attempt to say “This makes sense to you, right? The story I’m telling is clear?” It has been very helpful for me to put each piece in order and make some kind of logical sense of it. In thinking about the Send Money section more today, I thought about how I would actually say the proposed action to a person I was paying:

“I’ll send you $100.”

“I’ll send you $100 a week, starting next Friday.”

My previous design read: “I’ll send you $10 on Friday, and then I’ll keep doing that every week, probably also on Friday?” Much less clear!

Going forward, I’m going to think more about the way people speak, the way people think about money in their lives. Banks are are not human. Banks do this function, and that function, and that one over there, all to move money. Banks are centered on money, but need to serve people whose whole identity and self-worth and ability to do what they need are wrapped up in what amounts of money are moving in and out of their bank accounts. Credit cards are much easier to use than they are to manage. If I aim to clarify use of a banking app, do I hide the fine print or blow it up? If I expect a bunch of jargon from my bank, is not having it confusing? If I dread opening my bank app as it is, why am I creating something else that would be tiresome for me to use?

I only know the answer to the last question: I’ve been building this for other people because I know I think differently than the majority of the population. But, trying to develop a worldview that ignores your point of view is ridiculous and impossible. There’s not much more exciting to me than realizing that the way I’m seeing something is a new possibility. I feel like I’m getting to a point in these wireframes where I can start to question each part. So what can I do going forward?

-Think about syntax.

-Recognize my point of view as a strength.

-Consider how I can make this app easier and more appealing, without losing functionality. (Clearly label flows, follow visual conventions for hierarchy, give a few clear options for locating specific functions or flows, eliminate visual noise)

View the full Sending Money Flow here:recurring payments_Artboard 20

Mobile Banking App: Iteration 4

Today, we’re delivering the 4th iteration of our wireframes for the mobile banking apps we’re redesigning. This round, I added recurring payments and built out the screens accessible through the menu. I tested these changes using think aloud testing (previous post on the topic) and made revisions. I’ll be presenting these revisions during critique this evening.

Here’s a full pdf of my latest wireframes:
USBank_Wireframes_Kade_r4.pdf

The first significant change that I made, adding recurring payments, tested surprisingly well. However, something I didn’t expect was that users would encounter difficulty figuring out where to start. Here’s a comparison of the previous version of the Transfer screen to the version I tested:

Screen Shot 2015-12-03 at 6.29.02 PM

Users were getting hung up on my labels and selecting “Scheduled and Recurring Transfers” instead of “Make a Transfer”:

Screen Shot 2015-12-03 at 5.40.48 PM

To attempt to fix this, I reevaluated the labels:

Screen Shot 2015-12-03 at 5.41.10 PM

The next critical incident participants encountered during testing was a silly mistake on my part. Here’s the notifications flow that I presented them with:

Screen Shot 2015-12-03 at 5.41.38 PM

I failed to use the same pattern of confirmation that I had already established in the rest of the app.

Screen Shot 2015-12-03 at 5.42.04 PM

The simple fix:

Screen Shot 2015-12-03 at 5.42.37 PM

While I did test recurring payments, I think I need a focused round of testing on one aspect of them to refine the information presented. That aspect is how I’m showing the user what it means when they select a particular start date for a recurring transaction. Here’s an example:

Screen Shot 2015-12-03 at 6.39.07 PM

The tricky part is when you get into things like quarterly payments starting near the end of the month. The text can get pretty wild and needs to be refined. Currently, this is what I’ve got for something like that:

On the 30th of every third month
starting
September 30, 2015
(If a month has fewer than 30 days, the payment will be posted on the last day of the month)

I’ll be working on that next as well as a long list of outstanding screens and edge cases that I’ve yet to tackle. Wish me luck.

wells fargo mobile app 5.0

I have spent the last couple of weeks catching up on fidelity, layout, and basic flows for my Wells Fargo mobile app. After a couple of reviews, I think that I have landed on a look for the overall app that works well due to predictability, use of small amounts of color to aid in navigation and a white background behind soft black text. After a recent review, I discovered that the size of the art boards if have been using was deceptively large and that I needed to increase my font sizes overall for the readability on an actual screen to work. Each font type was increased around 20% from my previous iteration, which makes it easier to read, but still feels like its somewhat small. The benefit of the smaller text is having more functions on one screen and fewer screens overall.

Pages from art boards 3

Although I have spent time on several major and minor functions within the app, I have selected three experiences to highlight. The first includes the basic function of checking your main account and shifting over to another account. This flow also includes a version of the screen/function used for sorting transactions by type or other desired criteria. I have also included a “transfer between accounts” function that allows users to move money from a wells fargo account to another, or into an account outside of wells fargo. I will be working on the screens/flow of adding an account from outside of wells fargo to the list of available accounts.

check account flow

The next major flow that I have worked through is the mobile deposit function. I have broken this out as a primary function within the account/home screen since this is a function that I believe people want to access quickly.

mobile deposit flow

Finally, I have worked through a version of the transfer money flow, which aims to work similarly to Venmo. Rather than loading someone’s account information into your phone (which seems impossible), this function sends a packaged text message or email to a contact with a secure link to the transferred funds. The person will be able to use this link to deposit the money into an account that they choose. I will be finalizing the screens needed to load information into the “send to” field from your phone contacts.

transfer money flow

I look forward to reformatting my bill payment flow into this new format and expanding the network of accessory functions that I have identified. I will be doing a round of user testing to confirm what is working, and what is not, in the next week.

pk

 

 

V4 | Rapid Ideation Chase Banking App Redesign.

My cohort and I had a critique last week where we pinned wireframes and gave feedback to one another.

Here are the areas of improvement that came to light during class critique last week:

  1. Develop screens such as notifications, error message, over draft. We also call these the “non happy state” pages.
  2. Condense steps for adding reoccurring bill payments – seems like too much work.
  3. Turn the repeating process into a modal rather than individual steps you have to got through.
  4. I got feed back to change from a full month date picker versus a scroll wheel – I decided to keep a month picker and make it better.
    • I did so by graying out the dates that already passed and clearing the rest of the screen.

In addition, I went to a local coffee shop where I asked people to go through the wireframes through the “Think Aloud” method where we ask them to talk through every action. I explain in the beginning that I cannot help them and the only thing I can say is “Please keep talking”. This process can seem weird and a bit frustrating but it’s actually scientifically proven to have no effects on their thinking. It also is incredibly useful for designers because it gives us insight to what they would actually do if they were using the at on a day to day.

Here are the major areas needed for improvement and the solutions I used to address it.

3-03

 

 

This week I also turned actions such as adding a new bill or friend into a modal. A modal is a state outside of the main workflow. So it’s not necessarily less steps but it appears so. I also iterated on reoccurring payments.

2-012-02

This time user testing there was much less hesitation compared to the previous test. It’s affirming to know the flows are making sense to people who don’t spend hours making wireframes. Here are a few areas of confusion where there was some hesitancy or confusion.

This is my first attempt at developing the screens that aren’t in major flows:

2-04

Redesigning an app can seem like an overwhelming daunting task, but after you do it once, you understand how to do it… or at least ways you could make it better. Design is really about iterations rather than being done.  Previous to AC4D, I contemplated going to programs such as GA to get a quicker down and dirty skill set. It’s true, you probably learn a great amount through going through boot camps and gain skills that can be highly profitable. However, that is not the goal of AC4D at all. It’s to make us thinkers who are doers. Because when you’re one without the other.. I believe you’re probably only addressing half the problem.

Click Here for the remainder of my wireframes.

Wireframes: User Testing & Refinement

Wireframes are visual tools to communicate content and user flow in a mobile application or website. I think of them as skeletons because they aren’t meant to define color stories and refined visual design, they are used to lay the foundation for a system.

Over the past 5 weeks I’ve worked to improve the interaction in my mobile banking app. I use USAA’s app weekly and have always been satisfied with the established tools and usability but this wireframe project has forced me to see the app’s inconsistencies and failure points.

The process I went through includes,

  • Concept Mapping the existing system
  • Creating a new Concept Map to reflect a more fluid and cohesive system
  • Storyboarding User Scenarios
  • Drafting initial Wireframes based on user needs and priorities uncovered in Storyboarding and the simplified Concept Map
  • User Testing Wireframes
  • Refining and User Testing again

Below is a quick snapshot of my wireframe evolution beginning with the last tested version followed by the 2nd version. You can see a shift in UI elements like the buttons and hierarchy of labels but you also notice a shift in organization. This week I user tested Version 4 and reported critical fails in the app below.

Version 4:

mobile_banking_wireframes_rnd2-69

 

Version 2:

Mobile_Banking_Prototype_Rnd_1-02

User Testing helps me quickly see the flaws in functionality and pushes forward rapid ideation of the app. It involves sitting down with strangers and asking them to complete several tasks in a prototype of the app. I used Think Aloud which is a more specific testing method that challenges the designer to simply listen and encourage the user to “keep talking” or “think aloud” so that you don’t interrupt their train of thought and you hear as their un-biased perception of each screen and function. Each time a user can’t proceed or attempts the wrong path in a flow it is considered a “critical fail”. I’ve documented 5 critical fails from this week’s user test.

mobile_banking_wireframes_rnd2-67 mobile_banking_wireframes_rnd2-68

After testing and sitting down with a more experienced designer to review my work I,

  • Removed “Accounts” from action bar
  • Replaced the date picker with a calendar
  • Designed 3 alternatives to review with the cohort for adjusting fixed payment amount in bill pay
  • Moved the option to make a one time payment in bill pay

Version 5:

mobile_banking_wireframes_rnd2-65

mobile_banking_wireframes_rnd2-67 mobile_banking_wireframes_rnd2_Artboard 118

check_balance_notificaitons_v5-66

 

Service Design: Refinement and Prototyping

Sophie_Refinement

During our last Service Design class, Celine, Sophie, and I received some great feedback on our customer journey map and vignettes.  We realized that our customer journey map wasn’t calling out artifacts well enough and highlighting the problem statement, so we went back to the drawing board to refine the Pitch & Putt value promise, our problem statement, insights, and design principles.  Below are our revisions.

  • VALUE PROMISE
    Pitch & Putt promises a carefree day of play in beautiful South Austin.
  • PROBLEM STATEMENT
    New customers are afraid to look ignorant and rely on touchpoints and staff to anticipate their needs. When staff doesn’t offer guidance and touch points fail, new patrons don’t ask and remain ignorant.
  • INSIGHTS & DESIGN IMPLICATIONS
    1.  The course map illegibility sends new patrons on a wild goose chase for each new tee.
    Our design will heighten the fidelity and functionality of the course map, creating a fluid experience for first time golfers.

    2.  Golf is an elitist sport. It champions an aura of superiority that intimidates new players. Insufficient and confusing signage paired with overly relied upon, overtaxed staff fuels the feeling of self-doubt in already intimidated first time patrons.
    Our design will provide a cohesive and reliable system of navigation for first time Pitch & Putt patrons.

    3.  Pitch & Putt patrons love to go to bat for the golf course when the city threatens the business but they choose to bring their own beer over purchasing and supporting Pitch & Putt financially.
    Our design will boost awareness and approachability around the Pitch & Putt food and beverage program.

After getting a better handle on these items, we went on to tackle the customer journey, refine our vignettes, and begin prototyping a map for the course, which (due to weather) we will not be able to test until Thursday.  We also have another meeting set up with the Pitch & Putt owner on Thursday, where we will review the vignettes and authorize prototyping a few other design concepts.

The first series of vignettes revolve around the redesign of the map and creating a fluid experience for first time golfers.  Below is a comparison of the old map and our revision, along with vignettes for that flow.

Old Map

before

Map redesign

After map-06

Refined vignettes

Sign

Pitch_Putt_Service_Vignette_1C (1)

Pitch_Putt_Service_Vignettes-03