Reviving the Chase Mobile Banking wireframes

After about two months of collecting dust in far-far away folders on my laptop, Chase Mobile Banking wireframes got their second life this past week!

This time, we are going to see how much it costs to bring this app to life. To accomplish that, I have prepared the wireframes in a format that I thought would be most helpful for the developer who would do the estimation… I’ve made sure everything is good with Sketch, and have organized the wireframes in Invision, and eventually met with the developer to get a rough estimation.

Before the meeting, I felt pretty good about the wireframes. I thought they looked decent and make a lot of sense. To be honest, I was quite proud of my achievement in Q2, especially taking into account the fact that we had two other very intensive classes going on.

Screen Shot 2018-03-19 at 9.30.45 PM

I had enough time to forget that the wireframes weren’t *that* good. But the meeting with the developer opened my eyes to how much was missing and how many questions weren’t answered.

Here’s something that I thought was very important about the way I approach this class. I want to ensure that anything I do and learn should help potentially working with remote developers. That’s why I decided to take a risk and try to organize all screens and detailed specifications in Invision. I already used this app for user testing of these same wireframes, and it was the time to explore the capabilities of the app for remote collaboration.

I started with making connections between the screens, adding what is called “hot spots” (clickable areas) – a very long and boring process, but so insightful! I realized that so many buttons still don’t lead anywhere. So many pages are missing. Sometimes, it was not clear where a “Back” or a “Cancel” button would lead. That really helped to do some micro-iterations on certain screens.

Here is my Invision prototype if you are curious!

During one-hour-long meeting with Mark Phillips, owner of “Are You Watching This?”, we were able to walk through all existing flows, cover some of them in much detail, and just slightly touched others. Nothing really surprised me in the estimation. But I was finally hit by the realization that this is a long, very long process to develop a comprehensive set of wireframes for a Mobile Bank App. According to his estimate the app will take him about 8 months to develop.

Screen Shot 2018-03-19 at 9.28.51 PM

The process of estimation I had was not as efficient as it could be. I wish I had all the specifications and components list completely done by the meeting with the developer! Not necessary to show it all to him (we only had one hour together), but to minimize the number of questions I didn’t have an answer on. The lesson is learned. But then, it’s clear that the more often we meet, the easier it is to align with the direction and ensure I prepare everything the developer would need from me going forward.

I am looking forward to getting to a comprehensive deliverable for the developer this week and solidifying the estimate.

Building a Service Blueprint for KeyUp

The last week of Q3 approaches, but we (Adam, Mary Hannah, and Mariangela) continue to validate our service idea: KeyUp, a digital solution that aims to connect young adults to training programs and supporting services, with the mission to have them attain a well-paid, mid-skill level career, improve their quality of life, and subsequently, increase their level of civic participation.

While conducting experiments, we finished putting together our website (check it out!  https://www.keyup.org/) which we have shown to a couple of young adults from whom we gathered and implemented feedback. We’ve also been spending some time on building our online presence on Instagram (https://www.instagram.com/keyupaustin/)  and Facebook (coming soon).

Screen Shot 2018-02-16 at 8.36.23 PM
keyup.org

Hypotheses

This week, these were the hypotheses we tested in order to de-risk the development of our service:

  • If we manage to get 30 young adults interested in our product, we will get 5 people to participate in co-creating paper prototypes for our digital solution.
  • If we pitch our service idea to 4 stakeholders working in community outreach and also those that specialize in connecting individuals to job opportunities, they will agree to support us in our endeavor.
  • If we create social media accounts on Facebook and Instagram, we will be able to attract attention from key target audiences.

Experiment 1: Testing platform UI

The digital piece of our solution will be the main point of interaction between young adults and our service, so we wanted to make sure that the interface efficiently communicated information that is of relevance to them. In order to do this we created a paper prototype that we intended to use in a co-creation activity with young adults.

Success criteria:

We will get the contact information of 30 young adults, of whom five people will be willing to attend a participatory activity.

Actual results:
We only managed to get 3 individuals to agree to do a participatory research activity.
Reaching out to young adults that will actually follow up with us continues to be a challenge.

Experiment 2: Creating partnership with stakeholders

By speaking to an array of stakeholders, experts in the areas of continuing education and supporting services, we hoped to confirm that they supported and would use an app that would connect young adults with training programs and services to get them into middle skills jobs.

Success criteria:

We talked to four stakeholders hoping that we could detect opportunity areas to partner with them.

Actual results:

The services that we’ve reached out to have been extremely responsive and have started introducing us to other interested parties. We have now had meetings or scheduled meeting with almost every stakeholder that we identified or that another stakeholder has recommended we look into, indicating that we are approaching a comprehensive understanding of the actors in the youth workforce space. Our conclusion as a result of these interviews is that despite their active efforts to coordinate with each other, many of these communities and programs are working in silos. No one we spoke with had a list of all training programs and services available in Austin for people trying to reach middle-skill jobs, and few would even hazard guesses. Therefore, KeyUp would be filling a gap in the efforts of current stakeholders.

Next steps

UI paper prototyping

This week we focused on the researching and refining content for our digital solution.
In order to prove validation of our solution, we need to be sure that the information that we’re providing actually is valuable to the young adults we’re trying to connect to programs and services that will guide them through a sea of educational options.

After having put together a first paper UI kit in order to test it, we realized that we were dealing with an extensive amount of data about existing training programs, careers, and supporting services. The challenge lies in the fact that we can’t just google training programs and make a list of our findings; we need to actually do the due diligence of scrubbing data and provide information about programs that are legitimate and have a good reputation.

IMG_0723
Paper prototype for UI participatory activity

Pivot: We decided to choose three industries that we would like to be “subject matter experts” about so that we’ll be able to provide the best information out there for prospective users. These areas are: health care, tech, and skilled trade jobs, all industries identified as well-paying and high growth in Austin.

Service blueprint

IMG_8305
KeyUp potential end users

After the research we conducted, we realized that there are at least four types of users that could interact with our service. We decided to focus on the user that is in an “exploratory” phase while searching for jobs and that suddenly stumbles upon “KeyUp” through Google or social media. The reason why we decided to choose this user is because they will be following the full KeyUp journey from beginning to end.

Screen Shot 2018-02-16 at 8.29.25 PM
Iterations of Service Blueprints

We will continue working on defining what our service consists of by iterating on our service blueprint as we keep on conducting interviews with stakeholders and potential end users. We’ll use our service blueprint to prompt conversation about our service in order to receive feedback and refine our solution.

Screen Shot 2018-02-16 at 9.01.19 PM
Last iteration of Service Blueprint

 

How I built a system to help users save money

This week, I had a whole new experience when the bank I have been building wireframes for chose to integrate a new core product as fast as possible. The new product has four key features: user financial trends, analysis of specific transactions to see if they are historically anomalous, a “what-if” financial modeling system, and an ability to figure out when it is safe to spend at any time. The last time I wrote, I said I was going to build out my screens, do usability testing with 8-10 people, and build out my flows. Though I did accomplish this, I am going to focus on how I developed the new product, how I tested it, what I learned, and present my new screens.

In this week’s post, I am going to discuss

  • my process,
  • revised information architecture concept model,
  • testing,
  • testing outcomes,
  • screens and
  • next steps.

My Process

Since the new product I have been tasked to incorporate in the mobile banking application is about financial analysis, I decided that its fundamental purpose is to help a customer save. Thus, at its core, the mission of the new product is to help users save money. After doing some background research, I found out that Americans are not saving a lot of money at all. To me, this means the product should help Americans move from living paycheck-to-paycheck to a state of financial stability which I will define as having saved three times the amount of money you spend each month.

So now, I have framed the challenge in a new way. I am not longer trying to fit four different products into my banking application. Instead, I am going to determine how can a banking application help a financially illiterate person gain the confidence to begin saving their money and get out of the situation where they are living from paycheck to paycheck.

This led me to ask questions like, “Why don’t people save money? What are barriers to financial planning? How can a mobile application support decisions that lead to long term saving?”. There are products out there that help a user budget. So why isn’t America jumping on board and living within their means, putting away a little bit every month, learning to invest and take on other habits that will lead to long term financial stability? Of course, there are many factors a banking application has no control over. It can’t change the very real circumstances that Americans live everyday. What can it control? How can it help users to change their behavior in simple ways?

Thus, I started to reframe the challenge again. I asked myself, “How can the banking application create a situation in which the user feels like saving’s support is invited? What circumstances would a user be in, in which a he or she would more likely value a little nudge that would lead to better financial health?” This was a fruitful line of questioning because I recognized that though a user may intellectually recognize that saving money is better, he or she may not emotionally be able to grasp it. There are many barriers to behavior change and there’s no way a banking application can help a user to become better at saving if it does not take those into account.

To help me systematically think this challenge through, I built a service blueprint using sticking notes. Along the vertical axis in purple sticky notes, I wrote the headings: triggers (data), system triggers, triggers (user), system’s response, customer service response, and next steps. By triggers (data), I am referring to all the data a banking application can track including frequency of a kind of purchase, location of purchases, the collective spending habits of users in a similar location and income bracket, and individual user spending habits. By system’s response, I mean what is the frequency, quantity or time that will lead to a moment in time a user may want help. By triggers (user), I mean what will the user be doing in the real world as well as in the banking application when the system is stepping in. By system’s response, I mean what will the system say to invite the user into the interaction. The rest of the terms are about how the user will go about accomplishing the new goal instantiated by the system’s response.

For example:

Triggers (data) – system is tracking how much the user is typically earning each month (biweekly paycheck) as well as when bills are usually paid

System triggers – a user does not get a new paycheck for 1 month

Trigger (user) – user logs in to the banking application

System’s response – a modal pops up and makes a friendly comment in which it says it has noticed that something isn’t okay and ask if the user would like some help figuring out how to make sure they have enough savings to pay a bill coming up in two weeks. Sign up for our new service.

User response – sign up later or sign up now.

serviceblueprint
A visual representation of how I thought systematically thought about Safe to spend

In the end, I built out the product with a few use cases in mind. I specifically focused on a person who is living paycheck-to-paycheck. I wrote a few stories to figure out what the user may be doing and what his or her goal may be. I used this to help me revise my information architecture map. Then, I sketched my wireframes and built them. Finally, I ventured out into the field to do my usability testing.

Revised information architecture map

In order to revise my information architecture map, I first tried to incorporate feedback I’ve gotten that the original map was unsightly and seemingly disorganized. Though I’ve used the map for my own sensemaking, it also needs to be something I could hand off to a developer so that way they can understand the lay of the land, so to speak. After I revised its appearance for clarity, I added in the new feature I developed called Safe to Spend.

Revised information architecture map
Revised information architecture map

Testing

I attempted two forms of usability testing this week. First, I tried usability testing as I have always done. This was super pertinent since I am just at the beginning stages of building up my idea. It is important to get other people’s perspectives – to see if they can make sense of the flows. Getting to hear someone think aloud as they attempted to figure out the new feature, I learned about what I did not consider, about how I displayed information, and the copy I wrote. Getting a handful of people to test my screens, I get to learn about where I need to make design considerations in a rapid and cheap way. I was able to get really actionable feedback.

A user tests Safe to spend with a paper prototype
A user tests Safe to spend with a paper prototype

 

I learned a lot of important ways to revise. I chose the top three. They are visualized below in the next section.

The second way I tested my application was through cognitive walkthrough. This involves trying to use the application from the perspective of a first time user to try and understand if he or she can achieve their goal. I tried to figure out if the user wants to save money, would they understand how to move their way through Safe to spend. You can see how I visualized this process below. Using this method, I was able to reflect on cases that I had not previously considered including user states of mind and cash flow.

Cognitive walkthrough visualization
Cognitive walkthrough visualization

Testing outcomes

Below, I have visualized the top three errors I revised in my screens.

Test documentation 5-01 Test documentation 5-02

Test documentation 5-03

Safe to spend screens

Below are the Safe to spend screens. I labelled each flow with the task that it accomplishes plus indicating which of the requested features it addresses.

A flow for how a user turns on Safe to spend
A flow for how a user turns on Safe to spend
What if I want to cut down on spending - flow
What if I want to cut down on spending – flow

 

What if I delete subscriptions? - flow
What if I delete subscriptions? – flow
What if I spend less frequently - flow
What if I spend less frequently – flow
Get a snapshot of my trends- flow
Get a snapshot of my trends- flow
Intercept messages that tell me when I've spent more than usual, can save or how many more times I can do something during the week.
Intercept messages that tell me when I’ve spent more than usual, can save or how many more times I can do something during the week.
What happens when the system doesn't recognize your transaction
What happens when the system doesn’t recognize your transaction

Next steps

For my next steps, I want to develop my banking mobile app into it is fully complete, revise my information architecture map so that it is both clear and consistent, as well as build out the safe to spend feature. My hope is to create a full product that I can use in my portfolio.

Wireframing: Iterating on visual design and workflow

This week, I took what I learned from last week’s critique and applied the numerous suggestions to my wireframes. In last week’s blogpost, I discussed how I’ve been evolving my visual design skills. I went deeper into this aspect of my flows as I tried to also figure out how to make my workflow more efficient. I also said that I would build out more flows that a user would experience and see if there would be any new features I would want to add. I added flows but did not add in any features.

In this week’s post, I am going to discuss

  • Improving visual design
  • Revising wireframes
  • Improving workflow
  • Revised wireframes
  • Next steps

Improving visual design

As I discussed last week, I am not a trained visual designer. I am learning one significant aspect of visual design is training my eye to see details. Before entering AC4D, I rarely spent time thinking about how to evaluate graphics from the standpoint of readability and accessibility. I certainly didn’t ask myself how one document may be more attractive than another. Since practicing this kind of detailed evaluation, I have only begun to realize what I don’t know and that the most valuable way to getting better is by getting feedback from others (especially those who have more training). I am hoping that I start to develop my own aesthetic so that when I leave the program I can be more independent and assertive when it comes to my own graphic design decisions. For now, I am working at a snail’s pace trying to modify what were once ugly screens to slightly higher fidelity screens.

This week, I spent hours modifying old screens so that they are less “chunky” and “amateurish”. Below is an example of how I modified the hamburger menu so that it looks more realistic. You will notice that in the new screen the typeface is less harsh, there is more white space, and that there are clear breaks between categories represented by faint lines.

newvsold-02

You can see another example below. It is an example from the Bill Pay flow. I made all elements left aligned, the typeface smaller and as well as changed the text from a regular weight to a light weight. I am beginning to understand the subtle grace a wireframe (or document or form…) one can develop by using weight and size.

newvsold-01I also made my wireframes more consistent by making sure that all buttons looked the same, affordances were set up in the same manner from screen to screen and all hamburger menus were on the right hand side of a screen.

Revising wireframes

In addition to modifying the visual design of my screens, I revised the Alert flow based on user feedback from last week’s testing. I have been challenged by the alerts flow and seem never to get it right. I will be testing this flow during critique (again) as well as during usability testing.

Test documentation 5-01

 

Improving workflow

A huge part of my struggle this quarter has been getting better at visual design. Another is being able to work more efficiently and accurately. This week I was more intentional about trying to improve my workflow. I spent time creating groups, symbols and writing down key information that I needed to repeat across each flow. I also tried to time box more effectively. Honestly, I am not sure how much this all helped because in the end, I found out that Sketch, the application I use for wireframe design, is a little buggy and when you copy and paste symbols, it will make a new symbol instead of copying the instance. This then sent me on a rabbit hole to try to fix the work I tried at first. Though I have been told that symbols ultimately will slow down a team of designers, I want to figure out how to use them because it takes so much time to make one small change to each screen!

Revised screens

Below, you can see my revised screens as well as the new flows I have added.

Login flow
Login flow
Bill pay flow
Bill pay flow
View bill flow
View bill flow
Check balance flow
Check balance flow
Alerts flow
Alerts flow
Deposit a check flow
Deposit a check flow
Quick pay flow
Quick pay flow
Transfer flow
Transfer flow
Settings flow
Settings flow

Next steps

Next week, I plan to do usability testing with twice as many people (8-10) so that I can make up for not doing it this week. I also plan to add into in the edge cases and error screens.

 

Service Design: CRAFTing a Customer Journey

For Service Design, our team (Mariangela, Adam, and Mary Hannah) has been working with a local pay-by-the-hour craft supply business called (fittingly enough) CRAFT. This has meant that we have gotten the wonderful opportunity to interview a bunch of CRAFT patrons and do a little crafting of our own. Service Design is the exactly that, the design of services.

IMG_0636

In reference to CRAFT, it is the creation and orchestration of all the touch-points within CRAFT to act as a single entity in order to achieve the ultimate creative experience for each guest. Our process started with researching what the current state of a guest’s experience at CRAFT is. Next, we did research with the employees of CRAFT to understand the work they do, what they hope CRAFTing guests experience, and any barriers to achieving this ideal. To learn more about how we did each, we have included the introductions to our research plans and where we currently are in our process.

Introductions to our research plans

What is the current state of a guest’s experience at CRAFT?

Focus Statement

We aim to learn how customers currently experience CRAFT. We will use this research to seek opportunities within the service experience that will lead to greater value for the user and the business owner.

Research Objectives

Our goals are to:– Understand the customer’s perception of value, service, and flow from start to finish of the customer journey
– Understand factors that contribute to decision making throughout the customer experience, from start to finish as defined by the customers
– Understand types of people who use CRAFT, define how they identify as creators, and how the service integrates into their making process
– Understand what makes an ideal crafting experience
– Uncover all potential touch points throughout the customer journey

Research Activities

Front of House (FOH) WalkthroughDescription For each walkthrough, members of the design team will accompany a recruited participant from the moment a customer drives into the lot of CRAFT to the moment she leaves. After completing the walkthrough, we will walk with our participants to a nearby coffeehouse to do the Participatory Timeline activity (see below).  Secret ShoppersDescription We will ask 2 secret shoppers to walk through CRAFT  and take at least 15 photos as they go of the following things: – Things that catch your eye
– Moments you make decisions to explore a crafting material or not
– Things you like (fun, interesting, easy, etc.)
– Things you don’t like (confusing, annoying, boring, etc.)
– Things you think should be improved
– Things you needed help onAfter these secret shoppers complete their CRAFT experience, we will move to a nearby coffee house and review their photos with them. We will also have our secret shoppers create a map showing where they moved in CRAFT. Then we will move on to the Participatory Timeline activity (see below).

Participatory Timeline

DescriptionFor this activity, we will prompt our participants to create both actual and idealized timelines of their experiences at CRAFT. First, our participants will write or draw out a diagram of their actual activities in CRAFT, starting at the end of their time there and then working their way back to their perceived beginning of the experience CRAFT offers.
Then for the idealized timeline, for each step mentioned in the previous activity, our participants will select two images from a predetermined diverse array provided by us. They will pick one image that corresponds to their ideal experience of that step and then another that corresponds to an imperfect experience of that step, and then on to the next step, for which they will select another two images, and so on.

 

What do employees do at CRAFT and what do they hope for their clients?

Focus Statement

We have two focal points as we research CRAFT’s back of house. First, we want to understand how CRAFT’s owner, employee, and workshop facilitators spend their time at CRAFT. Second, we want to build a map of a perceived customer journey from the point of view of the workers at CRAFT. We will use this research so that we can find opportunities for innovation, where the perceived customer journey and the as-is journey do not match.

Research Objectives

Our goals are to:– Understand the owner’s, employee’s, and workshop facilitators’ perceptions of the value, service, and flow from start to finish of the customer journey
– Understand the culture of CRAFT among its employees
– Understand the owner’s, employee’s, and workshop facilitators’ roles and – responsibilities, both as stated and as actually lived
– Understand the actual and ideal work experiences of the owner, employee, and workshop facilitators at CRAFT
– Identify pain points encountered by the owner, employee, and workshop facilitators working at CRAFTResearch ActivitiesBack of House (BOH) Contextual InquiryDescription For each inquiry, members of the design team will accompany an employee as they carry out their work. We will inquire about motivations, values, and their personal history with CRAFT.Participatory TimelineDescriptionFor this activity, we will prompt our participants to create both actual and idealized timelines of their experiences at CRAFT. First, our participants will write or draw out a diagram of their actual activities in CRAFT, starting at the point of time when we are seeing them. We will ask them to work backwards and forwards through the their day. Then for the idealized timeline, for each step mentioned in the previous activity, our participants will select two images from a predetermined diverse array provided by us. They will pick one image that corresponds to their ideal experience of that step and then another that corresponds to an imperfect experience of that step, and then on to the next step, for which they will select another two images, and so on.
Customer Journey MapsDescription We will ask our contextual inquiry participants to complete customer journey maps that show all the activities customers undertake while at CRAFT. Starting from asking why customers walk through the door all the way through to the end of their interactions with employees, we will ask our participants to map out all the steps CRAFT customers go through. As they go, we will ask “What’s the best thing that has ever happened at this step?” and “What’s the worst thing that has ever happened at this step?” to elicit stories about each step.

Where we are in our process

We are currently unpacking our research by building a customer journey map.

IMG_0283 (1)

We are building this map so we can make the customer journey tangible so that we may uncover patterns and breakdowns. We will use this map to help us ideate and then prototype solutions.

We are hoping to innovate upon CRAFT’s current guest experience in order to fulfill their value proposition. Ultimately, our goal is to help ensure that each guest is able to walk away feeling that they’ve had a valuable experience, one that is seamless and connected wherein guests are able to spread the story of CRAFT to potential future customers. Thus, increasing CRAFT’s bottom line.

Revising The App. Users Are The Best Judges.

During the past week, I performed user testing with 6 users significantly varying in age and background. Based on the feedback, I’ve updated the wireframes that I created previously, and also updated the navigation concept map I initially created 2 weeks ago.

User Testing

My user testing included 6 people, in age ranging from 13 to 48. I was lucky to get a teenager — who is a very confident user of a smartphone, but he has never deal with a bank application. It showed me how a person with no previous experience in the industry and with no expectations like “in my usual mobile bank application this function is here and acts that way” deals with the system.

IMG_0232

Why 6 users? The research has shown that 5 to 10 users is enough to discover most usability problems; I’m going to be sticking to ~6-8 people at a time to apply the limited amount of time we have in our hands most efficiently, extracting the most value out of it.

IMAGE 2017-11-13 23:06:41

As a result of User Testing, I’ve discovered three main problems:

Problem #1.

When people were tasked to deposit a check into a CPC Checking Account, first thing they do is they try to tap on that Checking Account from the main screen of the application (which is the “Accounts” tab) – all 6 people did that. One other person has also tried to open Activities to do that.

“I think that normally I can go in there because that’s how… my Wells Fargo works.”

I felt like I was testing the tool and the approach and not necessarily the flow or the scenario of the app usage. People might have considered the task as a hint, and hearing the word “CPC Checking Account” and seeing it on the screen, they immediately tried to tap on it without looking much at anything, even though the task was in depositing a check, and the name of the checking account didn’t really matter.

Either way, I saw that it’s some valuable observation and I decided to have a way to “Move Money” through an Account page. The only difference going to be that the opened account is going to be pre-chosen in the proper fields (“From” for transfers, “To” for check deposit, etc).

2017-11-13 22.52.54

It’s worth noting that people were learning really, really fast. On the second assignment, they all knew they needed to tap “Move Money” tab and go from there. For the next User Testing I’ll change the order of tasks and will add other options that are outside of the “Move Money” tab to see if the learning has lasting effect. While I plan on testing it on new users, it might be interesting to see if the same users have remembered what they’re supposed to do.

Many applications are non obvious these days. Snapchat is an extreme example. Applications like Instagram and Facebook has a bottom tab bar (similar to my application) that, from the first try, is not really obvious – you can’t tell what’s behind the options. However, first time you try it, it becomes obvious and not a problem for further use. I feel like it’s the same with the banking app that you use often. I try to stick to iOS conventions to make sure application looks familiar to iOS users, and if there’s something non-obvious, it should not be something that is non-obvious every time. Users should be able to learn it very, very easily.

Getting back to the problem, it can also be simply a visual design problem. The buttons on the bottom aren’t sticking out enough. They are of a regular size for iOS tab bar and are similarly used in hundreds of popular applications, however there can be a way to emphasize it with color and icons, maybe using Chase color styling. Regardless, as mentioned above, having access to “Move Money” from the Account page is still very useful because that’s also how many people think – instead of starting a thought process from the actions, they start thinking from the account they want to perform the action on.

Problem #2.

After completing a task, users saw an overlay with “Your transaction is successfully complete” which was, in my prototype, an “exit” back to the homepage (Accounts page). However, it was not obvious for users that they need to tap it. They tried to tap outside of the overlay in free space or on one of the tabs at the bottom or on the “Transfer Money” button again, but not on the overlay as I planned.

“I don’t understand how to get off of this screen… I know I need to go there but how? Yeah, see, that’s obviously… these buttons should always work basically, you should always be able to get through”

Even though some people mentioned that they very like big blue overlay telling them that transaction is successfully complete and found it’s easy to read this overlay as “exit” sign, for most of my participants it wasn’t so obvious. In this iteration I’ll tried to make it is more clear by having a button that simply says “OK”.

2017-11-13 22.52.46

Problem #3.

On the Calendar screen where you are supposed to click on a date, today’s date is highlighted with blue (and is chosen by default), people still click on it (sometimes multiple times) even though there is no action to be taken and you can just move forward.

“I would expect something like “Today” button here or something like that.”

“That is another thing. I hate when it’s always this “Done” option. Once you clicked a date or clicked under it should just go.”

I realized that “TODAY” is actually such a popular “Date” for any kind of transaction you want to do that it makes sense to just have it default on the transaction information screen, so that people don’t even have to click on it to get to the Calendar screen in the first place. And if they do want to change it then (want to set another date), clicking on dates outside of Today is what they will do and it will be actionable.

2017-11-13 22.53.06

Regarding the note that you have to click Done after choosing a date, I think it is still important to have it the way it is, because users may want to “tap around” on the page and having it jump back to the Transfer info page with every tap would be very annoying. I will keep an eye on it in next user testings.

=========

Even though I said there are 3 problems, there are a couple of problems with the testing tool and approach that I used, and not with the application design itself:

Problem #4.

When users were going through depositing a check, they did not know what to do. In the prototype, they just needed to click on the Image area that it would just automatically get filled out without really taking a picture (Invision prototyping does not allow taking pictures anyway). But users were wondering: “I don’t have a check, what should I take a picture of?”.

“We just don’t have a physical check that’s why I’m not doing it.”

2017-11-13 22.58.42

This seemed like a testing approach problem and an immersion problem. Next user testing, I’ll make sure to have a check prepared with me so that users feel confident they can go through the flow.

Problem #5.

I only prototyped the “perfect plan” screen flow. But all screens should ideally be accessible so that users can surf around, get lost, try everything they want to try.

“I know where I need to go I just can’t get there.”

=========

With all preparation and technical issues for all 3 tasks the testing were lasting from 3:04 to 7:29 with an average time of 4:55.

The System Usability Scale (SUS) score has calculated to the following numbers:

  • Average: 72.10
  • Median: 81.25

One user was exceptionally unhappy with the fact that you couldn’t just surf around like in the real application and the prototype was restricted to the “perfect plan” (and that overall it was a prototype, and not a real functioning application) – my guess is that it was the user who gave an overall very low score, which lowered the Average score significantly. I will work on finding ways to communicate what you can and cannot do with the Invision prototype so that there are no wrong expectations.

Next time I will try include people older than 65 into the user testing to find out how easy the application is for people who aren’t afraid of banking in general, but might not be comfortable specifically with technologies and smartphones.

Lastly, below is the updated concept map that reflects the current application structure, and also includes further expansion and features that are not fully designed yet.

New Navigation Concept Map

Click to enlarge. Save the photo on your computer to see in full detail.

Iterations!

Iterating to awesome: How to do Usability Testing

In this week’s blogpost, I am going to describe my process for iterating on my Navigation and Information Architecture Map and the wireframes for the TD Mobile Banking App. This builds on two previous blog posts; the first was on my process for creating the original concept map and the second was for my process on developing the wireframes.

In this post, I am going to discuss and present:

  • Usability testing
  • Revising the Navigation and Information Architecture Map
  • Revised wireframes
  • Next steps

Usability Testing

Last week, I developed my wireframes using a process that hinged on imagining a flow through the application that would help well-defined characters achieve a goal. This week, I set out to see if real people could achieve those goals. To do this, I first created a digital prototype using Sketch and a plugin called Craft that links my wireframes to Envision. Then, I went out into the field to find at least five willing participants, primarily in local cafes. Last, I looked back at the data I had accumulated and found the top three design issues that I wanted to revise.

I knew that in order to get feedback on the usability of my application, I would need to present participants with a low fidelity prototype. One recommendation I received was to use a paper prototype. However, I decided to try and learn how to create a digital prototype since I know that people in industry do this. The process was arduous. It made me think more about each step of a user’s flow. Questions like, “What will happen if a user does not fill in a field properly?” or “What sequence of screen would a user most naturally flow?” came up.  I also had to learn the idiosyncrasies and limitations of Craft and Envision. I thought that the time spent on this part of the prototype development was worthwhile because I thought that organizing a paper prototype would be overly onerous, especially when working with participants in real time.

Once the digital prototype was developed, I set out into the field to find willing participants. I had six predetermined tasks: checking a balance, transferring funds to an external account, paying a friend, setting up a new alert, paying a bill, and depositing a check. I wrote each of these tasks down on a separate sheet of paper so I could hand them off during the testing session.

I also prepared myself to follow the Think Aloud Protocol. The steps in the protocol involve first, telling the participant what they are about to do and that once testing begins, all I can say is, “Please keep talking.” I tell the participants that I want to hear what they are thinking as they attempt the tasks written on the sheet of paper. The Think Aloud Protocol is based on a theory that people can explain how they solve problems and that though it will slow down task completion, won’t have an impact on potential task completion. As participants will work through the task, I will take notes and record what they say so I have a reference for later synthesis. I also had my participants fill out a SUS score which is their rating of the application flows. My hope is that as I iterate on the wireframes, the score will go up.

A participant tests the digital prototype on his mobile phone
A participant tests the digital prototype on his mobile phone

A key takeaway from usability testing with a digital product was that a lot of the feedback I got was actually about the limitations of Envision. People got stuck on different screens because Envision is limited in how systematically accurate a user can interact with the product. I also found greater success when users could test the product in its appropriate environment, a mobile phone, and not a desktop computer. I also found that digital prototypes are limiting because they constrain how a user can walk through the application since the sequence is pre-determined. When doing this again, I could of course make a screen and flow for every single way a user can walk through the application, but I think that user a paper prototype may allow for more user control and thus, I can get even better data.

Some key takeaways from my first round of usability testing using the Think Aloud Protocol was that when I write the tasks, I should give users more information about what they may need to enter into each field. I also found that having a setting where I could clearly hear the participant is super important. I sometimes struggled to write good notes because of this. It was also challenging not to step in and help sometimes because Envision made it hard to tap on a field and move to the next screen. I would sometimes end up helping a user because it was just too frustrating for something that didn’t help me get any useful information. Also, after getting feedback from 5 people, I had confirmation that getting many more participants to try the application would not add to the accuracy of what I would learn. I saw patterns emerge already and can imagine that anymore than 10, I would not learn much more.

Of course, I was also able to garner some key issues that I would want to fix in my prototype. They are documented below.

Test documentation-01 Test documentation-02 Test documentation-03Revised “Navigation and Information Architecture” Concept Map

There were two key revisions I made to my concept map. First, I wanted the concept map to reflect the complexity of the application system. My first map was too simple. A future software engineer would have a lot of potential to make up user flows because so many details were missing. So, this necessitated a complete overhaul of my concept map. Second, the concept map would have to reflect the revisions I made to my wireframes.

In order to do a complete overhaul of the map, I started fresh. I went through three paper sketches, getting feedback from classmates on clarity and hierarchy. I made sure that I had different shapes to reflect different kinds of screens and operations. Squares represent places a user goes to. Ovals represent the functions you find in each of the “places”. Circles represent the flows a user takes to accomplish the function. Working through this process made me have a much clearer idea of all of the screens I currently have as well as the screens I still need to develop for a complete application. The feedback I got from my classmates helped me to make a better visual hierarchy. At first I made the ovals a much thicker line weight but this confused my classmates because it made them more important than they should be.

In order to reflect revisions that I made to my screens, my concept map includes a shortcut to get to the main functions a user may want to apply to an account. Also, redoing the concept map made me realize that my I never included a way to logout of the application in the original wireframe set. It also helped me to see what screens I would add a home link to for a user to get to restart faster.

Revised Concept Map
Revised Concept Map

Revised Wireframes

Below are the revised wireframes. First, I highlight the key screens that I revised based on the top 3 problems I chose to revise. Second, I present all of the screens. In addition to the revisions I listed above, I also revised a several other elements. I did these revisions based on what I learned from the critique session in class.

The other revisions were:

  • Graying out a button if it should not afford clicking if all required fields are incomplete
  • Changing the titles of buttons to more accurately reflect what they do (ie changing “Deposit” to “Another Deposit” on the success screen for deposits) or to be more natural (ie changing “Return Home” to “Home”).
  • Adding a logout option on the main menu
    Revised Account home screen
    Revised Account home screen

    Revised View bill - added a home screen icon
    Revised View bill – added a home screen icon
Revised flow for adding a new alert
Revised flow for adding a new alert
Revised login flow
Revised login flow
Revised deposit flow
Revised deposit flow
Revised bill pay flow
Revised bill pay flow
Revised view bill flow
Revised view bill flow
Revised check balance flow
Revised check balance flow
Revised alerts flow
Revised alerts flow
Revised quick pay flow
Revised quick pay flow
Revised transfer flow
Revised transfer flow

Next steps

Next week, I plan to build out my application according to the concept map. I will also do usability testing. But this time, I want to focus on particular flows and to get feedback on buttons and font.

 

My wire framing process: from lo-fidelity to slightly higher fidelity

Last week, I built concept models of banks, the current state of the TD bank mobile app, and a future state of the app so that I could build background knowledge, make sense of complexity, and envision how to create a more usable application. This week, I began the process of redesigning the TD bank mobile application. The first step was to imagine how real people use the banking application. I imagined users with goals inspired by real people. I wrote scenarios that fleshed out their stories, and then drew storyboards that illustrated how they could use the app to fulfill their goals. The second step was to design wireframe flows that illustrated a journey a user could would take to fulfill their goal using the banking app.

What I learned last week

After immersing myself in the TD banking mobile app and imagining a better system, I knew that moving forward I wanted to keep a few key design principles in mind:

  • Keep the app simple – the current app has too many buttons that lead to the same place. This is unnecessary and confusing.
  • Keep the app visually minimal – there are screens in the current app that are too heavy with color and information. It is hard to know what different key screens are used for because my eyes don’t know where to look.
  • Make core functions more easily accessible – functions like check balance require 4 taps. There should be fewer taps to find this information.

Users, scenarios and storyboards

 I wrote about three potential users:

  • Louis, a junior in college who is living on his own for the first time;
  • Stephanie, a working mother who is also her household’s financial manager; and,
  • Clark, a freelance UX designer who has to manage many clients and subcontractors.

I brainstormed all the goals they may have and prioritized which goals were most important. Starting the app redesign here helped me to humanize the experience that followed. Whenever I got lost in the details, I could remember who I was designing the experience for. On a tactical level, it helped me to fill in fields with realistic data. On a systems level, when I had a question about hierarchy in terms of interactions and information, I could think back to my character and imagine it from their perspective.

Users and goals
Users and goals

I also believe that having clear character journeys in mind will help me to make sense of the critique I will be leading this evening. Though I will be asking my classmates to give feedback on how to make interactions more usable and hierarchy clearer, the core of my decision making will fall back on questions like, “What would Louis, a newbie to financial management and adult life decisions, need?” or “How will Stephanie use the features in the banking app to facilitate uncomfortable conversations with her less fiscally responsible husband?”

 

Once I had each character’s story written in detail, I made a spreadsheet with scenes and screens. It helped me to essentialize all of the details. What is the most salient idea I am expressing? What image would communicate the idea to a viewer? This helped me to narrow in big ideas. (So much of this design process is going from detail to big idea to detail!)

Scenarios, screens and scenes
Scenarios, screens and scenes

Then, I moved to storyboarding. This started the process of first, imagining how characters would realistically be using the banking app. How would they be standing? Where? And then, it served as a bridge to thinking about the interfaces. What would Stephanie want to do if another mother pays her back in the middle of the park with a check? What interactions would be fast and convenient for her?

Storyboards
Storyboards

Storyboards to wireframes

In the process of storyboarding, I started to build out wireframes. So much of the design process is working in the right level of fidelity for the stage of process you are working in. While storyboarding, I would draw a storyboard with less detail but would have the big idea. This would prompt moving to another sheet of paper where I would sketch the interface with more detail. It’s a cycle of fidelity. Storyboards have low fidelity but are filled with big ideas. They moved me to start thinking about all the details I needed which prompted me to think about details, spacing and hierarchy of the interface. So, I would sketch the interface and then the flow at a higher level of fidelity on a separate sheet of paper. But then I would return to the same (or different) storyboard to think about what the user would do next. What would help Clark keep his records most organized when transferring money to a subcontractor’s account?

Wireframe sketch
Wireframe sketch

Once I had one complete wireframe journey complete, I moved to designing my wireframes in sketch.

Wireframes in sketch

Below you will see each of the flows that I have developed so far.

The following flows are inspired by Louis. In the first flow, he starts a recurring bill pay to help manage his stress. He feels overwhelmed with all of the new ways he needs to “adult”.

Louis sets up his first recurring bill.
Louis sets up his first recurring bill.

Louis finds out he made a mistake when he set up his bill because he missed a payment. So he has to view what he did and change when the bill is set to pay.

Louis views and changes his recurring bill.
Louis views and changes his recurring bill.

Louis is out with his friends. They want to see a movie but he doesn’t have any cash. So, he sends his friend money electronically.

Louis pays his friend.
Louis pays his friend.

The following flows are inspired by Stephanie. In the first wireframe journey, Stephanie is notified that she and her husband have overdrawn their checking account. She checks her balance.

Stephanie checks her balance.
Stephanie checks her balance.

Stephanie wants to set up a notification for her and her husband so that they know when their checking account will hit $500.

Stephanie sets up a notification.
Stephanie sets up a notification.

Stephanie gets a check from a friend in the middle of a party. She wants to deposit it.

Stephanie deposits a check.
Stephanie deposits a check.

Stephanie wants to transfer some extra funds into her daughter’s college account.

Stephanie transfers funds.
Stephanie transfers funds.

Next steps

First, I need to finish making every screen in my system. Second, I will go out into the field and get feedback from real users. I can’t wait to hear what they say!

Banking Concept Maps

Bank Concept 3

When asked to do a redesign of a banking app, it’s important to start off with an understanding of banking as a whole. Why does this institution exist and how does it function?

From here, we can take a look at a banking app that is meant to provide value to the customers of a bank, and understand how the functionality offered to a customer fits into greater picture of banking.  In this case, I considered the Wells Fargo app. The app is relatively robust. It contains many ways to view and manage one’s money, but also a large amount of additional information about the bank and it’s services.

WF Info Arch
Wells Fargo Information Architecture Map

Considering that apps ideally make our life more simple, I thought the best place to start for a redesign would be to simplify navigation and highlight the aspects that the user would want to work with most, namely managing the money in one’s account. Additionally, I removed and consolidated some of the extra information so that it wouldn’t detract from the user’s ease of movement throughout the application.

WF Existing Info Arch
Redesigned Wells Fargo App Information Architecture

Wells Fargo does a great job of positioning a user’s accounts front and center upon login. I decided to build upon this existing frame by moving some functionality that relates specifically to an account within the account’s summary. This way, when a user wants to deposit a check, they are already positioned within the account they plan to deposit into. I did however, keep the general category of “check deposit” underneath the main navigation menu, since this is one of the more commonly used features of a banking app (this is the only reason I started using my bank’s app in the first place!) and it can still be accessed as a stand-alone feature. Other items in the navigation menu I discarded or consolidated into headings that are easier to understand and find the relevant information. For example, “push notifications” was previously located under the “Settings” tab, but I decided it would be easier to find this feature if it was located under a tab with the rest of the app’s features.

There is still work to be done in order to create an app that allows a user to have both an in depth understanding of their finances as they exist, and also a holistic perspective of how they can best manage their finances. With some more emphasis on managing one’s finances in the long term, I believe the Wells Fargo app can provide great value to a user that wants to understand how they can benefit from using a bank and put their money to work for them.

 

Concept Mapping: Understanding Mobile Banking

The second quarter has started, and in our Rapid Ideation and Creative Problem Solving class we are learning how to redesign a mobile banking application.
The first step in our process has been to create a high level Concept Map of the basic activities that entail managing ones money through a mobile app.
I decided to choose my Bank of America mobile application since it is the one that I use the most. I have always had mixed feelings with this application and its web counterpart. The mobile app seems easier to use in some aspects but harder for others, and viceversa.
Before we dived into concept mapping, as a group, we started by brainstorming a bunch of words that we associated with banking. With these words, we created a 2×2 matrix in order to identify relationships between the main features / actions related to banking. The rows & columns with the greater number of interactions/relationships between each other are the ones that I identified as the essential features of the mobile banking activity:
2×2 Banking Matrix
 
Highlight 2x2 matrix

Once I identified these essential features, I translated them into a more digestible visualization – this is how the following “Relationships” Concept Map was created:

Relationships Concept Map (Low Fidelity)

Relationships - concept map

After this first attempt, I switched to Sketch and re-created a high fidelity version of the map:

Relationships Concept Map

%22Relationships%22 Concept Map(no title)

After our relationships map, we started by “dissecting” the existing application. We did this by taking a screenshot of every single screen on the app. We were to explore features that we had never imagined existed. We ended up with hundreds of screens. This helped us create an understanding of how the flow of the application worked, and it looked something like this:

Existing Screen Inventory 

Screen Shot 2017-10-30 at 11.27.34 AM

We then created a Navigation Information Architecture Concept Map based on the existing application. It got very saturated and complex after a while.

Existing Navigation Information Architecture Map

Existing-BoA

Legend

  • Circle size: I decided to communicate features with higher number of options by enclosing them in a big circle, the more options the feature had, the bigger the circle.
  • Line weight: I also decided to communicate higher frequency of feature use by using a thicker line weight.
  • Dashed circle: Are the customizable features that you can add from “settings”.

After recreating the existing Bank of America mobile application concept map, my understanding of the use of the app was bigger and brighter. I discovered new features I still don’t know if I’m ever going to use, but it also helped me think about possible use case scenarios of how I would go about using the app for a particular situation I were to encounter.

I used this new knowledge to create a redesigned version of the BoA mobile application:

Redesigned - BoA Concept Map

For my redesigned version, I highlighted blue and relocated the areas that I’ve noticed are important and might not currently be in the right place. BoA’s application puts their “Help” button front and center – which stays on the header – so that users can access and type in their questions for self-help. But a more clear placement and wording could guide users accomplish their most common banking tasks in an efficient way.

Bank of America’s mobile application has many features and products that can make it somewhat difficult to navigate, although I attribute the navigation difficulty to a few interactive elements. The app allows for customization which aims to fit different user needs. But this customization capability isn’t immediately obvious and can go unnoticed by many users. I asume this could be especially the case for those users that don’t take the time to explore the capabilities and who just prefer to schedule an appointment at a branch for their needs.

For the rest of this second quarter we will continue working on re-designing our banks mobile application. I’m excited to show the rest of the process!