Our banking app journey has come to an end, but not without one last deliverable: the feature brief. In developing a feature brief we needed to be able to quickly and clearly translate the value promise, the why, and the how of the product to the reader without necessarily being there to present it. This also meant a printed and bound deliverable.
Click the the image below to view the feature brief I created for the Candid Banking App.
Things I learned:
The same elements that work in a slide presentation do not necessarily translate to a printed presentation for individuals. For example, slide builds are great in live presentations, but annoying to flip through on paper if it’s just a visual build without descriptor text on each page.
Printing is finite, and tricky. When I printed all 115 pages of my brief (5 copies) I found that there were some pages that had elements that were invisible when viewed on my computer, but very clearly there when printed. I will be printing test copies next time before going all in on multiples.
I also got feedback that quotes and pictures of real people are important and would have made the insight section more impactful and added more credibility to the brief.
What does the ATX Fail Club ecosystem look like? What will we include in our narrative pitch for Saturday?
Since our last update…
We crafted a social media post to publicize our upcoming April 19th dinner party for the pilot. We were interested to see how effective this would be in actually generating interest/sign ups/follows for the club itself as well as engaging people to purchase tickets to an upcoming event. We shared this post on the ATX Fail Club social channels, as well as reposting to some of our own social accounts. The post received 12 likes on instagram, and brought 16 users to our website. 8 new people signed up for our email list and 4 people bought tickets for the May dinner event.
We also built out the offerings that we envision falling under the umbrella of the ATX Fail Club offerings, and created a low fidelity concept map of these.
Lastly, we built out our first draft of our pitch presentation and narrative, and presented it on Saturday. We received a lot of great feedback to keep tweaking this over the next few weeks before we present our final presentation at the end of April.
Not every artifact needs to be built out to higher fidelity levels. We focused this week on making lower fidelity artifacts to help us synthesize some ideas we’ve had. Later we can always refine these further if they will be useful to share with a wider audience, but this helped us to keep moving forward.
We have a lot of great ideas for the next iteration of our pitch presentation, but one of those is to draw a clearer distinction linking the stories we heard in our impostorim research to the broader goal of reframing failure. We also would like to include how our organization fits in with and will address some of the current relevant cultural emphasis on women’s empowerment.
Our Next Big Question:
What is our hypothesis for ATX Fail Club’s “magic moment(s)”? What interaction(s)/touchpoint(s) will let our target audience experience these magic moment(s)?
Now we’ve got to…
Further define how we will proceed with piloting our concept.
Continue recruiting sponsors, and publicizing our upcoming events
Identify potential magic moments, and create a method for integrating them into our pilot for testing.
We’ve just finished a block of readings in our theory class about power, and tonight we all presented for 7 minutes or less about what they meant to us. My presentation tonight asked the question ‘Will we be overcome by power?’ Specifically, as we all prepare to embark on our careers in design post AC4D. We’ve all talked about wanting to do good, and resisting the allure and potential corruption of power, but how realistic is this?
Growing up I played a lot of sports, but never really enjoyed them until I joined the lacrosse team as a sophomore in high school. It was great. It gave me this wonderful outlet where I could be physical, and competitive, but also a part of a cohesive supportive team, and I ended up being pretty good at it. Later when one of my teammates I’d met playing for UT asked if I wanted to coach an elementary school 5th/6th grade girls team with her I jumped at it. I was excited because I saw this as an opportunity to pass it on and empower and encourage other girls. So I thought a lot about the type of coach I wanted to be and how I could:
help girls learn live lessons through sports,
realize that there’s more to sports than just winning,
and be supportive, motivational, and inspiring to my players.
George Aye recommends that designers ask themselves the following question before starting a project.
“How has this project/team acknowledged the role that concentrated pockets of power have played in the history of this issue?”
Thinking I had done this we created a rule at the beginning of the season that everyone who participated in practice that week would get equal playing time in the games no matter what. I didn’t anticipating this being a difficult rule at all, and mainly thought of it as a way to encourage attendance at practice.
I don’t think I went into the season expecting to win, but that’s what happened. Our team was doing really well, and by the end of the season we were pretty used to winning. Everyone loved it, parents, teachers, the players, and me. It feels good to win. Like many teams we had some players who were more athletic or skilled than others, and they often scored more points. There was also an awesome girl on the team named Lina who was not yet a star lacrosse player. She was shy and doubtful of her abilities, and often made excused to be able to sit out during practice. So when we were at the end of a close qualifying game against a strong team neither her nor I were super excited to put her in. In fact, she didn’t want to play because of the pressure, and I didn’t really want to put her in either because I wanted us to win. Tim Wu warns of something similar in his article about the tyranny of convenience saying
“Convenience is all destination and no journey. But climbing a mountain is different from taking the tram to the top, even if you end up at the same place. We are becoming people who care mainly or only about outcomes.“
But she’d participated in practice that week, and I had that rule, so I told her to trust herself and have fun, and in she went. Somehow she ended up with the ball almost immediately, and panicked. She just stood there, and everyone started yelling to “RUN!” She snapped to and immediately started sprinting, but towards our own goal. The yells soon turned to “WRONG WAY” as her own teammates played defense on her, and at the last second she made a giant u-turn and started the other way down the field. This whole thing caused so much mayhem that it threw the other team off, and she ran down and scored. It was amazing! Everyone went wild and talked about it for the rest of the season. We called it the Lina play and turned it into a trick play. After that Lina was more present, confident, and engaged. Pierce Gordon talks in his article about how designers can learn from activists, and benefit from more diversity just like we all benefited from having every member of our team and the wide range of lacrosse skills they brought.
“In this, we hope to open the conversation about how multiple, valid, differing expertisescontribute to the world. In many instances, the true innovation happens at the margins of society.”
I was so glad that I’d stuck to my rule, but I’d also learned how easy it is to be swayed by power. If I hadn’t had a concrete rule that I’d vocalized to the people around me to hold me accountable to I don’t know if I would have made the same decision. Or if we’d lost would I have re-evaluated that rule the next time that situation came up? If I questioned my ability to stay true to my values in a situation where the stakes are pretty low (elementary school sports) what does this mean for later when the stakes are higher? Margaret Gould Stewart says the following words of encouragement in her article.
“We just need to make sure that we keep the long view in mind and are vigilant about making ethical, responsible decisions along the way.”
I personally believe this is wishful thinking, and without a solid meaningful framework it will be a slippery slope. As students entering this field we are in a unique place where we can be both optimistic and naive about the industry we are hoping to join. I think we need to take advantage of the space this gives us to think about what we value, and craft our own personal codes of ethics. Adding concrete actionable statements that are meaningful to us, and sharing them with others is even better and may help to solidify our resolve when we inevitable do need to ask ourselves these hard ethical questions about power.
Also, encourage your daughters to play sports (preferably lacrosse).
For our last product management assignment, we met with developers to generate estimates based on the redlined wireframes of our mobile banking apps. For this assignment we used those estimates to create two product roadmaps. The first was based on an “ideal” scope with two developers working full time (40 hours per week). The second was based on a “constrained” scope of the product launching within one month (20 working days) still with two developers working full time.
Approaching this I was very thankful for the estimates spreadsheet we created in the last assignment. This helped me quickly review the estimated hours for each flow. I created new columns to turn these estimates back into days, and generated totals at the bottom. To build out my full front end app as I currently have it scoped I’d need an estimated 57 days. So I only needed to trim a little bit.
Looking at my flows I zero’ed in on the send money flow where a user can send money to another account outside of the bank. This was chosen because it nicely cut out 8.5 days and I figured this is a function that many users have other apps to do this already such as Venmo and Zelle.
I also decided to lose the chart function of the monthly trend feature, because that information is a duplicate of the list screen in chart format and would cost me 2 weeks.
Lastly, I trimmed down the deposit check flow to remove the confirm image screens and the static info screen at the beginning of the flow. This removed another 3.5 days. I figured that these were more nice-to-have items and I think the MVP version of the app will function well enough without them. In fact, they may not even be necessary so it might be better to add them in later if we find users are having difficulties there.
Next, I began laying out my development roadmap. I decided to use half days as my increments along the top and added two rows to divide work across the developer resources. To organize the flow/screen development I tried to group similar functionality and screens together thinking that would reduce the amount of ramp-up time for the developers as they moved between flows.
I also made an attempt to have the flows build off of each other functionality wise. For example, the screens showing flagged and recurring transactions would be built after the basic transaction screen. This means the core functionality of the app will be developed first. I placed login at the end which may seem counterintuitive, but my thinking around this is that these screens offer a little flexibility on the features that we add so may do well at the end when the timeline has more or less than anticipated.
Included below are the constrained roadmap (top) and ideal roadmap (bottom). The timeline for my “ideal” app build could be achieved within two months of development if all goes as planned.
In our product management class we are picking up where our designing digital interfaces class left off. We’ve been tasked with taking our banking app wireframes that we made in Q3 and presenting them to a developer in a productive meeting to get a better understanding of time estimates if we were to actually move forward with building this mobile application.
I started by reviewing my existing wireframes and making updates for cohesion between the first set and second set I’d built in the previous class. Then I went through and began removing portions that alluded to screens that I would not be building or including in my MVP deliverable. This left me with 9 flows.
To help me organize all these screens, many of them being used in multiple flows, I wrote brief user stories for each of them. This cleared my head from all the screens swimming aimlessly up there and helped me focus on moving forward.
Next I exported all the screens into powerpoint and began labeling each screen in the flow order both numerically and with a descriptive title. I then went through and added all these labels for each screen to the estimate discussion spreadsheet. Then I went through and redlined all the features on each screen, and copied the screen and re-redlined the controls.
I met with Caleb, my assigned developer last Friday at Friends and Allies. We began by going through each of my flows with me explaining the clicks between each screen and what was being shown – basically following the user stories. Next we went through and discussed each screen and the time estimate he thought would be appropriate. He said he usually does his estimates in days so I worked with that and modified days to hours later. I was interesting because each new simple screen was estimated to take about 4 hours, but the estimates for the complicated screens that had unknowns in backend development quickly grew to be potentially 3 months of work.
These large ranges all hinged on how much research they would take, and at the end he said they still may not be possible. Basically they were just a big unknown. The big unknowns in development were related to the flagging transactions as recurring and anomalous algorithm, and the ability to link to a recurring payment entity’s site for cancellation.
The lower estimate for building this banking app MVP is about 13 weeks, and the upper estimate is 22+ weeks.
A few other helpful things I learned were:
Any kind of chart will usually take at least 2 weeks of development time.
Medium fidelity wireframes were his preference for scoping meetings (like this one), with more robust high fidelity wireframes being made for build out.
Many developers will increase their estimates to account for things that may come up unexpectedly sometimes doubling the actual time something may take.
It’s been quite the trip, but we’ve picked up a lot of tools and insights along the way. We’ve learned about human-centered design research and synthesis. We’ve also practiced sharing our insights with others through tools like concept models, zooms, and service blueprints. Last quarter, we explored methods of ideation like reframing and insight combination to come up with over a hundred novel design ideas to combat impostorism in women.
Jen, Vicky and I have a few insights and learnings to share with our many loyal AC4D blog readers:
Be yourself and do what you want. [Present findings that you find interesting and others will too. Don’t be afraid to insert your personality into presentations!]
Always maintain a bias toward action. [When in doubt, creating is better than not creating!]
Less is more. [#aintnobodygottimeforthat]
We’ve created a glorious vision for where we will surely be one week post-graduation. Please join us as we bask in the reality of it all:
We will each be fresh off our one-week minimum vacation to a tropical beach, and returning bright-eyed to a new role at a company we like with a team we’re excited to work with doing work we’ll be proud of. We’re excited about taking what we’ve learned and implementing change for the better at work and in all aspects of our lives.
To do this we will need to create a compelling portfolio and earmark time each week to set aside to work towards this goal. Building in time for critique and review will be beneficial and a great reason to reach out and learn from alumni, mentors, and the design community at large.
In addition to doing these things, we will also be expanding on the concept that came out of our research on impostorism in women. We are doing this because…
We exist to create a world where women aren’t stymied by failure.
In order to make this vision a reality, we are reframing failure by designing an event series for women to come together and celebrate stories of failure. To do that, right now we’re answering the question of whether or not women are open to celebrating failure. So, this week we’re doing “think aloud” user testing to better understand reactions to our concept and messaging.
The last couple weeks in our theory class we’ve been reading articles chosen to fit the theme of “With the Best Intentions”. Many of these had examples of design projects that were created with the intention of “doing good”, but may actually have had questionable outcomes. This theme was especially engaging for me, because of my work experience in government. I commonly associate my work and intentions to align with “doing good”, and take a lot of pride in my work. For this reason, I found myself reflecting on how the author’s viewpoints might relate to my experiences and the work I do, as well as my future work as a designer.
Involving many different perspectives (sometimes conflicting) doesn’t always lead to a clear picture or easy solution, but it often provides a wealth of insights and a more meaningful picture than approaching a problem with a narrower lens. This is especially important when dealing with wicked problems, or working in the public sector because a designer may not be a part of the community they are designing for, or personally affected by the problem. Not only can this create blindspots in the design that lead to the benefit of one group over another, but also a solution that could be more heavily influenced by the market instead of lasting change for good. By involving stakeholders from a variety of backgrounds a project can benefit from the knowledge brought by all parties to collaborate and try something new that none may have been able to come up with on their own. Lastly, relying on a wide range of stakeholders will help normalize a solution and make it more accessible and dignified for all users.
Empower the community to get involved in identifying and solving their needs.
The readings this week showed that involving the community you are designing for is not always enough if you’re not asking the right questions. Sometimes, it’s not enough even if you are asking the right questions if they are not able to answer them well. I think this is often why we jump to technology as an answer, because it is so good at giving us information quickly when that isn’t always the case with people. We as designers need to take the time to work with communities to provide the tools and resources necessary to help them identify what needs may exist, and participate in the process of developing solutions.
Create long term goals with iterative tasks.
We also read and discussed the importance of focusing on designing solutions for the root cause of problems versus the symptoms. Some examples showed that immediate, localized, or small impacts don’t always solve the problem, but may just lessen a symptom of the problem. With wicked problems it can be difficult to know the root cause of a problem because everything is so intertwined and connected. Therefore, an approach that incorporates a long term goal and outlook with shorter term iterative tasks provides the best chance of success and the ability to “design with”. This is because it allows for ongoing adjustments based on learnings and developments as well as steady forward progress.
Have good intentions, do your best, and feel good about it.
This is more of my own personal takeaway from the readings. I can see why these articles are good for us to think about as designers, but I was perturbed by many of them. Particularly irksome were the readings that highlighted how “doing good” has become a huge selling point and private industry has been capitalizing on it to profit. I don’t in general believe that private industry can responsibly solve wicked problems because they are driven by profit as opposed to government or non-profit organizations. Despite good intentions, thinking of consumers is different than thinking of people. However, I think it’s very important for designers and everyone to approach problems and the world with good intentions, do their best, and not let the idea of “selfish altruism” get in their way. Yes, I get validation from “doing good”, but it also inspires me and drives me to continue working and striving to have a positive impact which I refuse to find fault in – especially if I am conscious to keep the above takeaways and other learnings in mind.
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.
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.
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.
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.
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.
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.
I learned a lot about the value of user testing, and what makes it run smoother.
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.
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.
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.
Last quarter our team researched the impact that impostorism may have on women’s trajectory through higher education and the workforce. Since then, we’ve spent the last month working to turn our research into actionable business ideas. This was done by using a few different methods such as reframing, pattern creation, and ideation to generate a large number of ideas. Once we had these ideas, we went through them one-by-one to rank them on the following scales: level of fun, level of impact, feasibility, and capacity to build confidence. This ranking allowed us to filter down to our top five ideas.
Next we created storyboards, lean canvases, and theory of change structures for each of these five ideas:
Impostor Confessionals – is a safe space to share and celebrate your stories of impostorism in your life, and in doing so support others.
JVL Consultancy – women-owned consultancy that identifies and designs guiding criteria to demand equality in the workplace.
Destruction Box – self care, self reflection, and stress relief, all tied up in one monthly box.
The Ladies Dinner Party – is a place where women gather to share and celebrate stories of failure — and in doing so, grow together.
Alumni Sharing – as students graduate AC4D and enter the workforce, they can experience intense feelings of impostorism. This alumni sharing initiative spotlights and shares those feelings to help overcome impostorism within all of us.
After presenting and thinking further on these ideas last week we did another round of down selecting to end with three ideas. Down selecting from five was hard because we all really liked all five ideas we’d come up with. We ended up combined the dinner club and confessional storytelling ideas into one idea where the dinner club would meet more frequently and the confessional style event would be a semiannual or annual larger event. We also decided that even though we weren’t moving forward with the fifth idea as a business concept we’d still like to create the “prototype version” of it and gather impostorism stories from the AC4D alumni community to share with current and future students.
So now, we have begun the process of talking to people and testing these three ideas. This week, we interviewed one person to get her feedback on all three ideas. For this interview we had one lo-fi physical prototype of a product, and we used the storyboards for the other two ideas to explain their concepts and how they would work. Our hypotheses:
The destruction box idea, while fun, may not be that effective for combatting impostorism long term.
It may be difficult to get people to sign up to tell their stories of failure or impostorism on stage publicly.
Human Resource departments are good entry points, and method for framing the JVL consultancy work.
What we learned:
The destruction box may be more impactful that we thought. Our interviewee loved this idea. She talked about how this could release endorphins in the body and physically make people feel better. She also recommended that there be some sort of reflection tool so users can reflect on the why behind these feelings. She brought up the fact that women are traditionally associated with creating: Mother Earth, child birth, etc. and it was refreshing to embrace the opposite of that: destruction.
She said it reminded her of a similar past experience when she and others intentionally broke plates to symbolically destroy negative feelings. She says it felt cathartic, almost like… “Yeah! Is this how the bros feel when they walk into a board room?”
Our hypothesis that the dinner club might be an easier point of entry for telling stories of impostorism/failure was seconded by our interviewee. She liked both the dinner club and moth style event but said that as an introvert she was much more comfortable with the dinner party. She agreed that she would likely not get up on stage to discuss her impostorism, let alone submit a video to do it.
Lulu was most excited/most pessimistic about the JVL Consultancy idea. Her first question was, will you actually be able to implement this in companies? She feels that yes, we need this, companies need this, people identifying as women need this but it couldn’t only happen with HR. She feels like there’s no chance of success if we don’t have buy-in from leadership. We will need to focus more on how we could position ourselves to appeal to organizational leaders and potentially interview people in these roles to try and evaluate if/what would make them buy into this idea.
Looking forward, we have another interview tomorrow, and plan to continue to iterate and build prototypes of our ideas.
This week I sat down with 7 people and had them test the wireframes and flows that I created as part of the redesign of the UFCU mobile app. The entire experience was new to me and I learned a lot along the way.
This was my first time using InVision to create a semi-interactive prototype, and there was a learning curve. Once I got the hang of it though it was really neat to link the screens and buttons and get a feel for what it would actually be like to move through this application.
Next, the user testing. I decided to test four flows on my users:
You need to send your Uncle Bill $50 from your checking account for his Birthday.
You need to deposit a $75 check into your checking account.
You want to check your account balances to see if you have enough money.
You are transferring $400 to an account outside of UFCU.
I asked the user to simulate logging in at the start of each flow. I used a finger print id button that they could tap to do this. It was interesting to see people’s mixed reactions to this first step. Some people loved it because they thought it was more secure, others were upset because they like using a pin, and still some kept closing out of the flow all together because they would hit the actual home button to scan their fingerprint.
Next was the main menu page. My thinking in redesigning this page was to put the more actionable items like depositing a check large on the top and the more passive items like looking up locations on the bottom. I learned that while this made sense to me, most people expected to the ‘Account’ button to be larger and at the top because this is what they said they do most often. There was also some confusion about the difference between ‘Making a Payment’ and ‘Transfer’. Flow one paying your Uncle was setup as a payment, but almost all the users attempted to transfer money to their Uncle. I think this could be redesigned to a more general button of ‘Send Money’ and then build in navigation to seamlessly help a user get to the appropriate flow.
Another big issue for people was the ‘Search By’ screen for adding a new payee. On this screen I listed 3 options that they could search by: Business Name, Business Zipcode, and Email. Most users ready the first option and instantly got confused. One saying “My Uncle is not a business…” Then they would usually try and back out instead of reading on. I think I would re-arrange the order of the search items on this page to have email or just name at the top and separate out the business payees and personal payees as an earlier step in the flow.
I learned many more things that could be improved with my wireframes, and really enjoyed the user testing. Overall the users thought clicking through the prototype was kind of fun and treated it a little bit like a game. Some were a little worried about getting things wrong. I also found out how easy it is for users to get caught up in the details. On one flow I said they were depositing a $75 dollar check, and included that in the amount section, but then used an image of a $50 check. This threw people off and made it a little less realistic. Having text autocomplete also made testing a little less believable and some people got a little paranoid that it read their mind.