focusing in on mentorship

This week, Susi, Christina, and I pivoted slightly once again as we refine our concepts. Last week we mapped out service blueprints and more closely defined our concepts. Using what we uncovered, this we revised our service blueprints, reached out to competitors for interviews (scheduled for next week), and re-opened a concept we’d previously put on the back burner: Mentor Match.

We are honing in on the problem space of young first-generation Americans assessing their post-high school options. One theme that emerged from our research is the reality that parents’ lived experiences and perspectives plays a huge role in shaping what young people in this group believe is possible. Yet it’s often the key support of a non-family member—coach, adviser, or teacher—that plays the pivotal role in young people making choices about college. In short: Young lives are changed when they encounter someone who instills confidence and provides alternative ways of seeing the world.

As such, all three concepts now revolve around matching young first-generation Americans with the advice and support they need. Ask Maya is a published advice column + newsletter; Storytelling Series is our, well, storytelling series.

Our new pivot, Mentor Match, is a digital concierge matching service to connect potential mentees with up to three mentors.

We arrived here after downselecting away from Turbo Life, a digital “whole life” management tool. We found that idea too far afield in terms of service and too “already done” in terms of existing products to continue, and our interviewee/testers agreed.

Instead, Mentor Match grew out of a conversation with a subject matter expert (and possible future stakeholder). She shared that her organization has a robust alumni network, and a growing student recipient base, but no effective way to connect them. She described the relationships between the organization and the students as “transactional,” and expressed a strong desire to help turn these relationships into something lasting, mutual, and engaged.

Her insights help hone our concept this week. Using her as a case model, we have begun building a prototype to test a tiered matching service—a digital tool that will allow mentees to fill out a profile, be matched with three possible candidates, and meet up from there. Each mentee will be requested to meet at least one mentor, with a strong encouragement to meet all three, to best test out which pairing might yield the best success. Think “E-Harmony” for life mentorship.

Our next steps include developing our custom matching criteria, testing our criteria by hand-matching a small pool of mentors and mentees, and testing our pitch deck with possible organizations and companies.

Team Impostorism Update

Last week Laura, Vicky and I narrowed our three design concepts down to two. Here are the three we’ve been working on this quarter:

  • DESTRUCTION BOX: Self-care, self-reflection, and stress relief, all tied up in one monthly box. Instead of nurturing, pampering, or creation, subscribers are encouraged to express anger, rage, and destruction by symbolically destroying feelings of impostorism.
  • JVL CONSULTANCY STEP THREE: A human-centered design firm providing company leadership with actionable solutions and recommendations to help hire, retain, and promote top talent while moving toward a more balanced and inclusive workplace.
  • ATX FAIL CLUB: A safe space to share your stories of failure and impostorism in your life. Curating dinner parties and storytelling events for women-identifying people to come together and celebrate stories of failure.

While logic would point to us narrowing it down to our two most developed ideas, we opted to move away from what was arguably our easiest idea, the Destruction Box, and use that energy to focus on the more wicked problems addressed by Step Three (name still subject to change) and continue to develop the ATX Fail Club.

But do not despair, the Destruction Box isn’t going away entirely! Every user we talked to mentioned that regardless of the feelings of release/empowerment/joy they might get out of symbolically destroying feelings of impostorism, they’d be snapped back to reality pretty quickly when they had to clean up their own mess. So we’re considering incorporating some small acts of destruction at the end of our ATX Fail Club events and we’d do the cleaning up.

This week we:

  • worked on developing our service blueprints
  • continued to refine the offerings of Step Three
  • reached out to more contacts, some of whom we’ll connect with in Q4 due to scheduling
  • interviewed 3 people, 2 with daily work in these spaces
  • worked on the outlines of our pitch decks

We narrowed down Step Three’s offerings to three:

Recruitment Package: We will review all of your job postings to ensure you are attracting top candidates.
Handbook & Benefits Audit: Ensure that your handbook and policies have the right guidelines for your business.
Culture and Retention Package: Create a mentorship pathway within your company.

Recruit. Retain. Recognize. 

Two weeks ago we made some lo-fi Service Blueprints for all 3 concepts. Here’s an example of the one we made for Step Three:

Service Blueprint: an operational tool that describes the nature and the characteristics of the service interaction in enough detail to verify, implement and maintain it.

We focused on what artifacts were used, who used them (customers or employees), where they used them (customer-facing or nah, aka front-of-house or back-of-house) and how. It was helpful in that it really made us think about every aspect that goes into creating and planning these concepts. One challenge we discovered is that when you don’t really have a complete concept of your business, it’s hard to build one of these.

NEXT STEPS: As we’ve worked to flesh out our ideas for Step Three, it will be super beneficial for us to build a separate service blueprint for each of the three services we’re offering. If we don’t do that in the next week it will be one of the first things we do in Q4. (As well as updating our lean canvases for each service.)

Ch, ch, ch, Changes

This week the team of Kelsey Greathouse and Sara Miller had a busy week of continuing of developing our concepts and developing physical representations of those concepts. We have three major updates on our progress.

Update 1: Decision to Not Persist with Our Network Nearby Concept


We made a tough decision to not move forward with one of our concepts. We gave each idea a score of 1-5 in the qualities of each being: financially viable, viable to get off the ground in the timeframe we have, amount of interest expressed for the concept in our interviews, and personal interest in the concept. From there we added up the scores of each and ultimately, LaunchPad and Casa had the most amount of points by far.

For many of these qualities of Network Nearby, we had put a “?” where the others had actual values. In our initial interviews for Network Nearby, we uncovered a deeper problem than the one that we had initially hypothesized: that in order to feel empowered to “network” people must first feel they have value to offer another person or business. Our initial concept of a networking app solved the problem of making it easy for people who already wanted to connect to do so, but the population we most hoped to reach (individuals looking to build a community or learn about alternative career paths) often did not feel they had value to offer to relationships, so were not seeking that out.

In short, moving forward with the concept would mean conducting more interviews to better understand the problem space so we could have a better idea of what a product would look like. And, as a team, we worried that another week of interviews in a problem we were excited about but without a solution would set us back on our other ideas.

This is an update of our business plan for our new model!
This is an update of our business plan for our new model!

Update 2: Adjusting Concept of Launch Pad


Deciding to move away from our Networking Nearby opening time and mental space to focus on our other concepts more. In that time and mental space, we took another look at both ideas. After synthesizing the information we learned in interviews, we realized that there is a broader need to help people in one career path be able to see the pathway towards a different career path. This allowed us to be able to remove ourselves from our initial concept of a website and consider other solutions that did not fit within the confines of a website.

We had heard in an interview with a recruiter last week that her company will often look for former teachers to be able to fill the role of recruiter. We were interested in this thought process and hoped to dive into what might allow a teacher to be a successful recruiter. What skills does a teacher have that could translate well to recruiting? What are the gaps in their skills that they needed to fill on this own or that this company filled with onboarding that would make them successful?

Simultaneously, we were attempting to find a way to scale our idea down to be able to create something that would be truly effective. We had learned a lot about what recruiters look for in hiring interviews and in reviewing applications as well as how they value alternative education. Considering that teachers are a population of professionals who have a specific skill set and some may be looking to make a transition, we decided to focus on them as our customer segment.

This allowed us to generate a product that specifically served them. For it, we came up with a personalized summer workshop series that helped teachers gain everything they needed to effectively transition into a career in recruiting by the end of the summer. It will be an a la carte service where teachers pay for a consultation and then are essentially given a curriculum of classes to take over the summer based off of their individual background. We then partner with companies who hire graduates of our program and we are given a percentage of their salary as payment.

This upcoming week we are going to connect with teachers to see if they would be interested in a program like this. We also hope to connect companies to see if they would have interest in partnering to hire graduates of such a program


Update 3: Service Blueprints


After deciding to release one of our ideas and reframing another this week, we sought to delve a bit deeper into the ideas to create service blueprints. Service blueprints are used to map out the interactions a user has with a service or a product. Thinking through each of our two ideas, Casa and Launchpad (v2), we started by posting sticky notes on our boards with the process of each.

In creating a service blueprint, we were required to breakdown each service into stages of consumer use. From discovering the product through use and even after use, we mapped out what the user experienced during each stage, what interactions they would have with the product, and what back of house work did we need to do to make these things possible.

This is our service blueprint for Casa
This is our service blueprint for Casa.

We quickly realized just how complex our ideas were and each category quickly became quite granular in interactions. Both ideas will require many resources, a lot of time, and a lot of manpower to make happen. This exercise provoked questions of how we would scale our ideas, what are our MVPs ultimately, and how we may be able to begin to build with 20% of our MVP to scale properly.

For our digital renderings of the process, we sought to simplify the larger process and look at bigger buckets of interactions to give a more clear overview of how someone uses our products.

This is our service blueprint for Launch Pad,
This is our service blueprint for Launch Pad,

How you can help!

We are hoping to connect with…

  • Students currently enrolled in bootcamp programs
  • Employees at bootcamps
  • Teachers interested in transitioning out of teaching
  • Companies looking to hire recruiters

If this sounds like you or anyone you know, email us at or This is an opportunity to be a part of the development of our products in the beginning stages and would love for you to be a part of the process for as long as you would like!

User Testing for a “2 in 1” Bank & Budget app

Create, Test, Revise, Repeat.

Our assignment this week was to create budgeting features to our banking app.

Paper prototype
Draft paper wireframes

1. CREATE: Make Prototype of banking app as a clickable wireframe

What I made: First I drafted out wireframes on paper. Then I made screens using sketch. The final step to make the prototype ready for user testing was to make it clickable. I used InVision to create hotspots between the slides.

One thing I learned: There are advantages to starting with paper wireframes rather than drafting digitally on sketch. For me, paper wireframes is less about drafting a visual and it is more an exercise to force me to create an exhaustive list of the possible components. Also this is helps to identify which components are repetitive enough to be a symbol.  I am still learning how to systematically build a robust and organized symbol library for an app. Once I figure out what works for me, then I can edit and create new screens faster.


Screenshot 2019-02-15 23.38.38


2.  TEST: Do usability testing with prototype

How I tested: Utilizing talk aloud protocol, I observed users click through the prototype. I gave users a prompt for each flow. “So you’ve always wanted a dog and you decide one of the first steps is to start setting aside money. Your user goal is to see how much is in your savings. and second is there a way to start allocating money for this “puppy fund”. My objective was to see if the terminology I chose was easily understood. I used phrases like “safe-to-spend”, “Add Savings Goal”, Set aside or Save by a date” terminology of savings verses savings goals. I wanted to make the prompt vague enough that the user did not think there was only one correct answer. 

One thing I learned:

For mobile apps, test on the device not on a desktop. I downloaded the InVision app on my personal iPhone and handed it over to users for the testing session. Even though my screen is small (and also cracked) I learned more from the user. I can see if they use any tap gestures. Also if the app lay is readable on the screen.  even though small could learn more and have gestures. t the beginning of the interview I explain to the user that I will give them a goal and I will see how they click through the app. I emphasis that I am not testing them to see if they get the goal correctly. If anything I am testing the app to see if it is intuitive. Also I reiterate to be complete candid and it won’t hurt my feelings; if anything it will make my project better.

3. REVISE: Identify the major problem points

What problem points were identified? The icons to represent savings and expenses. Both users need to slowly save up for, but in my mind expenses are for recurring transactions like rent, insurance, phone bill etc. So I chose a icon that looks like a calendar. While savings is for more one-off purchases. I picture savings as a locked vault of money that is off limits from spending. So I chose an icon with a lock. Most users understood the icons, but only after clicking around the app. One user thought that the funds were like a CD which you cannot access at all. To revise the icons I will put labels under the icon when it is selected. So it is quicker for users to learn what the icons are associate.

One thing I learned: A big picture takeaway was that inherently a budgeting app is super difficult to create because each user has a different mental model of what budgeting should be. Not only does a new user have to learn how to use the app but also they must learn how to think about their finances differently. Users first have to understand best budgeting practices before they can fully utilize the apps features. So how can we design something that can incrementally teach users while they are also using the app?



Stay tune next week I will make revisions based on the user feed back


Down-selection, Focus, Reflection

This was a pivotal week for Kim Nguyen, Kay Wyman, and me. We made the executive decision to focus our Capstone efforts on just one idea moving forward. That idea is Me Mentor, a system for creating, tracking, and reflecting on personal goals.

The Problem

Based on our research with post-traditional students (specifically, students that must hold a job to pay for both school and life expenses), we learned that the incredible stress of balancing immediate needs with future professional goals leaves students with little time to reflect on the ‘why’ and ‘how’ of successes and failures. Working a full-time job while attending school part- or full-time is like living two lives with the time that’s allocated to one. Many tools exist that help people keep track of their aspirations, but these tools often focus solely on the goal itself and whether it was achieved.

Reflection is subjective. It requires a person to look at their experiences retrospectively, and hindsight isn’t always 20-20 between people who observe the same stimulus. Every experience is unique to the individual, due to the cumulative nature of experiences — new experiences are shaped by context and past experiences. To quote John Dewey,

“we live from birth to death in a world of persons and things which in large measure is what it is because of what has been done and transmitted from previous human activities.”

Our Solution as a Service

To illustrate our current vision of how the service will work, we created a service blueprint. A service blueprint is a diagram that visualizes the relationships between different service components — people, props (physical or digital evidence), and processes — that are directly tied to touchpoints in a specific customer journey. Shown below is the first iteration of a customer journey for Me Mentor, which involves a method for setting and reflecting on goals and personalized coaching on how to use the insights from reflection.

Lo-fi Service Blueprint

Pitching Our Idea

Over the past week, we have also been working diligently to create two cohesive narratives: one that appeals to potential investors and one to attract our target audience (individuals who are strapped for time, leaving little room to reflect on their goals if they even had the time to create them in the first place).

The most difficult element of our pitch deck to investors has been to figure out how to be profitable with the model that seems to bring the most impact to our target audience. We envision a coaching element, but a personalized touch makes scaling up a tricky task, especially in our increasingly digital world. Some of the assumptions we’ve made govern:

  • Initial customers
  • Customer growth rate
  • Subscription price
  • Website build and hosting
  • Labor costs
  • The rate at which we would need to hire help
  • Marketing/advertising

Under our current assumptions, we would need to charge a price that would potentially alienate our customer base, especially those in school living paycheck to paycheck.

We continue to test our prototype with two users.


One user has needed a lot of attention which worries us for a couple of reasons. First, it could possibly reflect the amount of coaching a client needs/expects. The more time an individual requires is inversely proportional to the number of clients we can manage without hiring help. Secondly, it could parallel the level of attention for a wider audience. If customers don’t see the value of our product (or simply get bored with it), we will have trouble with client retention.

Next week we plan to:

  • reach out to more people in our target audience to test the prototype,
  • continue to test our hypothesis that people find reflecting on successes and failures beneficial and will pay for a service that coaches them through a process of creating goals and chopping those goals into smaller, more manageable milestones,
  • refine our business plan to maintain the level impact we would like our product to have while increasing profitability, and
  • begin planning a pilot to test over the next eight weeks.

Mental Model Match

For our latest assignment in Designing Digital Interfaces, we were tasked with merging the traditional functionalities of a banking app to offer additional capacity for financial modeling. This meant that we had to take our existing banking app designs and integrate new functionalities in a way that felt seamless and intuitive for users… and then test to see how well we had done.

I tested my design with five users ranging in age from 26 to 36. I again used the “think aloud” style of testing in which I had users talk through their experience as they tried to accomplish a few outlined tasks (or “flows”) within our banking app designs. I tested users both on my computer and on cell phones and learned that I much preferred testing users via mobile phone because the experience was that much more true to form with an actual use case. 

users seek charted territory
When experiencing an app for the first time, users look to find new functionality in familiar places.

My test users were familiar with a variety of banking apps and a few also used financial modeling or budgeting apps like You Need a Budget. During testing, I learned that it’s helpful to chart more than just one path for a user to achieve the desired task. Users who were less experienced with budgeting apps tended to look for new functionality via “tried and true” mental pathways. 

My other significant takeaway from user testing was more generally about the value of testing your design with real humans that aren’t yourself. Your app may be your baby, but if it can’t match to your users’ expectations then it won’t grow into a successful business venture. Streamline your design to meld with user expectations such that the user can intuitively navigate through your app’s features and functionalities.

mental model match
Takeaway: Match the user’s mental model

The final step in our journey with Designing Digital Interfaces will be to revise our wireframes based on our experiences in this final round of user testing. I look forward to updating my wireframe designs and flows so that they are as intuitive and streamlined as possible!

Impending Doom & The Future of Design

Yuval Noah Harari
Yuval Noah Harari, author of Homo Deus: A Brief History of Tomorrow.


I would like to tell you about a book I’ve just finished. It’s one of the finest books I have ever read.

Reading this book also bolstered the belief that I’m in no position to make the previous claim. I’m a human, a fledgling designer, and a biological creature. Which makes me a product of evolution, prone to cognitive dissonance, and recency bias.

The implications of these faulty human traits become clear in Yuval Noah Harari’s Homo Deus: A Brief History of Tomorrow. But more than proving we’re faulty creatures, Harari’s thesis should resonate with anyone who has a stake in design.

Humans, Just Another Animal? 

Harari is a historian, a realist, and most likely, atheist or agnostic. He contends that humans have dominated the planet due to our creation of fictions.

Our fictions are the fuel that propels our dominance on the planet. These stories define our uniqueness within the animal kingdom: the ability to organize in groups far above 100. The utility of money is a tangible example of a shared global fiction. A $100 bill is a piece of paper, but we all agree on the fiction that it has value.

Harari details how our ability to organize under shared fictions has led to the Anthropocene, the current age where human activity is the dominant force on the Earth’s environment. But it’s not only the Earth we’re changing.

We’re beginning to modify our genetic code, we’ve extended our lifespans, and we can ingest mood-lightening pills to ease our worries. Harari writes that as we reshape our biology with greater precision, it’s the old and new fictions that will guide what we create.

Huxley, Orwell, and Atwood all warn us through their literature that as we gain greater biological control over ourselves, we’ll lose our humanness. But maybe those warnings aren’t predictions just yet. Today, mitigating depression with an accurate dosage of chemicals has made life livable for many people. The trouble, Harari writes, is that our scientific developments in the life sciences (biology, behavioral economics, cognitive psychology) are quickly eroding the dominant shared narrative most of us live by.

You’re a Humanist, Like It or Not 

The dominating narrative of our age is humanism. Most of us have grown up with a feeling that “I am a unique individual with a clear inner voice that provides meaning to the universe.” Humanism sanctifies life, happiness, and the power of Homo Sapiens. It’s a story that says, “It’s up to me to choose what is right, what is art, what ice cream is best.” It also says “It’s up to you to choose the same for yourself.”

“Feelings” can have a very touchy-feely connotation, but it’s also humanism that fuels capitalism, choice, and our sense of freedom. It’s what legitimizes voting, and urges us to seek more equitable justice.

And it’s here that Harari’s warnings begin:

The humanist belief in feelings has enabled us to benefit from the fruits of the modern covenant without paying its price. […] What, then, will happen once we realize that customers and voters never make free choices, and once we have the technology to calculate, design, or outsmart their feelings? If the whole universe is pegged to the human experience, what will happen once the human experience becomes just another designable product, no different in essence from any other item in the supermarket?

We’re Walking, Justifying, Narrative Machines

If you’ve ever concluded that humans are irrational and fickle, you’ll not find much argument from Harari. What sets his writing apart is how he synthesizes scientific developments in light of our ancient human fictions.

A few of the unsettling scientific developments in irrationality:

  • fMRI scanners have proven your brain makes decisions before you’re aware you’ve made them
  • Split brain experiments have shown that humans are experts in cognitive dissonance, sliding into rational explanations even under bewildering circumstances
  • Behavioral economics has shown humans “narrative self” consistently overpowers our “experiencing self,” which turns the irrational, unpredictable choices we make into the illusion of a coherent, individual story (referred to as “System 2” in Daniel Kahneman’s terminology)
Daniel Kahneman receiving the Presidential Medal of Freedom. Many of his experiments led to the conclusion that we have a "narrating self" that makes justifications inconsistent with our "experiencing self"
Daniel Kahneman receiving the Presidential Medal of Freedom. Many of his experiments led to the conclusion that we have a “narrating self” that makes justifications inconsistent with our “experiencing self”

Dear Algorithm, Tell Us What To Design

Most of us don’t design by religious guidelines or by a dictator’s demands, we design for an environment where individuals are free to choose: my barstool or Ikea’s, your app or Apple’s. We believe in choice, and we design knowing there is a choice on the user’s end (most of the time).

Harari foresees a conflict here. On one side, the humanistic legacy and individual choice. On the other, the developments of science and technology, along with the rise of algorithms which increasingly make choices for us. Harari writes: 

Humans are relinquishing authority to the free market, to crowd wisdom and to external algorithms partly because we cannot deal with the deluge of data. In the past, censorship worked by blocking the flow of information. In the twenty-first century censorship works by flooding people with irrelevant information. […] Today having power means knowing what to ignore. So considering everything happening in our chaotic world, what should we focus on?

This leads me to imagine a loop that will impact designers at a high level:

  • We’ll continue to design based on witnessed human behavior, but will have to fight louder for a voice among the screams for large quantitative data
  • Big data collection and the algorithms will increasingly affect what gets made
  • What gets made = what gets used
  • We’ll increasingly study human behavior that’s created or influenced by algorithms

Pessimistic enough? I suppose Harari brought it out of me. But his book isn’t simply pessimistic. It’s an exercise in reflection and an attempt at broad foresight. More optimistically, it helped me gain a sense of the big picture of creating things for fellow humans.

Are we in danger of designing for “data fiends” who may trust algorithms over individual feelings? In reaction maybe we’ll design for the opposite, an “intentional ignorance,” or peace of mind that purposely avoids the prescriptiveness of data. Perhaps the data will show us more clearly our cognitive dissonance and we’ll act differently, more efficiently, or even more ethically.

Whatever we’re called to design, we should recognize the fictions we’ve been operating on, and act on the the stories we want told in the future.

Banking with Financial Modeling: A Student Redesign Project

Over the past two weeks, my classmates and I had set out to take feedback from users who played with our first rendition of a mobile bank app that we each design, imagined ourselves as working for a bank that was acquired was tasked to add financial modeling elements functionalities to our bank app. Mint one example of financial modeling. I’d like to share with you the journey I took to develop the idea and design, what I set out to learned and the things I discovered along the way.

The Process

Redesign Guidelines.

Just before this project, I had conducted user testing on the last iteration of my design. From that research I took my learnings about user motivation, habits and made a guideline of what to include in my next revision. Those guidelines were as follows.

  • Regarding UI and Copy
    • Use less icons, this was more distracting and created a busy feeling rather than informative
    • “forwards/backward” should be indicated with a specific call-to-action language, avoid image and generic language (i.e. review, back)
    • move navigation items in the same hierarchy. user’s prior experience demonstrated that this is best at the top left of the screen
    • Physically separate navigation links and buttons from confirmation targets.
    • a bank app should be visually clean, simple and information dense but still concise to only the most pertinent and supportive of what the user is trying to do.
  • Regarding User Experience
    • Users want to have control and flexibility over security
    • Users want the experience to be immediate and reassurance that what they are looking at is up to date and accurate
    • Be attentive to the detail of flow, messaging and accuracy of what is being displayed, the slightest confusion will immediately lead to distrust because this is a banking app.

Learning User Expectations of Financial Modeling  + More Guidelines

Financial modeling is not something that I am too familiar enough. To gauge what the what user’s the prior experience of a financial modeling app looks like I set out to analyze an existing app,  Mint,  and created a concept map of its functionalities. I then reviewed the concept map and isolated the core functionalities based on the following elements I was trying to integrate.

  • provide a snapshot of your finances and their trends
  • allow the user to analyze any specific transaction in any account to see if it is historically anomalous in
    the context of all of your spending
  • provide a simple “what if” modeling system based on “playing with” your recurring
    payment amounts, so users can see how changes in monthly spending impact your account
  • help the user figure out what amount of money is “safe to spend” at any given time.
  • Include the original banking functionalities that I had designed for originally
    • the ability to make a deposit
    • the ability to check one’s account balance and see the transaction details

The Re-Design + Build Out

The Fuzzy Front End & Creating a Process Flow Diagram for Clarity 

This is the fuzzy front end. It was a struggle to just ‘know’ what to put together and how. The earlier guidelines help me with what features should be included and how should the details be but I was still missing something to move this forward. In developing the process diagram I quickly learned the missing piece was a ‘why’. It was not until I was randomly piecing feature and elements together that I was able to start speaking to why they feature or elements should exist together.

A few squared and diamonds into it, I decide that my overarching goal of the app should be to test and see if an app when well designed, can provoke people to consider more frequently and in depth about their long and short term financial wellness. If the app can do this and also provide a simple to use tools to take steps to improve or maintain financial wellness.

Sketch for Direction & Digitized Mock-Ups

As I was mapping the process flow, I would make rough sketches of what the screen could look like and laid out what information should be included on the screen and how that information was best laid out.

In going between the process flow mapping and the hand sketched, I was able to see in real time if an idea of which pieces information, feature, and diagrams play well on limited screen size. I was also able to put the screens to and features I was building out to the litmus test of me overarching and functionality goals.  Something that wouldn’t fit nicely on a single screen, or made the screen too ‘busy’ was a great signal that I needed to revisit the grouping, and break down the ideas into something smaller.

Once I was happy enough I moved onto digitizing the screens in Sketch. It is important to emphasis ‘enough’ because I have learned that when it comes to doing something creative, it is SO EASY for me to go down a rabbit hole in the details. The focus of this step was to have a high-level flow, with details in the layout and functionality and some copy, but not the icons,  font. That stuff comes later.

The Wireframe

A lot of change happened between the last iteration and this one based on user feedback and lesson’s I’ve learned. As a designer, and research I made my process in developing the idea more robust, and focused on the details of the flow and if that ties back to my overarching goal for the users. As a researcher, I focused less on the details of what the user was going to see, and more on the flow of how the users can step through the mockup, this meant less time spend on screen to screen actions and more time focused on what is the least number of steps that a user has to take to achieve the task I will give them during user testing.


In regards to the actual design the changes I made were:

  • apply a structure and pattern to navigation
    • banking options in a menu at the button so navigation can happen single-handedly
    • back buttons at the top in the same spot
    • there is the main screen have a banking menu and pages that go into detail don’t
  • make the screen more simple and clean by
    • using mostly white and with just some specks of color on only the elements that are prioritized
    • User good copy over icons for navigation
    • icons have the same style
  • make information more prominent by using models when necessary to explain something to a user to get their attention

Here is the results. Click here for a larger more details view of the screens.

Screen Shot 2019-02-14 at 9.07.45 AM

User Research

Interviews and Research Objectives.

While I was digitizing, I had made simultaneously arrangements for scheduled user testing. This helps give me a hard deadline to complete me digitizing and remain focus and avoid those detailed rabbit holes.

In my user research I had set out to learn the following:

  • a user’s banking and financial planning and assessment behaviors
  • what are a user’s banking and planning goals
  • what do users plan for? what motivates this person’s financial planning
  • do user already have a tool to help with monitoring or making budgets. If so what is it?

I think testing the design using the Talk-Aloud method where I would give user prompts and ask the user to talk me through what they are doing and I would occasionally ask them to elaborate on why.  This method allows me to listen in on how the person thinks about finances, their expectations, and reasons for disappointment and enthusiasm. By getting a glimpse of this, I could better understand what flows and elements get people excited or make them anxieties.

Screen Shot 2019-02-14 at 9.07.28 AM

Testing Results and Lessons Learned


Testing Results and Recommendations.

During user testing, there were three key screens that proved most problematic. Here are the problems and recommendations I would make.

Screen Shot 2019-02-14 at 9.43.50 AM

Screen Shot 2019-02-14 at 9.43.58 AM

Screen Shot 2019-02-14 at 9.44.06 AM

Screen Shot 2019-02-14 at 9.44.15 AM

Screen Shot 2019-02-14 at 9.44.23 AM

Screen Shot 2019-02-14 at 9.44.29 AM


Lessons About the User.

Screen Shot 2019-02-14 at 9.44.38 AM

Lessons on Being a Research.

There are some things in my control, i.e. presentation, some of the setting and my mood. There are something out of my control, i.e. how I am received. This came up when I realized the effect my voice has on other people. I have what I like to call a ‘sultry’ voice. It can be deep. So, when testing with women I noticed that they would often look to me to the direction which would affect the research data. Knowing this I paid extra attention to my tone and tried to lighten it, as well as be very intentional with my diction. In one example a user would as me “Is this what I am supposed to click? I don’t know” and I had responded with “What do you think that thing should do?” This did not help the user feel more confident in taking control. It was only after I asked questions with less room for negotiating a conversation that I get better results. In this last example, I started to ask “What is this screen telling you?” over “What do you think this that thing should do?”

Lessons as a Working Designer.

I found that a lot of my ideas of how elements should act on a page limited by the tools I was using. In one example I wanted a certain sorting bar to stay constant even as sections of data can be scrolled through have still had that sorting bar apply to that newly displayed data. This proved most challenging in Sketch and Invision.  My compromise was to apply that bar multiple times per data section. Looking back, this is not something I would hand over to a developer and ask them to build it based on the mockup. I would prefer to do a manual demonstration to  show the developer what I was aiming for in the design.  So in conclusion, DON’T rely to heavily on tools, they limit your vision to their features and offerings.

Another thing I realized was how inconsiderate my design can be to a developer. If this a project that I would like to see the light of day, I would integrate a developer earlier in part of my design process and ask them to talk me through parts that they imagine diffuclt to build and why.

In Conclusion

I still have mixed feelings about this project. There is no doubt that I learned a lot from this, but there is part of me that wishes There was more time to brew over the design ideas, the reasons for doing, and the benefit of the app at all. It’s cool to make something a tinker with it and learn as you go, what I would like personally is just a little more time to sit and take in all that has been achieved. I liken this project to a sprinting marathon. That is when you have to run top speed for a full marathon. It’s not a thing, but it can be! I know in the back of my mind that there is a payoff, and there is something to be achieved but it’s hard to enjoy it while you are doing it, because well, I’m not an Olympian or an expert UX designer with slick wireframing skills (yet).

Adding Analytics to a Mobile Banking App

We’ve been focused on creating screens and redesigns for a mobile banking application for the last few assignments in our digital interfaces class. This new assignment threw us a curveball. The prompt was to imagine that the financial institution we’ve been working with has recently merged with a company that specializes in financial analytics and modeling software. Our challenge was to integrate this new technology into our recently redesigned mobile banking application and test it with users.

Finding Inspiration

The first thing I did was look at a few existing budget and money analytics tools that currently exist. I used Mint a few years ago, so started by re-logging into my account to review how they have it set up.  I know that many people really like mint, but it never really worked for me and always felt kind of burdensome. I’m also not a fan of circular graphs and charts so in reviewing mint I knew I wanted to do something a little different than what they have created. Next, I thought about applications that I really love and ended up opening my Airbnb app to review how they have it set up. Despite it not being a banking app, I found it really useful in how straightforward and clear they present information, and place emphasis on providing users simple tools and tips to improve their bookings or activity. These were both things I wanted to include in my screens.

Testing Methodology

After creating my screens I sat down with 5 users to test the functionality and see what they thought. My goals were to make screens that were clear, intuitive and made people feel like they had the tools to improve their budgeting/spending/saving if they were so inclined. To do this I asked participants to use the think-aloud protocol. This is similar to a stream of consciousness where the testers talked me through exactly what they were seeing, thinking, and doing. Using this method helped me understand the why behind what they were doing.

The four flows/tasks and the screens involved.
The four flows/tasks and the screens involved.

Testing Results

I found that I hit that mark with some things, but missed on others. Overall, testing really helped me see where I could make edits and improvements in my design.

Monthly Budget Overview Screen
Monthly Budget Overview Screen

For example, Flow 1 and 2 the user goes to their monthly budget overview screen to better understand their spending for that month and see if it’s safe to spend $200 they weren’t expecting. This screen came across as overwhelming for all my users. Being struck with lots of numbers, a math equation, and a graph all at once was too much. Additionally, having the safe to spend amount in the top right corner was not very noticeable, and the legend for the graph was missed by many participants. To solve these issues, my thinking is to either remove the equation at the top of the page (since this information is also in the graph) and the legend. Then I will add labels next to the call out of the amounts on the graph and when they are clicked an additional info popup will appear to explain more in-depth what these numbers mean if a user is interested. This should make the screen cleaner, and more approachable.

Things that users really liked about this screen was the clear status indicator at the top and the smart filters at the bottom. All my users thought the smart filters were great and said they would use them frequently instead of filtering through their transactions looking for certain things.

Anomalous transactions flagged by the app with spending insights.
Anomalous transactions flagged by the app with spending insights.

In flow 2 users were asked to look for transactions in their checking account that the app may have flagged as anomalous. Every user first looked at the amounts, then the recurring buttons, followed by the entity name label, and then finally found the information button flags. In my next iteration, I plan to move these buttons to a more noticeable location and change the icon to be more of a flag instead of information.

On the message screen almost all the participants were surprised that the message was related to their spending habits instead of a fraud security alert. Some said they appreciated it, but the general consensus was that there should be an option to have control over what gets flagged and the messages they receive. Many also said they would expect to see any important messages when they logged in, and not have to go search for them.

Click here to run through the wireframe flows yourself!

What I learned about testing

I learned a lot about the value of user testing, and what makes it run smoother.

  1. Scenarios and the wording used in setting up tasks for users matters. For example, in flow 2 where users were asked to look for flagged transactions, the wording became very important in differentiating that they were looking for potentially fraudulent activity or just transactions that were out of the ordinary for their spending habits.
  2. The more mundane the context information the better. I found that testers can easily get distracted by filler information in wireframes, especially if it’s not believable or stands out in some way. For example, on one screen I created savings accounts for dog savings and fun money just to show that a user might have multiple accounts to choose from. Labeling these as “dog savings” and “fun money” caught people’s attention and distracted them from what they were doing.
  3. Test with your mobile device, but turn the lock function off during testing. I found it really helpful to have users test the mobile app on either theirs or my mobile device to the functionality felt more real. However, I did not turn the sleep function off, and it became annoying to keep having to unlock the device throughout the testing session.



A+FCU Banking App + Financial Modeling Capabilities

In our Designing Digital Interfaces course, we’ve been working on integrating financial modeling tools into a mobile banking application of our own design. I’ve been working with my own redesign of the banking application for A+ Federal Credit Union, a local Austin credit union primarily serving education employees. Within the expected functions of a banking app, the financial modeling features that I’ve integrated include viewing a quick overview of financial status (income, spending, and upcoming bills) and a deeper view into spending habits. I’ve also added functionality that allows users to view what amount of money is safe to spend at any given time, including the ability to set a ‘reserve’ amount and add notifications for nearing and exceeding a ‘safe to spend’ amount.

Financial Overview Flow
Financial Overview Flow
Spending Habits Flow
Spending Habits Flow

I created wireframes for 2 separate flows which I then tested with 4 participants in their homes. For background research, I asked participants what bank they use, what budgeting tools (digital or analog, if any) they use, and what their primary financial concerns are when thinking about their budgets and spending.

My participants, who ranged in age from 22 – 40, were asked to accomplish 3 tasks for each wireframe flow. My primary goals were to understand how users navigated through the different financial modeling tools, how easy it was for them to understand the categories and vocabulary assigned to the tools, and what functionality they felt was missing.

I discovered a number of problems throughout the wireframes and flows I constructed, but the most prominent problem is in the structuring of the features within the system (information architecture and navigation) and the headings used to describe them in the menu, where most of the features are currently located. Users had differing interpretations of what information they expected to find within each category heading, but no single user was able to navigate quickly and easily to the correct place.

flow problem 1.001

To revise the screens, I intend to consolidate the ‘budget tools’ categories into one ‘finances’ bucket and nest that within ‘transactions.’

Another problem that I discovered is that the categories in the ‘total spending’ visual are not quickly interpretable. In its current form, a user would need to click on every slice of the visual to know what category it refers to.

flow problem 2.001

To revise this, I intend to add a clickable legend to the visual, both to make the visual tool easy to quickly access, but also to give users an alternative path to navigate to individual category transaction details.

Our original assignment in the course was to redesign a banking app. Through this exercise, I got my first real taste of wrapping my head around information architecture. It was difficult, but because my redesign focused on the app’s core functionality, it made sense to place links to key tasks on the home screen, where users would be most apt to need those functions.

When it came to integrating the financial modeling features, it was challenging for me to decide how much of those features to integrate where it would be highly visible to users, but not take up precious real estate needed for core functionality. On the other hand, I was wary of isolating and hiding all the financial modeling tools in nested menu areas where users weren’t apt to ever find or utilize them. To add to this, of the 4 test participants I spoke, most don’t use budgeting tools (1 participant uses rarely), although they all expressed the feeling that they should and would like to. That leads me to feel even more strongly that key pieces of budgeting features should be established on highly-accessed core areas, but link to more robust sections of financial modeling, to allow users to dive deeper as they see fit.

flow problem 3.001

Another key takeaway from my testing was how important context is when considering usage. I tested my apps in users’ homes, which gave me an appreciation for their lifestyles and needs. While I was working with Keara, a single mother of a toddler, her son was making his disapproval of us known, and known loudly. He was tugging at her, vigorously inspecting my camera equipment, trying desperately to tap the computer keyboard, and eating post-its. In the middle of the test, she turned to me and said,

“See, this is good for you to have someone who has a child hanging all over them trying to figure something else out. This is real life.”

Seeing firsthand how distracted, by necessity, Keara was has shown me how important it is for her to be able to find the information she needs from an app quickly to be able to accomplish her task and refocus her attention. If an app requires too much reading or interpretation, she’s not going to want or be able to use it.

After this round of user testing, I’ve identified some key problems with the structure of the information architecture, which I will address first. After restructuring where the financial modeling features ‘live’ and how users can access all or parts of them, I will also revise the smaller, individual problem areas that are caused by poor or missing user interface elements. After my revisions, I plan to test with a new group of users for feedback and further iteration.