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.

 

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.

 

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!

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!

Reimagining the TD Mobile Banking Application: from sense making to a future state

In this week’s assignment for Rapid Ideation and Creative Problem Solving, I practiced systematic knowledge creation in order to develop a vision for the future state of a mobile banking application. The process to come to this vision was driven by my own sense making and belief that when a digital product is developed with higher order systems thinking, the product will be more effective, designed with a user’s experience in mind.

The first step I took was to build my own background knowledge on banking. I listed all the banking concepts I could imagine, systematically found relationships between the terms, and built a backbone for the fundamental purposes banks serve. From this foundation, I was able to create a hierarchy of bank knowledge that would fuel my future vision of what a mobile banking application could be. Ultimately, this process led to the banking relationship concept map linked below. Constructing my own mental model for the purposes of banks, what functions and sub functions they perform, and how they fit into the larger financial ecosystem provided me with a framework to make decisions later in this process.Bank Relationship Map

The second step I took was to create an information architecture map of the current TD mobile banking application. This involved physically recreating the entire user flow of the app. I navigated throughout the whole application to create a schematic of the application. I learned how a user would interact with each feature, making notes of breakdowns, and possible opportunities for optimization. I was also able to learn TD banks current hierarchy – what “features” are most important, where are different applications linked more than once, and what functions a user would have to hunt for. This led to the information architecture map linked below.

InformationArchitecture-01

After taking a step back to reflect on how I conceptualized banking and how the TD bank currently designed their banking app, I was able to make new connections. In the above map, you will see that TD bank does not have a clear hierarchy guiding their user interactions. Different applications can be navigated to in multiple ways but it is unclear why this is important. There are also different functions that appear to be higher order and yet, are confusing and don’t appear to serve the user.  I first sorted the features into categories that made more sense, specifically, account management, services, support and profile. These categories matched what I believe to be the purposes banks serve and also matched TD bank’s current application functions. From this, I could easily sort all of the functions into these categories. Thus, you will see a future state of the mobile banking application that has clearer hierarchy. I also made a few decisions including making support easier to access, as well as making security a higher priority from the user’s perspective.

InformationArchitecture-02

Design Research: Getting Inspired and Immersed

Our Interaction Design Research and Synthesis class has given us an opportunity to research a very interesting field – something that we usually don’t think that much about – Animal Food Value Chain. The amount and quality of data we’ve gathered has been keeping us torn between different directions; we finally decided to focus on learning which factors influence consumers’ purchasing and eating of different cuts of meat. In asking consumers to describe how they make choices surrounding their selection, preparation, consumption, and disposal of meat products, we hope to find out how consumers make decisions about which parts of animals they eat, what can influence them to redefine which parts of animals are desirable as food, and what happens to those pieces they purchase but decide not to eat.

This topic touches the majority of people on this planet. It is something that most of the people have experienced, and deal with very often. It is also a source of huge amount of waste and damage to our environment. It is important, and the questions that pop up within this field isn’t something that can easily be answered just out of your own perception of the world. Getting information from other people, and turning it into insights, is critical in order to understand how non-singular this is, how much of a difference there might be in behavior and reasoning of different people. It is fascinating.

The amount of inspiration we get while interacting with people is incredible. We talk to people, we go grocery shopping with them, we cook meals together, we even cut meat together in a butcher shop!

We’ve applied the 5 different types and approaches of gathering information and getting inspiration from people, the 5 types we were taught in the class – and found them all useful:

  • Contextual Interview;
  • Contextual Inquiry;
  • Immersion;
  • Subject Matter Interview;
  • Participatory Research.

Research activities bring us into situations and environments that we wouldn’t otherwise get into. Last week, we were invited into a home of a young family of three to talk about their experience of purchasing and consuming animal-based foods. Our host Anna was home with her 9 months old son. And while an infant would often be considered a distraction in a situation like that, for us it was an incredibly rich source of information about what this woman’s days look like.

We did conduct interviews with people with kids before, and they mentioned how big of a deal, and how much of a struggle grocery shopping or cooking might be when the kids are around; but only after spending 2 hours in an environment like that we’ve truly understood our interviewee: context around her, with her baby being the largest part of it, changed the way she approaches grocery shopping, including the way she selects the meats in a grocery store.

All these words: fast, simple, no thinking, no decision making, straightforward – now it all started to make total sense.

There is a lot of room to grow, a lot of room to improve for us as researchers.

If I was to go through this experience again, I would surely:

  • Make sure the group defines the focus of research as early in the process as possible. What we went through has proved that not having a concise and proper goal, that we all would be on the same page about, is a huge distraction from moving forward effectively. On the flipside, it allowed us to keep a somewhat open mind around the topic of our research.
  • Try to gain more empathy with our interviewees and people we interact with. Maybe even become “friends” with them, in a way, during the interview; and not necessarily trying to keep the whole interaction very “professional” and distanced.
  • Not be afraid to ask questions that I think are dumb – they, in fact, can bring some of the best and unexpected insights.

I am excited to continue this journey with our group, and can’t wait to get to Design Synthesis and generate Insights from all the information we’ve gathered.

 

School Lunch Menus: Future à la Carte

There’s this special kind of feeling when someone hands you over a brief for a design project. Personally I can describe it as a mixture between anxiety and excitement. You read the topic and you already start thinking about what you’re going to do – products, tools, materials, interactions, branding? But, when you’re learning how to conduct design research, you need to remember to take a step back – your experience is not the only one that counts, therefore, your solutions are probably lacking some serious intervention from the outside in.

Set the table

And then your mentors hand you over your research topic: “Animal Food Value Chain” – think about it. So simple and yet so complex. We could even say that our lives have evolved around and thanks to this topic, and therefore, so many systems have been created due to the need and demand of animals and food.

To narrow down the possibilities and create our focus, each member of the team raised the questions that immediately came to mind, and with affinity diagramming we created patterns that slowly started taking us to a potential area of focus:

What are the factors and actors that influence school menu planning specifically around animal based food products.

The interest was there, we all consider that a healthy diet is key to a good academic performance. But we’ve also learned that various perspectives of what a healthy diet should look like differ from context to context, priorities to priorities. But after we discussed enough about what we know or what we think, it was time to hand the microphone to humans in a school setting.

 

Tell me about yourself…

When conducting a contextual inquiry, you approach someone and your intention is to know how to talk to them, so that they can tell you their story as it relates to a subject in particular; they’re in their space (be it work, home or car) and you’re there to learn from them. Your conversation has a goal – you want to know what a person in particular has experienced that will guide you closer to uncovering a problem.

So we went on a Contextual Inquiry adventure and approached an Austin charter school’s food service staff – that was Laura, or the coolest Food Service Director that I’ve ever had the pleasure of knowing- and believe it or not, we didn’t talk about food half the time.

So far, we have discovered that school food staff not only works with the common goal of feeding children healthy and delicious food to warm their hearts and give them energy. Their goal is to instill them good eating habits and taking them away from potential metabolic diseases that are related to bad eating practices. Their goal is to empower students at a young age, and guide them towards reasonable decision making so that they can continue pursuing good choices and do so all their way to college and adulthood. They think about the children’s future and they cook with that in mind.

What about the beef stroganoff?

Creativity is the fuel of makers, artists, designers, performers, chefs, etc. We’ve learned that cooking might sound fun for some, but it can become quite complex and can even inhibit your creativity when you have to work under so many constraints and government regulations. Laura and her staff seem deeply passionate about what they do. If they could improve the service, they would buy all locally sourced food, they would have more vegetables and fruits for children, and make the serving bar lower so that the little kiddos can have a good look at their bright colors and choose the one they like.

So far, exhaustive and tedious processes make Laura’s job less enjoyable than she would like it to be. We wanted to uncover what were the factors and actors that influence school menu planning specifically around animal based foods? We have gotten our answer fairly quickly. Now the question is, who are we designing for?

Summit: Pay it down while you live it up

“I’d like to pay off my credit cards as soon as possible because it is a cloud, it is something hanging over my head.”
–Carl, 32

Debt can be intensely anxiety provoking and yet we saw over and over again in our research that although the young people we spoke with recognize that their financial situation is causing them stress, and could be detrimental to their future, they continue to struggle to change their day to day spending behaviors enough to pay down their debt. Why is it so difficult for people to change their behavior when it comes to money? Why aren’t all of the myriad of existing tools addressing this problem?

 

Satisfaction Happens Now + Fear of Missing Out

Over the last six months, through a dozen in-depth interviews, intercepts and prototype testing, we’ve gained a deeper understanding of how young adults think about their finances, how they feel about their debt, and how they manage their current financial situation.

Blog_ResearchParticipants_Debt

 

Through our research two things became very clear:

1. There is no satisfaction in future benefits. We need to feel immediate value to be satisfied.

2. We want to make good decisions but fear sacrificing more than necessary.

“In the moment of choosing to buy something or not, it’s really easy to make that decision– yeah fuck it, I don’t care– I want this now, and then, oh I have to rein it in now, I have to pay this off.”
–Carl, 24

 

We found that people will make a budget or a plan at the beginning of the month — often using budgeting apps like Mint — in order to get their spending under control, but once they are confronted with daily spending decisions like whether to eat out for lunch or go out with friends, their budget goes out the window. There is a huge opportunity to create a solution that bridges this gap between long term goals and day-to-day spending.

 

Introducing Summit: Pay It Down While You Live It Up

Summit is a financial app that sends users friendly, contextually appropriate messages inviting them to send a little extra money from their checking account to the card they want to pay off, making paying off debt a daily activity just like spending.

Blog_HowSummitWorks
Summit Gets Personal

Summit leverages individual’s spending habits in order to choose the best times to send personally relevant messages inviting them to put money towards their debt.

Blog_MorningJavaMessage
Summit Reduces Anxiety

Looking at a large credit card balance can be overwhelming. That’s why Summit breaks down the user’s long term goal of paying down your debt into small manageable chunks, all while helping decrease the amount of time they’ll be paying their debt.

 

Experience Summit: Click on the image below to get a preview of interacting with the Summit app

Blog_IdealStateClickable

But…does it work?

Summit promises its users to reduce the anxiety caused by credit card debt and empower them to change their behavior and achieve a better financial future, but what is it like to use day after day?. In order to find out, we ran a small pilot using existing technologies to test Summit’s core interaction: sending users daily messages that allow them to put money towards their debt.

We piloted with 7 individuals over 4 weeks and sent a total of 124 messages– paying an extra $388 over people’s minimum payments.

Summit_Pilot
Before our pilot, we calculated how long it would take each of our participants to pay off their credit cards and how much interested they would end up paying based on their current monthly payments. At the conclusion of our pilot we ran the numbers again to see what effect, if any, our service had, and what effect it would have if they continued at this new rate.

 

The results were exciting:

Summit_BeforeAfter

Not only did everyone pay more than their minimum payment this month, but if they were to continue to use Summit, on average they would pay off their debt over 2 years earlier and save over $800!

 

Behavior Change

Beyond saving our users money and years of indebtedness, we also strive to help users change their spending behaviors so they eventually won’t need our service. After our pilot we spoke to all of our participants and asked them if using our service had changed the way they spent money that month.

One of our participants, Jacob, told us about a message he received just before lunch one day. He had brought his lunch to work that day — something he had been trying to do more often to save money — but that morning his friends decided they were going to go out for lunch and invited Jordan along. Even though he had packed a lunch he decided he was going to leave it in the fridge and go with them. As lunch time, approached he received a message from Summit asking him to put $7 towards his credit card debt which he accepted. As he put that money towards his debt, he decided to keep the positive momentum going and eat the lunch he brought.

This is the behavior change Summit seeks to bolster. Keeping long term goals top of mind and creating a cycle of small successes that helps people create their own positive financial future.

 

Going Forward

Going forward as we develop and launch Summit we will be looking for strategic partners who can help us make it a success. Our strengths are in understanding our users and telling stories, and will be looking for people with technical, financial and industry experience to work withus to make Summit a reality.

The Summit Team,
Samara Watkiss, Jeff Patton & Lauren Segapeli

——-

(Click below to experience the pilot)
Screen Shot 2015-04-17 at 11.45.09 AM