UI Wireframing: Bank App Redesign

Sometimes I hit a dead end with a design method and struggle to let myself move forward while feeling like I did a mediocre job on one step—How can you possibly develop something of quality without each step being the best it could ever be. I’m continually proven wrong about the need to perfect the understanding of a product or service using one design method, when the next step in the design process might prove to cycle me back to better understanding the previous that I struggled so much with.

Wireframing my redesigns of the Wells Fargo app did just that. I hit dead ends with the UI concept maps we developed for our last assignment. All of the information felt a little abstract and removed. However, when I was forced into wireframing I had no choice but to carefully study each and every function and why it exists in a certain way. I was immediately able to make stronger critiques of the way the current app flows. I was stuck trying to visualize this using concept maps.

IMG_2303

Working with wires helped me understand the logic of mobile apps and increased the chaos that unfolded with something that seems so fluid and seamless in final interaction state.

Screen Shot 2019-01-21 at 6.38.40 PM

 The first decision I made was to design the landing page to reflect the main functions a user wants the app to do. Everything else is de-emphasized. I went with a fanned out wallet visual. The tabs can be swiped up and down and clicked to engage.

Screen Shot 2019-01-21 at 6.37.56 PM

There aren’t many steps in this deposit flow—I hope this makes it intuitive and simple—but it certainly is more detailed and will allow me to go back to my concept map and inform the revisions I make as things begin to take shape. Screen Shot 2019-01-21 at 6.37.38 PM

I did user research on apps that other banks used rather than basing all of my design decisions on the things I didn’t like about the Wells Fargo app. Experiencing the flow of my Australian ANZ account brought to light a lot of particulars that would not have surfaced otherwise.

While the above flows look simple there is so much minutia and complexity around the wireframes themselves. With the wires revealed just a small taste of the big web looks something like this.

Screen Shot 2019-01-21 at 6.50.02 PM

Banking is a fascinating space to be developing mobile accessibility and the implications of redesigns carry a lot of weight. I am glad to have had this learning experience as I fully appreciate the level of insight that goes into the UI.

Wireframing the Capital One App

Our assignment this week is to create wireframe flows based on the banking app concept models we’d made for Assignment 1. It’s at this point that I understood how lacking my original concept map was. (The grade I received on it was also a good indicator.) If someone were to try and build an app from my map, well, they couldn’t.

On the plus side, I found that creating a complete picture of the app through wireframing was much easier for me than through concept mapping. On the slightly more negative side, I was getting into the weeds quickly by trying to build every possible path. I think I was overcompensating for my concept map’s inadequacy because I started to turn my wireframe flows into if/then statements. Which was not the assignment. (That’s the next assignment.) Luckily I was able to back out of it and create specific flows (e.g. Depositing a Check) vs. every possible flow ever.

Here is one I did for turning on notifications. The Capital One app will prompt you to turn on notifications every time you log in (unless you’ve already turned them on). Using this function, I’ve shown how it will take you to the iOS settings and allow you to set your notifications. (Not pictured are 2 more notifications screens [Show Previews & Notification Grouping] that I did build but omitted for this image so the words would be legible.)

Set_Alerts_Notifications_JF

Another wireframe I built was born out of a need for accessing my security code. Capital One has a specific security code that users need in order to import transactions into third party apps, such as You Need a Budget. I needed that code this week for, yes, You Need a Budget and it’s not accessible via the Capital One app. It has to be done online. So in my wireframe I added it as a category under Profile > Security.

Security_Code_JF

I also gave it a Reveal/Hide function in case you hit it by accident and don’t want people to see it.

Once I stopped thinking about every possibility and zoomed in on what screens will take you from point A to point B, this got a lot easier for me. Next week we’ll be building the prototypes and testing users to see how well our wireframe designs are working. Stay tuned!

Mobile Banking App IA Redesign

There are so many different preferences of bank customers. Some people want to have nothing to do with the high maintenance fuss of banking and managing accounts. Others want their hands on everything. People think they know themselves and their preferences, and then they lose their wallet, and all of a sudden their needs for the app are totally different than before. What is appropriate to have on a mobile app that makes for a functionally simple yet robust app?

When I use my Wells Fargo app I often feel like there are far too many steps in between the landing page and my goal having opened the app. If you are someone habitually checking your account balance and perusing transaction histories, then Wells Fargo is great for you. But why do I have to navigate multiple menus to get to check deposits and account transfers? The Wells Fargo App tries to do a lot, and it grows more bloated with every feature that is clumsily incorporated. I’ve represented my information architecture experience with the app below:

WF@2x

When considering redesigns I wanted to keep the main functional goals in mind. While there is no doubt that things are missing, I decided to iterate with a very clear and simple map so as to emphasize what the root functions are of the banking app. Things can get more busy in later iterations and prototyping when things are more clearly missing (under build rather than over build).

The true shape and content of the app should be informed by user scenarios and needs. Here are the bones.

WF Copy@2x

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.