Jen, Laura and I launched ATX Fail Club to reframe failure as growth and empower more women to persist and succeed. We do this by cultivating communities in which women are encouraged to share and celebrate failure.
Since our last update:
We drafted a sponsorship ask email to send to local businesses explaining what ATX Fail Club is about. We are using this email to test the assumption that local businesses will want to align with our mission and vision and market to our members through in-kind and/or financial sponsorship.
We created a list of 87 sponsor prospects and reached out to 25 about sponsoring the April pilot dinner or future events. So far we’ve heard back from six businesses, secured one sponsor for the April dinner, and an offer to host a future event in May.
To promote the pilot we have posted on our ATX Fail Club social media accounts and personal accounts explaining what attendees can expect at the dinner. These posts have resulted in 21 visitors to our website, 2 new email list sign-ups, and very positive interactions and feedback.
Lastly, we made updates to our website to include our new sponsor, mission, and vision.
Sponsorship requests take time and doing them sooner rather than later is better. We’ve learned that many businesses have budgeted amounts for community giving and are allocated on a first come first serve basis.
We learned how to set up a team in Canva to create, share and modify social media posts so we can all be working on promotions with continuity.
We iterated upon the current version of our final presentation to incorporate the feedback we heard last week.
Our Next Big Questions:
How can we measure the impact of ATX Fail Club for our members?
How can we design these experiences to scale beyond Austin?
Now we’ve got to:
Coordinate the logistics for the upcoming pilot and organize all the needed materials.
Identify potential magic moments, and create a method for integrating them into our pilot for testing.
Continue refining our presentation narrative and artifacts.
The design strategy feature brief pulls all of these pieces together. It is a concise overview that summarizes my product vision and articulates why the components that I have designed are valuable to the users. These documents are generally used with stakeholders to ensure that everyone is on the same page when moving forward with a design vision. Below I will walk you through the main pieces of my Aspiration design brief which can be read in its entirety here.
Aspiration is an online financial firm based in California which offers socially responsible banking products and services. This brief describes the journey to design the most intuitive, accessible, and fulfilling mobile experience for Aspiration users via the new Aspiration App. Following this roadmap will increase the wallet share of Aspiration by offering a fully functional app to complement existing online banking services.
The Aspiration app product design is grounded in these three behavioral insights:
Based on these research insights, I crafted the below value promise for Aspiration users:
After aligning stakeholders through a shared value promise, I offered a roadmap by which we could achieve our vision together. At a high level, the roadmap overviews three main releases of the Aspiration App, with each new release delivering additional functionality and features.
Click here to view the Aspiration Design Brief in its entirety.
Equity has been front-of-mind for me a lot lately. When Vicky is not in class, doing AC4D coursework, or sleeping, she is working for the City of Austin. I work with a small team of delightful humans tasked with providing effective code education and outreach to increase awareness of local codes and ordinances. Well, that and “other duties as assigned”, of course.
I was recently assigned to serve on an assessment team to help my department evaluate the impact of existing city policies and practices on racial equity. The goal is to use the results of the assessment to implement new policies, practices, and programs to help identify and address the inequities that impact the quality of life for low‐income communities in Austin, which are disproportionately communities of color.
Hands down my favorite article in the latest set of readings for IDSE402: Theory of Interaction Design and Social Entrepreneurship was an AIGA piece earlier this month by George Aye, co-founder of the Greater Good Studio. If you are working in the public sector, interested in human-centered design, and happen to be reading these words, then it is worth your time. Aye offers a set of criteria or “principles” by which we could judge what is “good design” in the social sector. Effectively, he argues that good design honors reality, creates ownership, and builds power.
This brings me back to the work that we are doing to assess equity across the City. We are first taking a hard look at the past and present standing of equity in our departments to honor reality, then creating ownership by getting teams involved at the department level, and finally, we will be building power as we move towards proactive action to solve opportunity areas for improving equity in Austin. If you’re interested in this sort of stuff, all of the departmental equity dashboards are #opendata and are linked here.
I value my team at the City immensely because we ask those questions that Mike Monteiro references in this piece called “Ethics can’t be a side hustle“. As public servants, we are constantly challenging and iterating upon our outreach strategies and techniques to ensure that we are reaching communities that otherwise might not be engaged. My teammates are deeply mindful about providing equitable service to the residents in Austin, and it is a pleasure to put these theory readings into action every time I step into the office.
Granted, some of these readings felt less applicable for my current career goal of designing for the public sector. For example, Tim Wu’s “tyranny of convenience” is not usually a concern when working in local government, nor is the City yet to the point referenced by Lis Hubert where we are designing apps and interfaces so delightful that they keep our citizens glued to their devices instead of engaging with the world around them. We also don’t have the kind of budget to invest in Kashmir Hill and Surya Mattu’s super smart devices on the taxpayer’s dime.
In learning about human-centered design at AC4D, we often discuss the user and how the user will interact with what we create. Who is our target user? What does the user value? How can we design the best interaction for this user? In my work, this is also a constant discussion because our “target users” are every single human who works, plays, or stays in Austin. This makes designing for the public sector a wicked opportunity, and one that I couldn’t be more thrilled to be tackling.
In our Product Management course, we are learning methods to take a product from wireframe to market. In my last blog post, I overviewed how I met with a developer to procure an estimate of how long it would take to build out the banking app that I have been working designing on the past few months.
The next step on our journey is to downsize our ideal state app design into a minimum viable product (MVP) version of the banking app. We were also tasked with developing a product roadmap to plan out the release of key features and functionalities.
Step 1: Estimate Ideal State.
Before trimming anything out of my design to create an MVP, I had to first take stock of my ideal state design and gauge how long it would take to create. You can see that I’ve broken the below table into the main user flows and summed up the number of days required to develop each flow. As you can see, the developer estimated that it would take him almost ten months to build(!) so the next step will be to trim out superfluous design elements.
Step 2: Thin Slice to MVP.
Thin slicing is essentially the act of trimming out any components or functionalities in your app that are unnecessary and/or do not deliver value to your user. To thin slice my ideal state app into an MVP state, I went back over my notes from both my conversation with the developer and during user testing to decide which pieces to slice out of my MVP.
Based on my conversation with the developer, I decided to remove screen 1.04 (see above) because it was simply a loading screen that the user was not able to interact with. This saved three work daysfor my developer! Since my conversation and estimates with my developer, I had also already revised my “deposit check” flow to reduce development time (see below).
Finally, I decided to remove the below “Cash Flow” visualization from the spending trends portion of my MVP version of app (see below) because the visualization had mixed results during user testing and caused some confusion for users.
Step 3: Prioritize MVP.
After trimming down my design to the MVP, it was time for me to prioritize which features to start with as I began to create the product road map. I asked myself which flows were essential for a banking app? Which features were most valuable to users?
Above I prioritized the key features that were needed in order to have a functioning product: login, account balances, and the navigation menu. Next, I prioritized which functionalities were desired by users (depositing checks and transferring money) followed by a less frequent functionality (pay a friend). Finally, I decided that notifications and trend snapshots were “nice to have” but not crucial to the user experience, so these were deprioritized.
Step 4: Product Road Map.
Now that I had all my prep work completed, working on the product road map was actually my favorite part of this experience. I enjoyed testing out a new tool called Roadmunk and created the below roadmap representing the workflows for two developers working on the development of this design.
While my initial release would be extremely limited and only feature the login flow, checking account balances, and essential navigation features, the roadmap shows three additional releases each layering in new functionalities. All in all, it would take four month-long sprints to fully release my banking app… by which time there will almost be a new cohort of AC4D students beginning the program!
For the past two months, our cohort has been working on designing a banking app that integrates traditional banking functionality with financial forecasting features. In our Product Management course, we are learning fundamental methods to take a product from wireframe to market. The first step along this journey? Meet up with a developer to enjoy a dose of reality!
When design meets development
Last week, I met with my assigned developer to estimate how long it would take to turn my hypothetical banking app into a functioning reality. Together we walked through eight flows depicting various user actions (Appendix A), mulled over controls and features (Appendix B), and then the developer estimated how many days it would take for him to build out the app as designed (Appendix C).
I learned a lot during our hour-long session… definitely too much to describe in detail whilst still maintaining the focus of our faithful AC4D blog readers! Below I will instead highlight a few primary takeaways from the perspective of a designer’s first meeting with a developer, in case this advice proves helpful for anyone out there in the process of designing your own app:
Whenever possible, reuse elements as you design. This both helps to maintain a consistent look and feel for the user, and it coincidentally also drastically lowers time the required for a developer to build out your app.
Do you want your app to be available in both iOS and Android? Go ahead and double that estimation that the developer gave you! Development takes time and money, so be sure you have enough of each to make your plans a reality.
When you meet with a developer, be clear about what user goals you are designing for and remain open-minded about the details. The developer may suggest a more efficient way (see below) of designing to meet your goals!
The developer suggested that I look into integrating Zelle® technology into my banking app in lieu of developing my own payments functionality. He showed me his own banking app (with Zelle®) to show me just how easy payments could be!
The next step in this process will be to take everything that we have learned and develop a product roadmap that integrates our most desired features and functionalities for this app based on our conversation and estimations from the developer. Stay tuned!
Appendix A: Flow Animations
For your viewing pleasure, below please find animations of each flow that I designed. The red dots represent where a user would click to advance to the next screen once the requisite information has been entered.
Appendix B: Controls and Features
In the eight flows linked below, highlighted controls are red and highlighted features are blue. You may click any flow image to display a zoomed-in version of the flow.
Appendix C: Estimation Session
Click to view the estimations calculated after meeting with a developer. This shared Google spreadsheet shows an estimate of how many days it would take the developer to build out each flow based on my individual wireframes. Also included are a few notes from our discussion. Feel free to comment with any questions!
Failure is hard to admit, let alone share with others.
Jen, Laura, and I have spent the past few months understanding the impacts that impostor phenomenon has on a woman’s life trajectory. We kept hearing stories from women about how failing at something led them to give up on that path or dream entirely, and completely change course.
In starting ATX Fail Club, we hope to reframe what failure looks and feels like for women and celebrate it as a necessary part of growth and success. Sign up below to stay updated on our failures and get invites to come celebrate some truly epic failures with us!
For our latest assignment in Designing Digital Interfaces, we were tasked with merging the traditional functionalities of a banking app to offer additional capacity for financial modeling. This meant that we had to take our existing banking app designs and integrate new functionalities in a way that felt seamless and intuitive for users… and then test to see how well we had done.
I tested my design with five users ranging in age from 26 to 36. I again used the “think aloud” style of testing in which I had users talk through their experience as they tried to accomplish a few outlined tasks (or “flows”) within our banking app designs. I tested users both on my computer and on cell phones and learned that I much preferred testing users via mobile phone because the experience was that much more true to form with an actual use case.
My test users were familiar with a variety of banking apps and a few also used financial modeling or budgeting apps like You Need a Budget. During testing, I learned that it’s helpful to chart more than just one pathfor a user to achieve the desired task. Users who were less experienced with budgeting apps tended to look for new functionality via “tried and true” mental pathways.
My other significant takeaway from user testing was more generally about the value of testing your design with real humans that aren’t yourself. Your app may be your baby, but if it can’t match to your users’ expectations then it won’t grow into a successful business venture. Streamline your design to meld with user expectations such that the user can intuitively navigate through your app’s features and functionalities.
The final step in our journey with Designing Digital Interfaces will be to revise our wireframes based on our experiences in this final round of user testing. I look forward to updating my wireframe designs and flows so that they are as intuitive and streamlined as possible!
Jen, Laura, and I have spent the last three months researching how impostor phenomenon impacts life trajectories and then ideating on ways to combat feelings of impostorism. We are now pushing forward a few design ideas that came out of our research to develop potential solutions within this space.
Here is a high-level overview of the design concepts we are currently exploring:
DESTRUCTION BOX: Self-care, self-reflection, and stress relief, all tied up in one monthly box. Instead of nurturing, pampering, or creation, subscribers are encouraged to express anger, rage, and destruction by symbolically destroying feelings of impostorism.
JVL CONSULTANCY: A human-centered design firm providing company leadership with actionable solutions and recommendations to help hire, retain, and promote top talent while moving toward a more balanced and inclusive workplace.
ATX FAIL CLUB: A safe space to share your stories of failure and impostorism in your life. Curating dinner parties and storytelling events for women-identifying people to come together and celebrate stories of failure.
In order to best understand how these initiatives could provide value (to subscribers, attendees, and clients), we are currently in the phase of interviewing and testing these design ideas with prospective users. To do that, we must embrace a bias towards action. We recognize that it’s easier to offer feedback on something that already exists, so this week we:
Interviewed ten people (on some or all concepts)
Drafted a prototype online listing for the Destruction Box
In this post, we’ll share what we’ve learned so far about each concept, and then we invite you to reach out and share your thoughts on these prospective businesses.
This product is for people who are feeling stressed, burnt out, or are having feelings of self-doubt. Our solution, Destruction Box, will provide an outlet for acknowledging, reflecting on, and symbolically destroying these feelings. This subscription box allows users to physically destroy objects that symbolically represent their impostorism. Unlike other self-care subscription boxes that promote nurturing, pampering, and creation, our solution encourages women to express anger, rage, and destruction.
What we tested:
We began the week prepared to test a few hypotheses with prospective users. First and foremost, we wanted to explore how the concept of symbolic destruction resonated with people. Would they see it as both familiar and impactful? We were also curious about the logistics of the subscription box like whether or not users would be inclined to purchase the box for others as a gift and at what price point they would value this solution.
What we learned:
Our user interviews offered insight into the above hypotheses and also provided new angles to explore this concept. We learned that our interviewees had symbolically destroyed items in the past and they did find the experience surprisingly impactful. Users also opined that the Destruction Box would make a fun gift for friends or family members. We also heard interest in participating in this sort of activity in a group setting. One interviewee pointed out that if other people are destroying something, then “you feel entitled to destroy it as well”.
In the upcoming week, we will further dig into the interest in and hesitations around this business idea. We want to better understand the allure of “group destruction” and how it might fit into this design concept. We will also be fleshing out our draft Cratejoy listing and doing more “think aloud” interviews to invite feedback on how prospective users might interpret the concept when they stumble across the product online. Finally, we’ll be prototyping additional destruction activities… your brainstorms are always welcome!
This service design solution is for companies who experience gender inequities or have trouble building/retaining a diverse workplace. Through human-centered research and design, JVL Consultancy provides company leadership with actionable solutions and recommendations to help them hire, retain, and promote top talent while moving toward a more balanced and inclusive workplace. Unlike employee surveys or checklists, our solution focuses on service design approaches and is customized to each client workplace.
What we tested:
During last week’s interviews, we heard that — while this concept sounds wonderful in theory — it will be crucial to have top-down buy-in in order to effect actual change with this business. This week we wanted to validate that feedback by interviewing HR professionals to explore how best to secure top-down support for this concept. We also generally wanted to continue to invite feedback on whether or not employees would find this relevant to their workplaces and how this consultancy could maximize value to both employers and employees.
What we learned:
Our hypothesis that top-down support is vital was validated during this week’s conversations. We heard the feedback that in order to “sell” this consultancy to prospective clients, it will be important to be able to show the return on investment (ROI) for investing in this sort of work. One of our interviewees, an HR leader with over a decade of experience, ideated with us on how this solution could decrease employee turnover at companies.
One interviewee reflected back on one of his earlier positions and said that impostorism was a leading cause of his decision to leave the company. He said, “People are always looking for belonging… and that’s hard when people don’t look like you, talk like you, or think like you.” JVL Consultancy could help companies to be more inclusive thereby decreasing feelings of impostorism, increasing employee retention, and saving the business money in the long run.
In the upcoming week, we will continue to meet with prospective clients (both business owners and HR professionals) to do “think aloud” testing with our website and explore what kind of value this consultancy could provide to the client. We will also brainstorm specific companies to approach with project proposals… stay tuned for more on that front in next week’s update!
ATX Fail Club
People feel shame and guilt about their failures, and internalizing these feelings can have mental health impacts and negative consequences on life and career trajectories. The ATX Fail Club offers a safe space for attendees to share their stories of failure and feelings of impostorism in their lives, whether at an intimate small-group dinner or on stage at a public storytelling event.
What we tested:
The best way to test a concept is to go ahead and prototype it… so last night we went ahead and hosted our first ATX Fail Club dinner event! On Monday morning, we sent out an email to invite all AC4D alumnae to join us for dinner on Friday evening. First and foremost, we wanted to find out if people would RSVP and show up for this sort of event. We also wanted to test whether or not attendees would be open to sharing their stories of failure, and to do this we needed to get folks to the table.
What we learned:
From our test group of approximately 30 female alumnae, we had five alumnae who responded to express interest but who were unavailable on Friday evening and one alum who RSVPed that she could make it. And what did we learn during the event itself? Too much to share in one short blog post! But at a high-level, we heard that this concept has meat to it and we are thrilled to continue testing.
We will follow up with our dinner attendees to share photos and invite additional feedback on the event and concept. We are also currently seeking sponsors as we plan the next ATX Fail Club dinner — shoot us an email if you or your company would be interested in sponsoring either by providing food, alcohol, or financial support. Or, are you just generally interested in this design concept and want to stay in the loop as we move forward? Visit our website to learn more and sign up for our email list to receive future event invites!
The past week we have been conducting “think aloud” user testing on our redesigned banking app wireframes. During this style of user testing, I quickly found that it is incredibly difficult for me to not answer questions or help the user as they proceed through the flow! Even when they muttered questions quietly to themselves, I had to restrain myself from offering words of encouragement or guidance. Instead, my duty was to continually ask the user to explain their actions and “think aloud” through their decision-making as they navigated through the wireframe flows.
Despite my personal challenges in keeping my support silent, this form of user testing illuminated a number of interesting design opportunities. For example, one user spoke aloud as he clicked down through the steps of filling in the required information to transfer money out of his bank account, and then when he reached the bottom of the workflow he expressed frustration at needing to jump up to the top right portion of the screen to “preview” his transfer. He said: “I had to click here, do a thing, click here, do a thing, click here, do a thing… and then go up here!” By moving the “Preview” button down below the required information areas, we could help to ensure a more consistent and intuitive experience as the user navigates down through the workflow.
Beyond these more technical design decisions, one of my favorite discoveries from user testing was the opportunity to recognize and design for human emotion. For example, while banking apps may seem dry, users may get nervous when pressing “Submit” on large transactions. I heard this sentiment from my users even though there was no actual money involved: that tendency to read over the final “Preview” page one extra time to ensure accuracy before taking the leap to click “Submit”.
By taking a page from Freddie‘s book, we can design for interactions that celebrate and reward the user to make even a banking app turn into a delightful human-centered design experience.
This past week in Designing Digital Interfaces, we have been learning how to design wireframes. To do this, we used a tool called Sketch and iterated upon our last assignment to create digital wireframes of our redesigned banking app.
Being a relatively new user of Sketch, I got really into the experience of simulating potential screens for various workflows. Below is an example of the wireframe workflow that I created for the task of transferring money out of my banking app.
The next step for this course will be animating the wireframes that we have created so that a user can virtually click through the wireframes and we can test the user experience. I’m looking forward to the opportunity of finding out whether or not my wireframes are user-friendly with actual humans!