Imagination in Design

Imagination and its limits were the topics of concern over the last week. In a past post, I had asserted that self-fulfilling prophecies are not a phenomenon but a human condition. This is because of the concepts of Psycho-cybernetics. In short, the concept of psycho-cybernetics states that the human mind once introduced an idea will continue to work on that ideas until it reaches its goal or solution.  Some ways we see this play out in our day to day are things like when we lose something and we ‘miraculously’ remember where it is later.

At the same time, the way we talk about the worlds impacts the ways we perceive and interact with the world. In a study looking at the way language and one’s thinking relates, “UC Berkeley cognitive linguist George Lakoff has proposed that the way we think about concepts is fundamentally metaphorical. In other words, we don’t simply talk with metaphors, we think with them. We rely on what is simple and familiar to us, like money, to understand what is more complex and distant, like time.” (Metaphors can change our opinions in ways we don’t even realize by Steve Rathje).

This has implications on imagination and its limits. Much of our language has a tone ownership over ideas. For this reason, we limit our own thinking because we have shaped our minds to believe that ideas are one of a kind, hard to come by and creates a fear in us to push boundaries. Our culture seems to have an obsession with the concern of ideas and imaginations being a limited source.

One way we can jumpstart this short on our imagination juices is through play, and reframing our understanding of the world. When we grow up we assume that we stop playing because we have seen this behavior modeled to us. But by not playing we stop learning. But what if we continue to play, explore and not allow social behavioral expectations to hold us back.

Making delightful things to stretch the boundaries of our imaginations, which in the long run can serve to help reshape our culture and behavior in a way that conditions us to be better to one another.

Reflections on Building a Feature Brief

The Back Story

Over the last week and a half, my AC4D classmates and I learned about a communication tool called a feature brief. It is precisely what it sounds like, a living feature brief explanation of what the design is, use to share the design you put together with anyone and everyone involved in building a product. The intent of a feature brief is breadth, a high-level walkthrough of a product’s features, and why.

What is interesting is that there is an element of still storytelling and persuasion involved, to communicated the value my design could have given the insight I’ve found from user research. I found this to be the most challenging part of the assignment. However, as this is a student project, and a fast pace one at that, I did not have nor did I made the time to consider ‘what is the value of this app I am making?’, ‘why might someone find this valuable?’. So in the process of going back through I realized that the type of testing that was done in the past (user testing), was not robust enough for me to initially speak confidently about the features of this iOS Banking App I redesigned for UFCU. I found myself going back and forth through my past notes from research, past presentations on this project, and repeatedly asking myself ‘Why did I do this again?’

The effort was not fruitless, but it was something that took much combing through my documents and data to write something that I would feel confident and sincere about.

Why a Feature Brief

A product feature brief is most useful as a live document, that is curated for all partied involved in building a product, that is not familiar with the design of a particular product (i.e., legal, developers, marketing, sales, business, other design teams, etc.). I communicated what the thing is, why was it made, what it hopes to provide for the user and the progress of the project. By creating an actual document to share, you literally put into the hands of other an artifact that they can comment on, critique, provide feedback, or make design edits requests. It is a powerful tool for communications and co-creation. It also invites colleagues to become vested by contributing to the design.

Building a Feature Brief

The Slide Deck. I started with place holder slides in a presentation building tool (Keynote). It was easy enough to create the outline of a feature brief: overview, insights references for design decisions, a roadmap, features & their capabilities.

I started with the cut and dry content the roadmap and features & capabilities. The features &capabilities worked out to be the bulk of the slide deck. After all, this is a feature brief. While creating the features & capabilities slides, I would use two guiding ideas to determine how much detail to provide.

  1. Is this a core feature that enhances the user’s experience?
  2. Present a 50/50 ratio of ‘What’ the thing is, and ‘Why’ was it made for a person to use.

I completed as much as I can, and found that they ‘Why’ portion was left blank. To get to ‘why’ I designed the features as I did, I went back through 3 months worth of research, variations on builds, rewatching user interviews & testing recording, and hand-written user testing notes. Here are some of the more useful content that helped me with the Overview, and insight sections and recalling why I made the design decisions I did.

User goals found during user interview and testing.

Screen Shot 2019-04-08 at 6.48.11 PM

Research Result (Key Takeaways)

Screen Shot 2019-04-08 at 6.48.20 PMScreen Shot 2019-04-08 at 6.51.16 PM

Some design recommendations that contributed to design decisions.

Screen Shot 2019-04-08 at 6.48.30 PM Screen Shot 2019-04-08 at 6.48.39 PM Screen Shot 2019-04-08 at 6.48.46 PM

 

Results

I want to share with you a PDF of all the re-research and feature brief build out.

University Federal Credit Union’s iOS Banking App Feature Brief.

Final Thoughts

Personally, when it comes to making anything, I often find myself that I often need to know WHY I am doing the thing I am doing. A huge reason why I’ve quit my job and when back to school to become an interaction designer was because I need to know the reason behind my efforts. Without a concrete product in hand, and people using it and providing real-time feedback it was so easy for me to become paralyzed every time I sat down and tried to put words to these features.

Key Takeaways.

1. Not having everything, is not the same as not having anything. Don’t be so quick to poorly judge the quality of all the work you have done so far when you can’t find all the answers you need immediately. I need to remember that I did have a reason in doing what I did so far, and need to go through all the foundational work I have done so far to remember the value I was trying to create for users.

2. Keep sharing reflections after every design stage. Presentations that include key takeaway, insights, and results are SUPER helpful to be able to keep track of all you did and why.

3. Adding slide numbers is the first thing you need to do when building a slide deck. After creating a clean feature brief that I was proud to share, and getting it printed, I found that forgot to add slide numbers for my audience to follow along! It was a bit painful to see considering how much attention to detail I paid to all other aspects of the brief. I’d imagine it would be what J. K. Rowling had published her first Harry Potter novel and found that they misspelled her name to be JK Rolling. All that effort and messing up on a small detail can affect the way your audience experiences what you made.

What I would do differently.

  • Include in my user testing, more robust interview questions to understand what makes a user tick, what they find valuable in the interaction I am designing. I would do this without any prototypes for them to play with so that I can learn about them, without the influence.
  • Maintain my research results, key takeaways after each phase of the process, user insights, and results from the process. It is a great way to track the work that has been done and why.
  • Work on connecting the features more to the insights. Try adding user research results to help sell the design idea.
  • Frame the brief in a way that it is easy to remember what the app does. (i.e. what is the goal? what is the problem to solve?)
  • Treat the roadmap less like a plan of action, and more of a rough estimation of the order of priorities.

Design’s Power

Power. Power is hard to trust, and so explosive.  Growing up, I’ve always associated power with people like my teachers, principals, parents, older sister. Growing up in the Vietnamese community power is strongly associated with roles, and traditionally we rarely even stopping to consider the person in that role. As I grew in size and thought, I was so confused and lost when I was first told that I have choices.  Middle school and high school was the most confusing. Not only was my body being flooded with hormones, new concepts, ideas, and fact but I was starting to discover that there was a power behind my choices. Before that, the only option I had was to either be a good girl or a bad girl.  Up until I was 20, I unwittingly gained the power of authority and choices as life changes. At 12, I discovered the power of opinions, it mostly got me in trouble with classmates, my family, and administrators.  At 15, I had the power of role-model thrust on me when my first nephew was born. I had little purpose, control, and intention behind this power. As a result, the power of authority wained as my nephew got older and realized that I am just as much of a kid as he is. And at 16, I got the power to move, with driving baby!  What was nice about that time was how mostly inconsequential the mistake made were. Where power gets scary is when there is more at stake, more people pay the price, or if the error is not fixable.
For the earlier part of adulthood, I was perplexed if this role attachment to power and authority is something unique to the Vietnamese culture. Over the years I have learned that it’s not. Today, it is hard to ignore the reality that it is the utmost importance for us as individuals to learn the skills to define what is right and proper, to assess the current state of the world and then to diplomatically make a stance to shape the world around us.
As I continue to explore design not just as a practice, but also as a way of thinking — processing information and assessing my actions — there is the pressing question of what is design’s power?  And I say pressing because design, particularly the AC4D flavor of design, is a tool kit that enables you to take in as much disparate information as humanly possible, understand what it all means, define the problem we see, organize and communicate it back to stakeholders in a way is easy to swallow. If done well, we can pull back the covers on issues, and motivate others to act towards a solution. The ability to move people to work should never be something taken lightly.
We have seen and felt the discomforts of our history when it comes to impressing one’s way of thinking and being on another. In one example, we see post-colonial Morocco struggle with their identity as a nation and individuals after the French left in 1956
“After the French left in 1956 and Morocco regained its independence, the divide between the ‘indigenous wealthy’ who had received good services and the ‘indigenous poor’ who received none at all became part of the structure of society. This division left an undeniable impact. At the socio-cultural level, it had severe direct consequences on people’s definition of themselves, their identity and their relationship to urban space as well as to what became later cultural heritage, while ‘modern’ urban space was perceived as superior in opposition to traditional, more functional.”
— Assia Lamzah, Urban design, and architecture in the service of colonialism in Morocco
In this case, the urban architectural design had a direct impact on try created the visual difference in Morocco’s social, economic disparity.  Where design is today, the inequality and effects created by design is harder to see we continue to move into a tech direction. Designers have built such delightful interactions for software, it is hard not to want and need the functionalities technology provides. The last time I went to get my hair done, I pre-paid with a Groupon and then tipped the service provider using Venmo. The ease and convenience of technology have fundamentally changed the way we interact in the real world and shift the way we think.  Recognizing that there is a massive shift in human behavior, it is essential to ask, “Who hold this power? How are they using? What direction are they moving us?”
We have even seen convenience make us handicapped as adults, hence the term ‘adulting.’ As technology grows and develops more products for convenient consumption, we lose the practice of learning how to do for ourselves. I often see this when it comes to food choices. When someone wants to lose weight, they don’t have a foundational knowledge of nutrition and fitness to pull from to change their lifestyle, they download a running app and a calorie counter app. When someone doesn’t know to pick produce, and cook dinner, they subscribe to a meal service plan. I still struggle with spelling, because I learned to write term papers in the age or Microsoft word. Even as I write this piece, I have built-in spell checkers catching my typos and mistakes. Tim Wu says it best in his article “The Tyranny of Convenience.”
“Convenience decides everything.” Convenience seems to make our decisions for us, trumping what we like to imagine are our true preferences. (I prefer to brew my coffee, but Starbucks instant is so convenient I hardly ever do what I “prefer.”) Easy is better, easiest is best. Convenience has the ability to make other options unthinkable.
— Tim Wu, The Tyranny of Convenience
The list of less visible powers is endless when we consider how has designer use their toolbox (aka design) to shape the world, smart decides to track and to report on our behavior and movement, our pattern of thinking and idea, our beliefs, using our own psychology to prevent us from unsubscribing to a service.
Power displaces people and things. This shift causes a cascade of changes to all other people and elements in that environment and reshapes the world, sometimes for the better, sometimes for worse. Design has always played a role in fueling these changes though building things. So does it make design unvirtuous a profession? NO, I think the designer makes design an unvirtuous.  Design is a toolkit, the person using the tools is who shapes the outcome. And No, you don’t get a free pass for not being aware of what is going on. If you are making things, you are responsible. So how does a designer begin to navigate this space of ethics, and responsibility? There are people and entire companies currently working on that.  If you search for the turn design ethics a massive list of products and articles are available for you to pick from.
I’d like to share my thoughts on how to learn to use the power of a designer’s tool kit ethically and not for evil. Power is the ability to move things, objects, people, ideas, groups, feelings.  In its raw form, power is directionless motion. Design is a powerful tool that can be used by both caring and unscrupulous people.  We need to:
  • Ask infinite why’s?  Be mindful of who we are working with to build things, and ‘WHY’?
  • Play the devil’s advocate. When you ask ‘What value is gained,’ you MUST also ask ‘What value is lost?’
  • Move low. Move slow so that you don’t miss critical negative responses to your ideas.
  • Put the kibosh on bad ideas. Ideas don’t grow on their own, they require people to nurture and Sheppard them into the public areas. The moment you suspect there is something evil with your design toss it!
  • Embrace challenge. Adversity and challenging things and ideas only add to your own complexity and ability to understand the world. Sometimes you can only grow and learn by admitting that your cup is half empty.
  • Define What is Good.  The designer is what shapes the impact their design has. You can’t create an impact for ‘good’ unless you have a clear and coherent understanding of what ‘good’ looks like.
  • Continuously Update your definitions. Good and bad is a dichotomous concept. One can’t exist without the presence of the other. So when you are moving through the world taking what ‘good’ looks like, don’t reject what ‘bad’ looks like. Instead, observe it, use it as a resource for what not to do. Then update your own definition of what good is.
  • Expand the narrative. Self-fulfilling prophecies is not a phenomenon, but a human condition. This is because of the narrative we consume and tell influence not just our thinking but each other. When you consume narratives of limited genres you limit your insight on the world.
Entering into the space of design should also come with the requirement to be able to consider, hypothesize about and make decisions based on the potential impact of your new idea. You can bet that what I have written today, will continue to grow and evolve as I journey further into the world of design.  When I think about the potential of design ideas, I am reminded of my friend’s attitude towards teaching children. In telling me about how his 3-year-old son is starting to learn to use the toilet properly, they also told me their concerns about this kid discovering the magic of things other than toilet paper disappearing into a swirling hole of water. Perhaps designers can take a page out of the parenting’s playbook, when you introduce a new way of doing things, always anticipate how it can be destructive, and only then can you start to be a responsible human and designer.

Crafting a Roadmap from Wireframes

A week and a half ago I had shared my journey and lessons learned after I took my redesigned mobile banking app to a mobile app developer for feedback. I walked away taking many of his design advice that would help achieve a more seamless interaction with the app as a user goes to the app to monitor and interact with their bank accounts. One example of a more seamless experience was the removal of the continue button on a deposit screen, instead, the updated design would automatically recognize them with insight and

This past week I was tasked with taking my bank app and plan for its development with some real work constraints. The challenge was to plan out this app’s development over time with only 2 developers working full time for one week. This put me at an 80-hour development budget.

Once this constraint was introduced I quickly had to consider the following, how many features of this design group in a way to make a complete app and still NOT go over my 80-hours of the development budget.

User Value vs Resource Constrained Decisions and Prioritization

Tradeoffs. With the user’s experience and value in mind, it was very easy to treat interactions like magic. You just say what happens to the screen to make a user automatically be taking to the next screen, i.e. when the deposit form fields are all filled out, the user automatically taken to the verification page. While the experience can feel magical, software development does not. This fluid transition came at the cost of more development time, and code to account for when a user wanted to go back to the deposit form to make an edit, but their form is completed. In this example, I had to work with the developer to define a task to add a flag to the account of the edit scenario. Here is the tradeoff I discovered.

The more delightful and fluid user experiences that are included in the design, the more you add to the cost of development.

The reverse is true as well. When I had to consider which 80-hours work of features make up the core values and functionality to make a complete experience. With constrained resources as a focus, some of the screens on my design flow had to be traded out for less magical user experience for the sake of delivering complete user experience. To be able to navigate this some assumptions and decisions had to be made.

Planning Structure

Sprints. Sets of features are built over time at a human pace and a single feature does not make a complete and functional app. In order to deliver a complete and functional thins features are groups and built and delivered in a sprint.

Release & Milestone.  The set of features if a sprint, once complete and shipped, it is released to its audience for use. Each release represents small leaps of improvements in the app. I also made the decision to align each sprint with a sprint goal that will be built towards the app’s overall goal for the user. For example, the app’s overall goal is to make it easy for users to monitor and interact with their bank. I made my first sprint goal be: to build the foundational feature for a user to access the app, and be able to monitor their accounts and a small part of banking. 

Prioritization Process

Prioritizing is a craft, not a science. This process has been invaluable in helping me develop and refine my prioritization skills. To prioritize, I needed to be able to justify the value of one feature over another, but no two features are the same, as it should be. I relied on my app goal, and assumptions made from my understanding of bank app users, as well as my early user research. I outlined Guiding Principles to reference early to make sure that my decisions are consistent and complement each decision before and after it. This would help the series of sprints and releases be coherent.


Guiding Principles: 

  1. Always ask:
    • Does this feature better than the user’s current banking solution (i.e. going into the bank)?
    • Is there a simpler faster way to get the same results?
    • Which features best achieve the app goal?
  2. App Goal to be broken into phases (aka sprints): For a user to be able to monitor and interact with their bank.
  3. A newly implemented feature should be complete in its core function and user a purpose for the user.
  4. Not all parts of a feature need to be implemented at the same time.
  5. If a part of a feature needs to be included I need to consider deprioritizing less important features OR implements a simpler version of the feature that still achieves the same functionality of the original feature.

From these guidelines and my references (user research, other developer and designer’s knowledge and experience, existing application’s implementation) I made the following assumptions:

  • physically going to the bank is not desirable because it interrupts a person’s day and routine.
  • features that make sense to have but are not historically a habit/thing that users use should be de-prioritized or removed. (i.e. users do not have the habit of signing out, there for signing out does not need to be the first thing that users see on a screen)
  • when I am unsure of what typical user behavior or interactions look like, I can always reference existing popular applications to inform what typical user behavior looks like.

Roadmapping

Now that I have guiding principles, defined constraints, and resource to help my decision making, building a roadmap because more like a putting together a puzzle.

I took to google spreadsheets to organize all my features, their details and their estimated hours to build.  I then created columns to assign them a sprint number (which will help decide which features to build get built in the 1st, 2nd, 3rd and so on sprints) and an owner. With the constraint that a single person can do at most 40 hours of development a week, I was better able to define which features go into which sprint. For example, I would start by selecting two or three features that make a complete experience. This is how that list of features shaped out.

Screen Shot 2019-03-27 at 4.36.17 PM

An example of the thought process behind building a sprint. For the first sprint, I identified that a user should be able to, sign in, reset their password, view their account overview and deposit a check.  The reasons behind that were that in banking users need to authenticate their identity and that. Working in tech, I’ve known for users to have ongoing troubles with remembering their password, so signing and resetting passwords have to be shipped together. The ability to monitor one account was the primary goal of the app. After adding all of these features and adding up their estimated outs I had some room to add another feature. I decided to go with being able to deposit a check because the alternative for a user to have to take time from their day to go to the bank. The app will not make depositing without having to go somewhere else san option and clear value add for users that chill received checks for forms of payments.  This includes business and people who work for small businesses that pay in check.  I made the assumption that there are plenty of people that still go to the bank to deposit their check, otherwise why else would teller counters and bank brick and mortars exist?

This first sprint put me just over 80 hours, reviewed each aspect of the selected feature to reexamine which part can be reduced. Resetting password seemed like the easiest place to start because I knew that the bank that I originally made this redesign for has a working website that supports password reset.  So I consulted the developer to figure out of it was feasible to have a screen within the app to point to that web page, and if that solution for password reset would take less time then the original estimate. The new solution worked out to take less time so I took the original design idea out of the sprint and replaced it with this new design idea.

I continued this exercise for the remaining features and would use a release goal (or theme) to makes sure that each release provided a coherent and complementary set of values. This would make the brand of the app seem less disjointed for users who are actively using the app.  These were the resulting goals.

Sprint Goals (themes)

The resulting roadmaps looked like this.

Screen Shot 2019-03-27 at 4.44.50 PM

Mobile Banking App – Roadmap

 

Modified screens. After organizing the features into a sprint in a manner that fits the guiding principle, I had to go back and modify the wireframes of the bank app so make sure that the app doesn’t look like features and parts of features were hobbles together. One example was the navigation menu. The original navigation menu accounted for all five banking features the app offered. With the first sprint, only two features were being built (Accounts Overview and Deposit). As a result, I had to go back to clean up the navigation menu for the first iteration of the app, then added tasks to the roadmap for later menu updates as more features get built out.

navmenu_iterations

I continued through the rest of the apps to make similar modifications to account for varying iterations.

Making and Sharing Wireframes Per Sprint

As a means to communicate to developers the current vision, and how it is different from the final version of the bank app, I pulled out the screens per sprint and compiled it into a format that easily shared with developers. For this activity, I have the formats of a .sketch file (where each set of screens in the same sprint is on its own page), .png file, and .pdf.  The point was so that developers don’t confuse the temporary modifications to a component with the intended final version of the same component. Below are some samples from the feature in the first sprint.

Assignment 2_Thin Sliced Feature_Onboarding

Assignment 2_Thin Sliced Feature_Transaction

Assignment 2_Thin Sliced Feature_Deposit

Lessons Learned.

Focus and tradeoffs. Designing an app have a very different focus and purpose than when it comes to building and implementing the design. I had mentioned earlier that there is a tradeoff in the difference in these roles where design’s user experience focused can easily add more bulk in development time, and product management and development’s perspective of contained resources will prioritize the feasibility and completeness or a design idea over the user’s experience.  Alone each focus can result in an excessively delightful app without purpose or a very practical app that may not be as seamless.  But when both focuses are in balance with each other, the results can be a very functional, concise and still user-friendly product.

Breaking features down into its smallest possible unit is the tool for flexibility.  Organizing the operations and logistics of building a product is a craft. Even with estimations per feature, I often found myself either coming in under or over the budgeted hours of development per sprint. In the real world, these estimations are exactly that, just estimations. I was only when I would break down the features into individual capabilities with smaller estimates that I was able to more easily move feature around. What I also found was that the more granular I was able to describe a feature and reconnect that granularity to other parts of the app it can or does impact, the better the developer was able to give me a confident smaller estimation.

Communication is key.  To be able to bring together all the people involved in building an app, and to strike a balance between delightful design and practical implementation communication is KEY! Everyone I consulted in this project had a better-reasoned solution or offered an alternative option that would take less time to build.

Wireframes of the final app.

Learning from Conversations with a Developer

A few months ago, I had built out an interactive wireframe of a bank app for the purpose of user testing.  Over the last two weeks, I was tasked with taking that design and size the feature.

All the Hurdles.

#1. Foundational Hurdles. The biggest initial challenge was to build out the remaining flows that I did not get the time to build. That is four out of a total of six flows. Additionally, I still needed to figure out how to make the app usable. These were very intimidating tasks because I hadn’t cracked the code on how to build wireframes quickly, how to map the user flows in a way that is smooth and achieve a clear goal, and going pedal to the metal was not an option as time is not a luxury at AC4D.

#2. First Meeting with a Developer. I was also to show my wireframes of the bank app to Eric Webb, a developer who has volunteered his time to help AC4D designers in training how to size and estimate the app’s features. Can’t do this if there isn’t much to show.

#3. Time. I need to do all of that as well as identify the key features, estimate the time it would take to develop the feature after a conversation with Eric, the developer.

I’ll be sharing with you how I overcame the hurdles and my journey in over the last two weeks.

 

The Process

Step 1. Meet with A Developer. Recognizing that I still had some wireframes to critique, I decided to meet with Eric earlier rather than later to get some feedback and suggestions on the existing mock-ups and understand what to consider from a product engineer’s perspective. As creativity does not happen in a silo, and developers also build things with users in mind, this conversation did provide a richer understanding of how to design for a user.

2. Complete more of the wireframe. Based on feedback from Eric, and hearing him talk through how he would implement parts of my design, and talk through what some parts of the design seemed unnecessary, I took some key takeaways with me as I rebuilt the existing parts of my app, and built out the remainder flows. Compared to 2 flows with repearted screens over the course 45+hours, I was able to build out unique, 28 key app screens that had a clear visual hierarchy, in less than 20 hours.

3. Second Meeting with a Developer. This is what I will be doing next. I will print out my screens and annotate (also called redlining) the components of each app screen as a developer helps estimate how long the app will take, and about how much it will cost to build the app.

Key Takeaways

While I did not get to a place with estimation, working with Eric and discussing the natural flow of an app and how users typically interact with apps was super helpful. Here are some key takeaways that I will actively include in my process in the future.  When designing keep the following in mind.

Use Existing Element over Custom Element.

Custom controls and UI take more time, to design, to build, test, and (for iOS apps) it may take longer to approved by Apple as you maybe not following their style guide properly. Making custom components for the sake of delightfulness comes at a high cost, literally.  Custom elements are best reserved for making the user experience & business interaction move valuable, efficient, and pleasing.

The result of this is more consistency in what you built, it’s faster to reuse existing components in design as well as in development, and the app is less brittle. When something breaks it is faster to identify and fix that single component that exists in several places.

The components of your app will have a pattern, which decreases the user’s learning curve as they interact with the app, and navigation become more intuitive for less tech-savvy users.

The components of your app will have a pattern.

Have Clear Defined Goal

Have a clear single defined goal for the app as well as for each flow. Without this, is it very hard to decide what elements, details, and information to include, let along how to outline the flow.  Knowing those things makes it infinitely easier to be decisive on where to place certain navigations, how to build a clear hierarchy, and you move faster.

Before_No Clear Goal After_Clear Goal

 

Consider Typical User Behavior 

When Eric asked me “When was the last time you logged out of an app?”  I, like many, couldn’t remember when I last did that on a browser or app. So, it was clear to me that keeping a Log Out link would be a waste of valuable phone real estate. I started paying more attention to how I bank and took a closer look at the things in the apps I’ve used that I never noticed before. All of the links I never touch in an app made it on a list of low priority elements that I will use to survey my peers and people I interact with daily. Some things that make it onto the list when it comes to my banking apps are: find a bank location, help, privacy policy, legal policy, terms & conditions, statements, setting a language preference, login information, notifications, alerts, bill pay.  As a result, I opted for moving the Log Out link into a hamburger menu.

Be Prepared, and Ready to Trim Ideas

After hearing from my classmates, when I meet with a developer to gauge feature estimates, I will be prepared by having the ideal state of the app screens printed to share and to make note of critiques on, be ready to explain why I made design choice I over other options, have all my feature named and listed, be ready to ask for alternative options and to ask lots of questions. I did not do a very good job asking questions about trade-off such as loading time (which impacts the user’s experience), and security features.

 

Mock Up Screens

Here are the flows I’ve created and will be used for estimations.

Onboarding

Onboarding_1

Onboarding_2

 

Accounts. Users can monitor their account.

Accounts

Deposit.

Deposit

Transfer Money. Users can transfer money between your accounts or to an external account.

Transfer

 Pay A Bill.

Bill Pay

Student Reflections Three Quarters In.

Thoughts and Experiences from the Team

For the last seven months, classmates and I have been learning and using several tools to research the topic of college persistence among working students. Early on in the research process, we found several tools and methodologies foundational to help up with research and make sense of the data that we saw. Among them were a contextual inquiry/interviews, ethnographic research, concept maps, compelling storytelling, service slices, dissecting a system, talk aloud method, and semantic zooms. From this data, we developed several crucial insight of which we would use to inspire design ideas.
In a couple of brainstorming session, we used reframing methods and tools including a 2×2 diagram to decide on which design ideas we would like to build out. In building out these design solutions, we used techniques including storyboarding, mapping a user journey, service blueprint, lean canvases, theory of change canvases, and wireframing.
In the process of research, building prototypes, and testing out the ideas we have learned so much and gained some insights we’d like to share. In all this sharing of ideas and experiences, a foundational skill is to listen. But there is a difference between listening to respond and listening to understand. Most of us listen to respond, but by listening to understand we are better able to incorporate the needs, we heard into our design. Additionally, as we are building and testing out design ideas, we’ve found value in failing fast and early then iterating as a way to make sure we are developing the right solution for the audience.

FundEDU

We exist to create a world where working students have the option to prioritize school over work, because working students face a daily decision between financing living expenses, meeting academic requirements all while experiencing cognitive overload.

To do that, we need to answer the question:

  • Why do donors find giving to a financially burdened student valuable?
  • What drives people to donate?
  • What is the thinking that makes people donate one-time vs consistently (on a subscription model)?
  • How would students spend the money?
  • What would students spend that money on?
  • How do we measure and track the impact of a donation?
  • What would make a donor stop giving?
  • Who donors are more likely to give to?
  • Would students be willing to ask their social network for financial support?

So this week we will:

  • Conduct interviews with people who have donated to students, or in general
  • Refine our service blueprint for the ideal state.

In the Near Future

Our team project is called FundEDU, a platform to connect working students that are strained financially with donors. This platform attempts to help student persist in school by helping cognitively fatigued working students be able to focus on school.

For the future of FundEDU we hope by the end of April we would have worked rigorously to get FundEDU to a place where it could be pitched to the investor. After AC4D, our personal goals is to join the world of design as interaction designers at an agency and have the opportunity to sharpen the research, sense-making and creation skills we have learned.

Paving Our Path

To get closer to our goals for FundEDU we intend to work on the following between now and the end of April.

  • Find users and keep solution flexible; change it to fit user needs.
  • Use tools and methodologies learned to outline the user flow, components of the business and how it relates, create a prototype that can be taken to users and tested, reach out to the public to look for users.
  • Validate/learn, validate/learn, validate/learn.

Individually, we are focusing our energy to continue growing in the following areas and ability:

  • Form an opinion and insert it
  • Continuous learning about design and topics
  • Take responsibility for designs
  • Focus on the user’s experience — empathize
  • Keep larger context in mind as we create things for individuals to use
  • Keep asking ourselves why something should exist in the world

Where Good Intent Intersects with Design

In the world we live in, when a person’s attempt to fix a problem goes sideways we often hear the defense “well they had good intentions,” or “it was well-meaning.” However, in the case where a solution with good intentions goes off the rails, we aren’t satisfied because we don’t care to hear the reasons why things fail. We want a solution. We want things to work. As a result, good intentions get put on trial, and its value gets debated. Moreover, we end up with expressions and books with titles like “good intentions are not enough.”

Our class has been pondering the questions of “Are good intentions helpful? Or is it selfish altruism? Beneficial for the person we want to help or ourselves?” Moreover, these questions have the implications of should we let good intentions be the guide in the way we want to do good in the world.

Hi, I am Kim, born a chaos muppet and self-made order muppet. I naturally embrace chaos as a challenge to create an order from it. I want to share with you my philosophy on how embarrassing disorder and working towards creating order makes for a well rounded, thoughtful interaction designer. I want to use an example to walk you through the mind of a chaos muppet trying to create some order. Here are the steps I went through to unpack this topic of ‘what is this thing, good intention?’, and ‘what are its values.’

1. Breakdown and Sort the Conversation.

In the debate of ‘how good intention intersects with Design’, putting intent on trial is not fair, because we have not taken the time to understand its nature. So let’s begin by parsing out the facts from opinions.

Facts:
  • Humans problems are made by humans and/or are a result of humans not playing well with what exists.
  • As long as humans are around, there will be problems.
  • Bandaid solutions are great for stopping the bleeding, the emergency at hand.
  • Complex things are made of smaller pieces that work together.
  • We don’t know what we don’t know.
  • We learn by trying or testing things out.
Opinions: (I’ve underlined what part makes the statement an opinion.)
  • Intentions aren’t good enough.
  • Design solutions only create more problems.
  • Wicked problems are hard or feel impossible to solve.

By doing this, we can start to understand which practical steps we can take next. Opinions are a flimsy foundation to build on because opinions and views are a verbal extension of our feelings.  It doesn’t make opinions and viewpoints less valuable, but it does make your foundation a moving target.

2. Find a pattern then ask the right questions.

We have been asking our self if good intentions ARE enough. Depending on whom you talk to and their experiences you will hear a mix of things. So, is the good intention behind a design solution sufficient for it to work? After all, when we see examples of design solutions with large scale impact and success, the founders and designers always talk about the intent of the project, take Spring Health Water’s project in India for example. They intended to create technology that is easy to use and maintain, create income for shop owners, jobs for those working for the company, and to supply clean, uncontaminated water to the masses at a super affordable price. The intention seems good, and the execution proved successful, yet today they are now struggling with getting adoption in rural areas. People’s intentions are not the only variable at play here.

The question “Are the good intentions behind a design solution enough for the solution to work?” begs the questions “Well, what is the goal?” Let’s say the goal is to have an impact (far-reaching, or profound), and sustainability (the solution should thrive, and not become relegated to the history pages of design as a field.)

In another example the effort to reduce alcoholism, we see plenty of efforts working at various scales. I’ve summarized these efforts and mapped it relative to its impact and sustainability. Here we see efforts to reduce alcoholism on working at various levels:

  • Small group  — ex. A family & friend intervention for a one person
  • Organization— ex. MADD (Mothers against drunk driving)
  • Nationally — ex. Prohibition, AMOD (A Measure of degree) which is an effort born out of numerous terrible stories we hear about college students and their drunken mistakes.
 Impact x Sustainability_01
The thing with these design solutions mapping is that it can change quickly, when any variable is changed or introduced.
Impact and sustainability can change with an introduction of any variable.
Impact and sustainability can change with the introduction of any variable.

If these solution’s outcomes can change so dramatically with a change in any variable, then this tells me that we are looking at the problem & solution relationship all wrong. We have been conditioned and taught that problems and solutions have a cause and effect relationship, but this is a narrow perspective. It assumes that one key variable is responsible for the solution’s success or failure. Instead, when dealing with problems that persist despite our intentions and attempts, we need to consider that the relationship of problem and solutions is one if systems, where all variables have the potential to influence on the outcome dramatically. This is true of many, if not all wicked problem.

So the question to ask when considering how Intentions intersect with Design, should be: “What is the role of intentions in design? Also, Why?”

 

3. Understanding Design Solutions In a System

Here I have three design solution’s trajectories of its impact on Behavioral Changes over Time.
impactxSustainablility
Low impact, unsustainable design solutions are unresponsive to their environment AND individuals. While attempting to address problems may have some degree of behavioral change on a group of people, it will not move the needle of the behavior over time. This is because these types of solutions are not dynamic enough to respond to constant forces acting on the individuals such one’s health, financial strains, personal beliefs, events in the world, policies, and regulations.
High impact, less sustainable design solutions, are responsive to both people and the environment but fall short on the front of adapting to deeper & wider reaching variable such as cultural norms, natural disasters, a profound personal life event like death or having a baby. The nature of this solution is that it works until it doesn’t.
High impact and sustainable design solutions are ones that build on each other’s success. They are ones that respond to acting forces AND adapt quickly to continue moving the needle of behavioral change before deeper & wider reaching variable comes along to undo the previous design solutions success.

 

4. Answering the right questions.

“What is the role of intentions role in design? Also, Why?”. While design solutions exist in a complex system where their success is influenced by variables such as time, scale, people, environmental factors (health, culture, world events, and more), and so much more, intentions are best associated with the design solutions themselves.
Here is the breakdown of design solutions. If Design theory is the framework and engine that shapes and defines how a design idea navigates towards an end goal, and people are the ones driving the ideas, then intentions are best described as the fuel. Fuel has lots of potential energy and power. When applied to the proper system with proper equipment and constraints they work as a source of energy for the design to keep moving forward. In an open space without direction, they are highly explosive.
Intentions as fuel
Without cooperation, collaboration, direction, and focus, we are all bound to collide on and get nowhere productive.

Direction for design

On Options and Intentions

The value of something made is not what the thing is, but how well it adapts to the people using it, and how quickly can you and your team adapt the thing to changing time and environment. When it comes to opinions, I am less interested in take individual opinions to the boxing ring and go head to head with one another. Your opinions serve to orient your self in the world, help you sleep at night, and to make friends. Where intentions are just another flavor of an opinion. That’s all good and dandy, but it alone is self-serving. When someone tells me their opinion, my first question is, “GREAT! What are you going to do with it?” On the other side of this conversation, if I told you my thoughts and opinions, what are you going to do with it? If the answer is a sincere “nothing”, then we have effectively wasted our breath and time.
Opinions WITH facts, however, works great to provoke conversations that shape theories, idea, and understanding. This, in turn, helps shape your focus and strategy. This is more productive, but it still doesn’t get you a solution. Working as a designer, I am more interested in hearing opinions, informed by facts AND experiences, and quickly finding a way to incorporate it into a system that solves a complex problem, and how quickly can you and your team collaborate and move quickly and responsively.
I hold the opinion that all things in the world MUST have a balance to be sustainable and bearable, take life and death, winners and losers, pains and happiness, good and bad. That is beauty of the world, the balance. Moving forward, my plans are to take this opinion, and find a systematic way to find balance in extreme human conditions.

In Conclusion

So that my friend is how this chaos muppet has used her ordering skills to make some sense of the intersection of good intentions and Design. To sum up, there is no right way to build a thing, but there is an effective way to utilize the resources we have collaboratively to create a change in a general direction we all can agree on. In outlining a design solution, we first need to stay focused on what is the immediate goal we want to work on, a design idea, what resources best get us results, and how to proceed.

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).

Prototypes Are Like Wet Clay: Reshaping and Testing Designs

This week our team of Kay WymanAaron Steinman, and myself recruited people that were excited to test out our pilot produces and services. Using out initial models, low-fidelity demos we shared our designs and gathered feedback. After a week of listening to people react to the work, we find ourselves needing to reshape our products and services to adapts to what people are asking about and to get a deeper understanding of why certain parts of the design aren’t picking up traction. The moment we think we have created a bowl, or vase, or mug natural forces taken hold of the medium and exerts itself on what we’ve put together, giving the piece a more organic look and feel. It’s like working with wet clay.  If this sounds like it can be discouraging, you are absolutely right. But the problem is that we are standing too close. Once our team regrouped and talked about the problem each product was attempting to solve, how people reacted to it, the things we learned to work well and not work we were able to take a step back and appreciate the new form each product and service is taking. Below we would like to share with you our findings from this past week.


 

FundEDU

(sounds like ‘Funded  You’)

Many believe that higher education is the best way to achieve economic mobility.  This can be true but is often not for those that have not found the right path for themselves.  The journey of education if beautiful in that it offers the potential for growth, hope, and opportunity. But if this that is not properly honed and focus, all of that potential will convert into large debts, time lost and a battered ego. Education and economic mobility then becomes out of reach or difficult to get through because of the great financial cost.  

FundEDU is the only crowdfunding platform for higher education that connects students to their community of support.

This past week we wanted to learn specifics about who and how many people will find this valuable. In order to gauge interest, we made a simple landing page announcing a website “coming soon” to capture email signups and a Facebook ad to drive traffic and measure interest by clicks. The test was designed to see if people are interested in “yet another” crowdfunding platform, even if it is specifically geared towards higher education.

Our hypothesis was that people would be generally interested in exploring a new, as yet unknown funding option for education and would be motivated to click on our ad. However, since we are not offering much in the way of an actual product yet, we would garner a few signups from the landing page.

The Facebook ad targeted people in the United States with some high school or some college, who were interested in either Austin Community College or General Assembly. The rationale for choosing the two schools was: 1) we wanted the ad to get in front of people already thinking about education. 2) Generating local interest from a school in Austin that serves many post-traditional students could provide us with leads for further testing. 3) General Assembly is a popular, but unaccredited school, so students would have limited access to traditional government aid for education.

On the first day of our ad campaign, our ad reached about 650 people and received 6 clicks, costing $4.03. That means each click was $0.67. While this is an expensive price for a click and not a full conversion, it still shows a strong sign of interest. More robust ads and landing pages built for each target customer segment could make these metrics more cost-effective. However, our next steps are to create a prototype to get in front of users for feedback. It’s important to see why people are interested in an educational crowdfunding platform. The fun of design is that the reasons for behavior or feeling are never exactly what you think.

Through the testing process, we learned that a very simple ad and landing page can start catching people’s attention for a product. Our class has been practicing “de-risking” through validating ideas quickly and cheaply, but this iteration proved the point in just one day and for $4. As the results came in, the limitations of this test became apparent as well. We do not know what prompted each individual to click the link or how they thought the service would work. 


Our hypothesis moving forward is that student and prospective students are looking for any funding channel because education is almost always expensive and government aid when it is available, does not cover living expenses. However, we suspect there is more nuance here or perhaps other compelling reasons to seek out crowdfunding altogether. This will be the focus of next week’s testing.

 

FundEDyou

Me Mentor

https://mementor.convertri.com/

We all have goals and aspirations that sit in the back of our minds just waiting for the opportune time to start working towards them. We often tell ourselves that we are too busy, or don’t have the right support or resources. For the few aspirations that do make it out of our heads and into the world, setting goals and staying focused is difficult when you have so many things to balance. In reality, everything that is achieved is a result of several small steps that build upon one another.  So how do we achieve a goal when breaking down ideas into smaller tasks is a skill that many aren’t taught. Me Mentor is a personal coaching subscription that helps make defining these steps easier, and routine. The Me Mentor process and personal coach supports you in learning how to identify, define, and take it one step at a time with encouragement and support. Learn to organize your time, thoughts, hopes, and future.

This week our prototype consisted of a Me Mentor form and a designer playing the role as a personal coach. With this prototype we were testing if people would be interested and find beneficial the combination of an encouraging voice, advice on how to break down goals into smallest bit size takes for the benefit of continued momentum, and having a list to refer to as a means to pick up where you left of for the goal you are trying to achieve.

This week we recruited two users to use our Me Mentor goal setting and planning worksheet, and then checked in on each user at the end of the day to follow up on their progress, reflect, and get specific on how they will fit in the next step in the next day.

Lesson #1. We learned from our two users that the practice of writing a goal and the plan they thought of to execute it made the idea real and motivating to start. We also learned that having another person coach them on how to break down steps into smaller pieces made it possible to have continued momentum. In one example, one user had the goal to write a paper and this person’s steps #1 and #2 were to look up requirements, then write a rough draft. This person also originally estimated that it would take 1-2 days between those two steps.  This plan could be equated to running short burst sprints, where each sprint is interrupted by a hard stop. We suggested that instead of waiting for inspiration to strike, they could begin to think deeply about the topic by creating an outline based on their ideas and the requirements. This helped the person continued their stream of motivation, instead of getting distracted by another unrelated task in between steps #1 and #2. This motivation is more like running at a steadily paced marathon, with continued endurance. We were able to validate that the model of a worksheet and personal coaching is valuable to help a person maintain consistent momentum.

Screen Shot 2019-02-08 at 11.50.47 PM

Lesson #2. We learned quickly is that this model does not scale at all. Having seen this, we understood first hand why, as another research team states it, “effective advising it intrusive advising”, and why this is rare. Even with all the good intentions, time and schedule, and other life events will interrupt the flow.

Lesson #3. We also learned that this model is most something that is easily adopted by our original intended target audience, a working student that is considered post-traditional and who struggle with college persistence. Another thing we learned is that not all goals are the same, and can have the same process and advising applied easily. Some goals start out as an idea for a lifestyle or feeling they want to achieve. This is where our design research skills prove the most useful. After a conversation, their original goal was broken into two goals, one for changing habits, another way to change a behavior, a much harder task, that takes time and reflection.

VorMi

(sounds like ‘For Me’)

This week our “Pre-hire” idea got a name change. We wanted to come up with something less product-description and more recognizable. We landed on the name “VorMi,” which is pronounced with a German “f” sound in place of the “v.”  
We hypothesized that employers would be available for a short 15-20 minute meeting to discuss VorMi. To test our hypothesis, we went door-to-door to 4 companies located in downtown Austin asking to speak with hiring managers / HR representatives to get feedback regarding our pre-hire system.

We learned that canvassing is not the most effective method for getting in front of the right people to gauge interest. The next step is to reach out via email to schedule time with our employer-side target audience and to continue seeking out companies we believe to be a proper fit for our product.

Our MVP is a pitch deck that explains who we are, the origins of our design idea, the problem our product addresses, and lays out the benefits to potential stakeholders. We continue to hypothesize that businesses with entry-level positions requiring some amount of ‘hard’ skills (such as coding or proficiency with a certain software) would be interested in taking part in a student’s academic journey.

Vormi


What’s next

This next week, our team will be sussing out the meaning behind what we found, reshaping out pilots and prototypes, talking to more people, looking for more people to test these designs, and building and iterating on service design blueprints.

Does any of the problems, designs or ideas interest you? Please email us at kim.nguyen@ac4d.com, kay.wyman@ac4d.com or aaron.steinman@ac4d.com and let’s talk! 

Bank App Part III: User Testing, Feedback and Recommendations

Last week, I had presented an initial Bank App Concept. This concept was a redesign based on my personal preference. Four guests were then invited to on see our work and provide feedback to each student. With this feedback, I revised my initial design, digitized the drafts and took my design into the real world for user testing.

Assumptions and New Features

With the second redesign, I baked in a few of my assumptions and features that I wanted to learn from user testing.  I set out to discover the following.

  • Do users value Touch ID and will always opt-in to make logging in a faster process?
  • Does laying our the main banking activities laid out like a buffet make navigating and conducting a task simpler, and faster?
  • Is a visual of a user’s debt to ‘money they have’ and how they compare valuable information for the user? How would they respond to that ratio?
  • Do icons make finding buttons and links more straightforward to find?

Users I Spoke To

Given the timeline of this project, I knew that I would not get as much of a variety of participants. So I set out to self-description a deeper understanding of what motivated the users’ banking choices.  One way I did this was to ask the testing participant to describe themselves by what spirit animal they are, or what magic power do they wish they had and why.

Listening to their response and reason I got a sense of what they value as people. I considered that self-description when I revisited their feedback. What was interesting was how their self description helped explain why certain features caught their attention in a good or bad way, what bothered and excited them about the design, and found the following to be my participant’s banking style and goals. From those, I identified some more universal goals to incorporate into my key takeaways.

Screen Shot 2019-01-28 at 10.11.43 PM

What was interesting what some of the contradictions I would hear from the users. There is a fine line to straddle between sufficient communications and ‘intuitive’ design flows. One example was when I chose to make the ‘Remember User ID’ Automatically be enabled when a user would allow “Touch ID.” From a technical perspective, it made complete sense, how else can you log in without a user ID. But this is not what I heard from Leo, who looks for full control of his banking choices.  At the same time, I also heard from Leo that having an extra message after completing a deposit was redundant, and felt inefficient.

This contradiction is not because Leo can’t make up his mind, but a clear indicator that what is deemed as good communication, and intuitive user flow is defined differently depending on how the user perceived money and banking.

The need to further communication in around certain features such as password and ID management and less around transaction completion made me hyper-aware that there is a balancing act to be made. I am going forward to the problems identified, and proposed solutions will need to be guided by these takeaways, which were informed by the feedback, user’s banking style and goals.

Screen Shot 2019-01-28 at 10.11.35 PM

The people I spoke to had real personal goals including, improving their credit score, getting a mortgage, improving their spending habits. Any goals made around money takes time, patience, and focused intent to achieve. It is unsurprising that people will react so quickly, intensely, and be firm in their resolve when technology behaved unexpectedly.  Anything unexpected can be quickly interpreted as an obstacle for them to achieve these goals they set for themselves.  Moving forward with my next iteration, I intend to use the data I have on user behavior to guide more of my redesign, as oppose to what ‘feels’ right to me. My job as a designer is not to intuit what people need, but to hear and crafts something based on what people demonstrate to me their needs and desires are.

Problems and Recommendations

Screen Shot 2019-01-28 at 10.41.24 PM

Screen Shot 2019-01-28 at 10.41.32 PM

Screen Shot 2019-01-28 at 10.41.38 PM

Screen Shot 2019-01-28 at 10.41.44 PM

Screen Shot 2019-01-28 at 10.41.50 PM

Screen Shot 2019-01-28 at 10.41.56 PM