Service Design at a Hostel

Have you ever stayed in a hostel? It’s much more than just a place to sleep. It’s a home filled with brothers and sisters you’ve never met. Things can be messy, awkward, confusing, but also warm and comforting.
In Q2 Service Design, we’ve taken on a project with a local Austin hostel. Our task, as three ambitious but relatively inexperience design students, is to show our hostel client the value of service design. We plan to get to know the guests and staff, understand their motivations and the nuances of their experience at the hostel.

Two weeks in and we’ve already uncovered some surprising differences in the clientele and operations of this hostel in contrast to our own hostel experiences abroad. It’s not filled with only young adventure seeking booze hounds, but rather a much richer integration of complex individuals.

We can’t wait to learn more.

Preliminary Customer Journey Map
Preliminary Customer Journey Map

Service Design: a team project by Josh Browning, Nicole Nagel, and Scott Reed

We started the Service Design course by hitting the pavement and approaching businesses in East Austin to hire us for a service design project. We contacted a variety of companies, including a sign manufacturing company, a coffee shop, a bicycle shop, an auto body paint distributor, and finally an auto body repair shop.

After a day of recruiting, we decided to pursue the auto body shop, which is a family-owned business operating in its current location since 1954. They have multiple customer interactions throughout their service, and emotions play an intriguing role throughout the repair process.

Our next step was a lunch meeting with the client (and since we’re in Austin, it was a taco truck) to make our pitch and present the proposal. We offered to analyze the client’s existing service delivery and to create and implement solutions to enhance the customer experience. The proposal detailed a 7-week project plan including fieldwork, synthesis, prototyping, and a presentation and report of the findings.

After closing the deal, we developed our research plan and immediately started customer interviews and observations.

Front of House Research Approach

We aim to understand how customers interact with the auto body shop service. Customers will include people receiving estimates, those who have scheduled repair appointments, and those picking up their car at the end of the repair.

Front of house research

Goals and Intent

  • To understand the factors that promote the customer to reach out and then use this service.
  • To understand how the customer perceives the value, and where and how the client provides that value.
  • To understand the frequency and effectiveness of customer communications throughout the experience.
  • To understand customer emotions throughout the experience.
  • To understand the ideal collision repair experience.

Methodology

We will utilize contextual interviews and participatory methods as the primary tools for gathering qualitative data. Interviews will last approximately 30-60 minutes.

We will observe customers as they experience the service, and then engage select customers as participants. We will ask them about their experiences through design research methods, conducting in-depth interviews to understand the perceptions and expectations of participants who have just experienced a component of the service. Finally, we will facilitate a participatory activity with participants who have completed the entire service to arrive at an image of their ideal collision repair experience.

Key Questions

  • What does the ideal collision repair experience look like to each customer?
  • What aspects of the service does the customer perceive as valuable, and where and how does the client provide or lack that value in their eyes?
  • What is the frequency and effectiveness of customer communications throughout the experience?
  • What are the primary behaviors exhibited by customers getting their vehicles repaired?

Participants

Research participants (8-10 in total) will fall across three distinct customer interactions:

  • Participants who are receiving an estimate and have not yet decided to use the service. Key moments to capture: initial arrival and estimate communication.
  • Participants who have finalized a decision to use the auto body shop, have an appointment for repair scheduled and are dropping off their vehicle for repair
  • Participants who have completed the service repair and are picking up their car.

Also, research participants should contain a mix of customers who are passionate about their vehicles and customers who have a functional relationship with their cars (as well as any other critical behavioral qualities that surface through our research).

Back of House Research Approach

We aim to understand how the auto body shop culture and operations influence the customer experience. Vital operational aspects include customer communications, repair planning and execution, and team coordination.

Back of house research

Goals and Intent

  • To understand critical processes and timeline for service delivery.
  • To understand the culture, helping guide what types of changes and recommendations would be well received.
  • To understand the current customer experience from the employees’ perspectives.
  • To understand how the managers and technicians measure customer success.
  • To identify their history with understanding and changing their service offering.
  • To identify the key stakeholders and their interest, role, and responsibilities concerning the service offering.
  • To understand how the client perceives the value they provide, and where and how (specific touch points or moments in time) the service provides value.
  • To understand where the customer experience starts and ends.

Methodology

We will utilize contextual interviews and participatory methods as the primary tools for gathering qualitative data.

We will observe the front office participants as they engage with customers, insurance providers, rental car companies, and any other entities to understand how they manage the various components of their responsibilities. This will help us gauge moments where the service delivery is not seamless, and where there might be an opportunity to improve the customer experience.

For the technicians, we will observe and probe as they work through their shop duties. This will allow us to better understand the level of work, detail, and skill required to execute their roles, as well as diagnose pain points in their processes. These inquiries will add color to the participatory timeline activities we plan on doing with most of the employees.

The participatory research will consist of 40-70 minute activities with managers. We will conduct a Daily Timeline activity and an activity where they map out their interactions with a specific customer from beginning to the conclusion from their perspective. These participatory activities will allow us to observe their emotions, perceptions, and expectations around the elements of their work, and prompt us to probe where potential opportunities may lie.

Key Questions

  • How does the team describe is the current customer experience?
  • What type of changes has the client made in the past? Why did they make those changes and how were they implemented?
  • Who are the external players involved, and how do they challenge or affect the client’s service delivery?
  • What is the frequency and effectiveness of customer communications throughout the experience?
  • How does the client’s team approach and cater to different client types?
  • Where does the client’s team perceive their customer service as the beginning and ending?
  • How do the employees interact and work with one another?

Participants

Participants will include management, and interviews with body technicians, paint technicians, and assistant paint technicians.

Customer journey map in progress

Next Steps

At this point we are about a third of the way complete with the project. We have created a complex customer journey map detailing the end-to-end process, the elements at play in each step, and the breakdowns within particular steps. Our plan moving forward is to complete additional customer interviews to collect more stories and data around the unique elements of the customer journey we have identified during this initial synthesis.

Designing for a More Inclusive Financial System

Building on Last Week’s Exploration

Last week, I immersed myself in a mobile banking application (US Bank), cataloging every screen that exists within it and using these images to map out its information architecture. The in-depth navigation exercise made me feel confused and overwhelmed – functions come from all over the place and are housed in locations that feel nonsensical. Engaging with my classmates’ work reinforced this need for a simpler banking interface; there’s ample room for a successful new product in the industry. So, in creating something more successful, what categories and functions can I challenge, and how can I better communicate away some of the complexity?

From here, I developed some characters of different backgrounds who would want to use a banking application. I colored my characters with ages, jobs, values, and goals. Then, I placed these characters in sets of contexts through which they built their banking processes. I drew off of these stories and began creating storyboards, but then I paused.

While I felt a connection to my characters, I didn’t feel my designs were solving any meaningful problems; instead, they were simply making achieving currently-achievable goal easier. I sought my AC4D mentor’s advice, and together we talked through problems with our financial industry. What do I want to help my users achieve with my application? What are some salient problems worth addressing?

Identifying a Compelling Problem

Our discussion landed us on US immigrants, and specifically refugees. Our country’s credit system is difficult to navigate and to participate in when arriving from an outside nation. There is a catch-22 with credit that is incredibly frustrating and unequal – how might we start to overcome this barrier and help refugees thrive in the United States financial system?

After hanging up with my mentor, I felt inspired and invigorated, and I dove into hours of desktop research. I learned about the process of arriving and settling into the United States as a refugee, the institutional and educational resources available to this group, their primary financial motivations, and any previously identified reasons for their lack of participation in the mainstream US financial system.

Through my research, I learned that many immigrants don’t trust the US banking system. Some think that the bank will police them, and others worry that banks will withhold their accounts for reasons like expired identification. I also learned that many immigrant households are unaware that they qualify for checking and savings accounts at these institutions. How can we start building a dialogue between immigrants and financial institutions?

Before moving forward from my research, I articulated a sets of design criteria to guide my interface designs.

  • The design must promote trust between the user and the bank.
  • The design must promote flexibility in asset access and movement.
  • The design must be simple and intuitive enough to overcome language barriers.
  • The design must successfully guide the user through complex systems.

Moving to Screens and Wireframes

1st Point of Contact for New Users

US Bank and Bank of America currently do not have any language options other than English. You can contact customer service in Spanish, but navigating these digital interfaces in a secondary or unspoken language could be incredibly challenging. I wanted to show people from the start that US Bank is keeping the diverse US population in mind and is here to cater to anyone’s needs.

welcome 2welcome 1

welcome

From the entry, I created somewhat of a tutorial to guide new users through 3 key aspects of banking:

  1. opening checking and savings accounts
  2. making a deposit – in this flow, a mobile check deposit
  3. understanding, evaluating, and building credit history

The flow of these elements needs to be refined as I work on the next iteration.

Opening checking and savings accounts.

In this flow, my primary goal was to highlight the accessibility and simplicity of opening these accounts.

getting started 1

getting started 1

getting started 1.2

Making a deposit.

A 2006 report on financial access found that US immigrants spend more than $2 Billion dollars a year cashing their paychecks through check cashing organizations that charge fees and percentages. This is a simple and huge opportunity for our financial institutions to help, as they already have this infrastructure in place, and it is a free service.

makeadeposit1

makeadeposit2

Understanding, evaluating, and building credit history.

Credit is the biggest problem for refugees (and many Americans alike). Refugees often have to quickly uproot themselves, and, from there, they are dropped into the US financial system that requires you to already have been planted for a long time.

One former refugee I spoke with, who has engaged in design projects centered around refugees, told me that financial systems are increasingly similar across nations, so language and explanation are not as important as communicating the value of credit, how the credit system works, and helping refugees to successfully build credit so they can participate in the system. This set of screens starts to address credit education and resources.

credithistory1

credithistory2

Next Steps

From here, I plan on reaching out to refugees in the Austin community to better understand their goals and values, as well as learn how my current wireframes can better address these goals. I am looking forward to immersing myself in this space and creating something of value by the end of these next few weeks.

Wireframes

20171106_212102

The second assignment in Rapid Ideation and Creative Problem solving was creating wireframes. I started this process by creating three distinct people. John, Elle and Frank. By creating three individuals with individual backgrounds and characteristics I was able to understand what goals they (and potential users like them) may have in interacting with the mobile app.

John is a Freshman at the University of Texas and works a waiter at Red Lobster. He has students loans that give hime funds for books, tuition and school related materials. All other expenses are funded through his job’s income. He has used mobile banking for many years but just signed up for account at New bank and does not have knowledge of this particular mobile baking app.

Elle is a middle aged woman working as an RN with two kids and a husband that works for IBM. They have a joint checking account. She has used mobile banking for years.

Frank is an elderly man who is retired and living on a fixed income from his retirement accounts. Does not use mobile banking often and instead relies on in person interactions with banking personnel for many of his banking needs.

20171102_130818

I was able to understand and identify key goals that each person might have in using the app and I used those goals to create stories that played out many different scenarios for each person. I chose to focus on seven scenarios

John:

  • Learn how to make monthly payments to landlord.
  • Edit and change recurring payment
  • Pay a friend for dinner

Elle:

  • Deposit a check
  • Check account balance

Frank:

  • Report stolen phone
  • Sign up to get fraud alerts

The next step in the process laid out in the assignment sheet was to create UI Storyboard, however, as I began this process I found that sketching the screen flows out proved to be more beneficial for me. I decided to write out my scenarios as a screen by screen dialog. An example scenario is the “Pay a friend for dinner” story written for John. It reads,

  1. John opens app,
  2. Fingerprint login comes up
  3. Puts finger on sensor
  4. “Validating” screen
  5. “Home Page”
  6. John clicks “Menu”
  7. “Menu”
  8. John clicks “Bill Pay”
  9. “Bill Pay”
  10. John clicks “Send $ to Friend”
  11. “Pay amount screen”
  12. John types in 30
  13. John presses pay
  14. “To” “For” “account” screen comes up
  15. John types in HIs friend’s first and last name.
  16. Results comes with nothing. Shows “Add to Contacts”
  17. Shadow box comes up with “add to contacts” “Create Contact” and Update existing
  18. He clicks Create contact
  19. Edit contact page comes up and asks for mobile phone number, person or company drop down
  20. John types in phone number
  21. Chooses “person”
  22. Clicks “Save contact” at top of page.
  23. “To” “For” “What account” screen comes up
  24. Clicks “Savings x55655” drop down
  25. Savings and Checking shadow box comes up
  26. Chooses Account “Checking – X5656”
  27. Shadow box goes away
  28. clicks “For:”
  29. Types in “Dinner”
  30. Clicks “Send $30”
  31. Check mark screen saying “Sent! $30 will be deposited once [Friends name] accepts this payment.

I felt that by laying out each screen in a plain way I was able to then transfer those dictations into sketch wireframes that I used to create the flows. From the flows I created through sketching on graph paper I then had a clear, concise idea of what I needed to create in Adobe XD.20171105_230307

I found the most useful tool in this process was mapping the screens out with each action taken. It made the transition from ideas and concepts to artifacts by way of digital wireframes. In the future I will attempt more of the storyboarding technique to see if there is value in that part. Wireframing is a difficult task because there are so many screen and scenarios, and often it can see overwhelming to start crafting screens. These tools: sketching, writing scenarios, creating people, and giving them goals, is a very useful tool to wrap your brain around the subject when things seem very scattered.

20171106_225602

 

Wireframing a better mobile bank experience. Sorry, Chase!

 

After spending hours creating a Concept Map of new, better Chase Bank App I was ready to make next step and wireframe the App.

Wireframes are a wonderful visual tools to communicate the intended designed user flows in a mobile application or website. They do not have a goal to show how the final version of the app is going to look like, but they lay the foundation of the potential designed system.

Doing wireframes I was targeting next problems I discovered on a stage on Concept Mapping.

1. As almost every other Bank App Chase makes its client learn bank language. To successfully use it the client needs to know the difference between functions like “Transfer money”, “Pay Bills”, “Wire Transfer”, “QuickPay”, “Zelle”. Even if it looks so obvious for some people, for others it looks like nightmare to the point that they reject trying to use it at all.

To keep myself aware of this problem, I created a scenario where main persona has just these struggles.

Her name is Brenda. She is from Texas. Brenda is a retired piano teacher. She loves to walk with her dog and drink mimosa on Sunday morning. Twice a year she visits her sister and her 3 nieces in Oklahoma. She mostly use cash and checks, and she is looking for a way to send some money for her nieces’ Birthdays and other milestones sometimes. Now Brenda deals with the Chase App trying to do that, but since it is not her routine, she needs to learn it again every time she needs it. She doesn’t know anything about how banks work and doesn’t really want to know. She just want to transfer some money to her sister once in awhile.

I tried to redesign the app to make it more needs-driven than services-driven. Now web app will make this job on defining a type of need for itself. Customer just need to know what he wants to accomplish.

2. If some problems are caused by the industry, some of them are definitely caused by poor design decisions. As I already mentioned in my previous article – Chase App seems to be purposefully complicated and swollen. 30% of links in main menu bring you outside of the App (half of them are really “ads” but you don’t know it until you try). To be able to do some core functions like Wire Transfer and Pay Bills you need to enroll on the website (but you don’t know that you can do it until you learn it on the website – it just won’t display in the mobile app until you do that). And to add a new Payee for a wire transfer you need to add them on website as well and can not do it in the mobile app. It may be very frustrating for some people. For example, for Ness.

This is Ness. He is an electrician and lives in New Jersey. Ness just got divorced and now he needs to fully take care of himself. He recently moved in in his new apartment. He already bought an iron and burnt 2 shirts. He knows that his wife always paid for utilities using her phone, so he decided to try as well. He downloaded Chase App, but he can not find a way to pay them. He is very frustrated. He doesn’t want to call his ex-wife and show that he is so helpless without her.

I included Pay Bills and Wire Transfer as default functions on the App. I also made a brave decision to exclude all promotions from main screen to simplify the app, but I have some ideas how to promote the bank services in less annoying way (follow the blog for next iterations).

3. Even though Chase App is very functional it still doesn’t have a proper level of consistency between all the functions (that are similar, but for some reason act so differently). And it’s overwhelming. Working on it I couldn’t stop thinking about it. How is it possible that huge company with the best professionals have products which is like an undercooked soup – somebody just through vegetables in a pot with cold water. And even if it looks like a soup, it doesn’t taste good. Meet Matt. He knows what I’m talking about.

This is Matt. He is a very successful project manager in a large company. He eats healthy food, runs every morning and networks every night. He is very busy. He likes to complete all routine daily tasks on a run. He uses his phone to pay his bills, pay to his lawn-mower, manage his multiple accounts, and sometimes even making international wire transfers. He uses Chase Checking, Savings accounts and Credit Cards, and likes to keep track of all of his transactions. He mostly uses his phone up to make sure there is not a single transactions he is not aware of.

My goal was to create more consistent, coherence application: one of the major overhauls I did is making all kinds of Transfer options have the flow be as similar to each other as possible, so that the experience isn’t that drastically different from one to another.

_Everything

This week I’ll test the first iteration of redesigned Chase App with real people. But before I’ll dive into usability testing, I’ll make sure all screens are present and make sense. I’m very excited to revise the screens and flow based on critique and testing. Stay tuned!

If Banking Apps Looked Out for their Users, It’d get a lot more Personal

I can’t stand banking stuff.

I confessed this to my classmate earlier this afternoon as we both worked and reworked wireframes for a banking app. I felt desperately uninspired.

“Banks rule the world!” He replied. Is that true?

What are banks even good for? They provide security. We don’t have to store all our cash under our mattresses. They give us credit to buy things we might not have the immediate funds for (yay, credit cards!). They also help us set money aside so we can save up for something, whether it be a new couch, college tuition, or retirement. But banks could do more to help us manage our money. The institution itself it not approachable, and it gives a lot of people an uneasy feeling dealing with a bank.

Wells Fargo just implemented a new paying system that other banks have adopted as well, called Zelle. It feels like a nod to Venmo, and the interface for the “Zelle” portion of the app is more lighthearted. I decided that I would recreate this flow, keeping some of Wells Fargo’s interactions, like the “contacts” piece which is simple and easy. The main part I eliminated was an enormous SEND/REQUEST screen that seemed unnecessary. Instead I put “Send” and “Request” at the top of the screen so the user could switch between the two, which is a bit more like how Venmo functions.

Notice how the top row of screens have a different feel from those in bottom row which are reflective of the “Send money with Zelle” function.

WF- Pay a Friend Flow

Here you’ll see how you can easily add someone by searching their name or phone number, which I thought was a nice way to easily store them as a contact in the app.Wells Fargo Request Money

Additionally, I added the confirmation page, which I am still reworking. Wells Fargo has a terrible system of sending you a text and an email telling you the transaction will happen in a couple of days.

Sending and receiving money is a very commonplace activity and prior to creating any wireframes, I had spent some time thinking of users and scenarios in which the app would be useful. People often send money to each other when they are sharing expenses, and expense sharing happens a lot when a group of friends are on a trip together.

Artboard 1-100

Setting up a travel plan should be easy. I moved the “Manage Travel” to it’s own tab under account services.

Artboard 2-100

Shouldn’t your bank pay attention to you? If you have a long trip planned, wouldn’t it be nice if you bank helped you prepare for it? With this in mind, I decided to create a way for a user to quickly make a Travel Savings Account and be able to calculate how much they will have saved by the time their trip rolls around.
Artboard 3-100 However, after giving this a bit more thought. I typically don’t let my bank know I am leaving for a trip until the week of my departure. That is hardly enough time to start saving for it. Knowing this, I still thought having a way for a user to easily create a Saving Account on the app could be useful for those with big purchases in mind.

So now, I continue to think about that person on the trip with their friends, making guesses as to how far his money will last and wondering if he can afford the upgrade or not. Banks can better support it’s users by helping them to budget for life’s expenses. A bank should feel like cash in your pocket – you know what’s there and no one is taking money out of your pocket without you knowing about it (ideally!).

As I think more about my next iteration on the Wells Fargo Banking app, I hope it feels a lot more like a friend looking out for you, than like an institution.

 

Iteration 1: My Redesign of the Velocity Credit Union Mobile App

Identifying issues with the existing Velocity Credit Union (VCU) app last week was just the beginning of our work this quarter in Rapid Ideation and Creative Problem Solving. The hypothetical information architecture concept map I created last week as a redesign of the VCU app underwent quite a few changes when I actually had to start putting together storyboards showing how people would use the VCU app.

For instance, I realized my original idea for the Bill Pay function was not really taking advantage of current tech. The existing VCU app has you manually enter in the information for every payee you want to add to your Bill Pay list. I simplified that process in my first hand-drawn sketch, but then I realized that I was missing out on an obvious and much easier solution: just allow users to select from a list of popular companies for which the VCU app would already have the billing information. Then, if someone needs to enter a more obscure company in manually, you can give them that option, but if they need to pay Southwest Airlines, for instance, the information for that company is ready to go. Below you’ll see what I came up with as the full flow for scheduling a bill pay. Flow_ New Bill Pay_ Screen 1

Flow_ New Bill Pay_ Screen 2 Flow_ New Bill Pay_ Screen 3 Flow_ New Bill Pay_ Screen 4 Flow_ New Bill Pay_ Screen 5 Flow_ New Bill Pay_ Screen 6 Flow_ New Bill Pay_ Screen 7 Flow_ New Bill Pay_ Screen 8 Flow_ New Bill Pay_ Screen 9 Flow_ New Bill Pay_ Screen 10 Flow_ New Bill Pay_ Screen 11

Flow_ New Bill Pay_ Screen 12

In addition to having the searchable list of common business payees, this flow differs from the actual VCU app in that when you select the date of the payment, a panel that actually looks like a physical calendar pops up. In the current VCU app, you just have to enter in numbers for the date. I chose to include that panel because it helps me to be better able to plan my finances if I can see when weekends or holidays are happening. That way I don’t accidentally make myself late on a payment because I scheduled it to go through on a Sunday.

 

I also built an updated version of the screens you would need to manually enter in a new bill payee.

Flow_ New Bill Payee Entered Manually_ Screen 1 Flow_ New Bill Payee Entered Manually_ Screen 2 Flow_ New Bill Payee Entered Manually_ Screen 3 Flow_ New Bill Payee Entered Manually_ Screen 4 Flow_ New Bill Payee Entered Manually_ Screen 5 Flow_ New Bill Payee Entered Manually_ Screen 6 Flow_ New Bill Payee Entered Manually_ Screen 7 Flow_ New Bill Payee Entered Manually_ Screen 8 Flow_ New Bill Payee Entered Manually_ Screen 9 Flow_ New Bill Payee Entered Manually_ Screen 10 Flow_ New Bill Payee Entered Manually_ Screen 11

This flow differs from the current VCU app in a few ways even after it forks away from where the last flow goes into selecting a common payee from the pre-made list. First, I added a confirmation message at the end letting the user know that they did successfully add a new payee (and giving them one last opportunity to review the information they put in). Second, after that confirmation message, I sent the user back to the “Saved Payees,” which has an alphabetized list of payees the user has paid previously using this system. In the original app the list of saved payees is organized in the order they were last used, with the most recently used appearing at the top. This means that if you add a new payee, it appears somewhere near the bottom of the list, making it hard to find.

Another flow I updated so that you do not have to manually enter in information every time you use it was the transfer funds feature. Now, in the current VCU app, the closest thing to being able to easily send money to a friend is the option to transfer funds to someone else who also banks at VCU, but you have to re-enter their information every time. For my redesign of the VCU app, I made it function much more like Venmo in that there is a searchable saved list of people you could send money to. Take a look:

Flow_ Send Money to Friend_ Screen 1 Flow_ Send Money to Friend_ Screen 2 Flow_ Send Money to Friend_ Screen 3 Flow_ Send Money to Friend_ Screen 4 Flow_ Send Money to Friend_ Screen 5 Flow_ Send Money to Friend_ Screen 6 Flow_ Send Money to Friend_ Screen 7 Flow_ Send Money to Friend_ Screen 8 Flow_ Send Money to Friend_ Screen 9 Flow_ Send Money to Friend_ Screen 10

This makes sending money much easier as no one, not even the person you’re trying to pay, is likely to know her routing and account numbers off the top of her head.

Next, I took a pass at updating the mobile check deposit feature of the VCU app. Here it is:

Flow_ Deposit Check_ Screen 1 Flow_ Deposit Check_ Screen 2 Flow_ Deposit Check_ Screen 3 Flow_ Deposit Check_ Screen 4 Flow_ Deposit Check_ Screen 5 Flow_ Deposit Check_ Screen 6 Flow_ Deposit Check_ Screen 7 Flow_ Deposit Check_ Screen 8

I primarily updated this flow by tweaking the UI. For instance, on the mobile deposit main screen in the original VCU app, every piece of information is centered and the same font. This means there is little visual hierarchy. In my version, I set the “Deposit to” information up and to the left, letting the amount of money you’re depositing occupy a larger and more central area. I did this because it seems like people are more likely to make errors entering in the amount of money their check is for rather than picking the wrong bank account. There are more ways to mess up when typing on a keyboard than when you’re choosing between your few bank accounts. Therefore, it made sense to me to make the check amount number larger and more prominent so that people have more of a chance of catching their errors before they try to deposit and get an annoying error message.

Lastly, I also took a stab at flow for checking you account balance. This was by far the shortest flow:

Flow_ Check Balance_ Screen 1 Flow_ Check Balance_ Screen 2

For this flow, I did a few updates. Most prominently, I moved your credit card balance out of the weeds of the “Services” Menu option and put it here, right on the home page of the app. I did this because keeping track of how much you’ve already charged this month is just as important for many people’s sense of their financial health as checking how much money is in their bank account at any given moment. If you’ve already got a $500 balance on your credit card, it doesn’t matter if you have $350 in your checking account. You still can’t afford those shoes you want.

Secondly, I updated the UI surrounding the header options. Instead of a button that says “Menu,” I used the common triple line symbol indicating a menu. Also, instead of a button that said “More” which weirdly gave you the same options as the top three Menu options (Deposit Check, Transfer Funds, Bill Pay), I included a “Log Out” button. Many people log in just to check their balances, so having a ready to hand way of logging out on the same screen on which you can check your balance made sense to me.

This is just my first iteration of the updated VCU banking app. I’m excited to get critiqued tonight so that I can rip apart many of the things I just explained to you and then make them better. Tune in next week to see the second iteration!

Banking mobile application: scenarios and wireframes

The second phase of the project for Rapid Ideation and Creative Problem Solving course (see a post about the first step) was to craft scenarios, storyboards, and wireframes.

I started with scenarios, written stories, that explain how a person will use a product or service to achieve a goal. Each scenario includes the person involved with a brief background, the person’s starting state/context for where they are using the product or service, their goals (want or need) in using the product or service, and stories that explain how a person uses a product or service to achieve their goals.

I developed three characters across age-bands so that I can better understand different types of customers who use banking applications.

Characters and backgrounds

Allie: A 38-year-old physician at a local hospital. She lives in an affluent Austin neighborhood. Mother of three and balances a busy home/work schedule. Allie uses a computer and smartphone daily.

Timmy: A first-year student at the local university majoring in International Relations. Parents supplement his part-time campus bookstore income with a weekly allowance. Opened his checking account before going away for college. Grew up with technology and got his first smartphone for his 12th birthday.

Connie: A 59-year-old human resources professional at a midsize company in Austin with offices spread across the country. Her first grandchild was born a year ago, and she enjoys visiting them on the East Coast whenever possible.

Sample scenario

Scenario_sample

 The written stories were helpful for me to understand what a customer might want to accomplish with a banking application, to consider new mobile services, and to develop a list of screens to create.

Scenario to screen mapping

I created several rough storyboards of the written stories to help illustrate ideas and the customer needs. I moved onto sketching wireframes of screens and used Adobe Xd to enhance the fidelity.

Wireframes: deposit check

Sample wire frame: deposit check

 

Wireframes: view checking account debit transaction

view checking account debit transaction

 

Wireframes: pay existing account

pay existing account

 

Wireframes: send someone money

send someone money

My next steps in the project are to begin usability testing, to develop additional screens, and to revise the screens and flow based on critique and testing. Usability testing will be essential to iteration and improving the design.

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!

Wireframing: Redesigning Mobile Banking

For the second part of our Mobile Bank App Redesign project – recap for the first part here – we dived into wire framing.

We developed a few scenarios inspired in different types of people. This allowed us to think of different banking needs that other people might have and helped us understand what would motivate them to use a mobile banking application.

Using a – Character, Background, Context, Goals, Story – framework, we came up with three characters and four different scenarios they might encounter which would lead them to interact with their bank through a mobile application.

Character
Isaac, 38

Background
To start creating scenarios for our characters, we first started by “humanizing” them by giving them an identity, describing their motivations and unattained goals, and assign them a level of competence of the technology that we will be using to help them, in this case – a mobile application.

One of my characters is 38 year old Isaac, who is a freelance designer and has a 13 year old daughter. He works from his home office most of the time, while his partner works full time at a consultancy company. As part of his day-to-day activities, he takes care of grocery shopping, and everything that has to do with bills. He uses his computer for many of his activities but appreciates having his phone around to notify him of important events whenever he’s running an errand or visiting a client.

Context
To start introducing the product into the live of Isaac, I assigned a context of the time and place that he will be in when he starts to use his mobile application.

Isaac recently opened a savings account to start saving for his 13 year-old daughter’s college. He realizes that he just missed one week of depositing into the saving’s account and is worried that this might continue happening and thus, end up saving less than he could have for her daughter’s education.

Goals
In order for Isaac’s needs to be fulfilled, the following goals would need to be addressed by the product that he will be interacting with:

Isaac would need to be able to:

– Know that there is enough money to make a transfer
– Know that money was successfully transferred
– Make sure the information is saved (to prevent future mistakes)
– Avoid having to repeat steps for this repetitive task

Story & Screens: Storyboarding

With my character’s background, goals and context, I was able to create the following story, which I segmented into key areas in order to organize my storyboard . Each key moment in the story gets assigned a screen on the storyboard. This process also helped at identifying key interfaces that I will have to create for my higher fidelity screens.

Screen Shot 2017-11-06 at 6.44.48 AM

Storyboard

Storyboard - Banking

Low fidelity UI

Structure

Wireframe Bank

First flow:

Transferring money, setting up reminders

wireframes(stab1)

This week, I will get the rest of my wireframes ready for user testing which will hopefully give me a lot great feedback to iterate my product.