Over the past couple of weeks, we’ve been reading about the limits to imagination. And outside of school, I’ve been reading this book:
In this book, Kat Holmes talks about how many designed products reject their users, e.g. a computer mouse and can openers for right-handed people or maybe an app that only iPhone users can use.
I’ve thought quite a bit about inclusivity and design during these past few weeks as we read these articles. When we read about doctors and how they’re trained to think about patients, I thought about one of our interviews we did for our capstone project. We interviewed a transgender woman who introduced us to the idea of trans broken arm syndrome. Which effectively means that trans people don’t get the care they need for basic health concerns, like a cold or a broken arm because the doctors tend to focus on their trans status and hormones.
And this type of racial inequality exists everywhere, especially in tech. Here’s a chart of the lack of diversity in tech companies as of 2017. (image links to website.)
And why does this matter?
Because when we’re mostly white and we design for ourselves, this is what can happen:
Ian Bogost talks about his frustration with technology when he says, “So many ordinary objects and experiences have become technologized—made dependent on computers, sensors, and other apparatuses meant to improve them—that they have also ceased to work in their usual manner.”
Kat Holmes says a similar thing when she says that, “Designing for our own abilities as a baseline… can end up excluding many more people.”
So when I think about the question that Richard has been asking us, “What limits what we can imagine?” I’m afraid the answer is us. WE are the doctors approaching people with our implicit bias. WE are the ones designing can openers for right-handed people. WE are the ones designing soap dispensers for white people.
So what’s the solution? Well, also us! WE are the designers here at AC4D learning user-centered design. WE are the ones who want to design with instead of designing for.
We met and discussed the feedback from our presentation last week and further defined our success metrics.
We posted a personal and current story of failure to Instagram stories and over half of our followers viewed it to the end and we got several positive responses.
From that story we gained a few new insights, primarily that knowing that failure is a part of success does not lessen the pain of a perceived failure. Only in sharing that story with others does the pain lessen.
Lastly, we sent out our first newsletter introducing ourselves and our mission and promoting our next dinner. And within hours we had 2 more people sign up!
From our presentation feedback we learned that our stories from the field don’t connect with the ATX Fail Club offerings as well as we thought they did. That is a narrative we’ll have to work on over the next 3 weeks.
Our high-risk assumptions and ways to test those assumptions are too generic and we need to look closer at defining the values our participants will be getting out of this particular solution.
Our Next Big Questions:
Can we get sponsors to cover 75% of the costs of the dinner? And believe in the mission enough to want to sustain it?
What other channels can we create to help people share their failures in the moment vs. waiting for a dinner?
Now we’ve got to…
Focus on ticket sales/promotion on the next dinner as it’s 2 weeks away
Continue recruiting sponsors
Identify potential magic moments, and create a method for integrating them into our pilot for testing
Look into what other parts of the Failureverse can we pilot now, alongside the dinner
What is even the point of me being the oldest person in this class if I don’t share my wisdom?
Over the past few weeks, we’ve read articles on ethics and power: who has them, who should have them and what are they doing with them? As we did these readings I thought about things that had happened in my life and I wanted to share them as they relate to these themes.
Mike Monteiro writes about ethics in design and he says, “You can’t help Uber build Greyball during the day… and then buy ethics offsets by doing a non-profit side hustle. We need you to work ethically during that day job much more than we need you working with that non-profit.”
But that is what I was doing in my 20s. I was working as a designer at a print shop during the day and at night, once a week, volunteering at Texas Children’s Hospital.
The print shop job didn’t normally bring up questions of ethics for me until I got one particular project. I had free creative rein on a brochure… for a defense attorney who bragged about [getting clients off] who were accused of murder, child abuse, domestic violence, DWIs, etc.
I felt sick. I told my boss I couldn’t do it and he said, “Yes, you can and will.” Mike Monteiro also writes, “I get that you don’t want to lose your job. I get that you have rent to pay. But earning your living at the expense of someone else’s livelihood is not a good way to live.”
Did I quit my job? Sure didn’t! I designed that brochure (in hindsight I should have made it uglier) and my concession was that I made my boss enter the copy I was uncomfortable with. That way I didn’t have to “touch” the parts I was uncomfortable with. He said I was being ridiculous. Possibly, as ultimately my feelings about it changed nothing; it got printed, thanks to my work on it.
(And yes, I realize people need defense attorneys and yes I realize people also get unfairly accused and the defense attorney’s job IS to clear those accusations but there was something about this particular defense attorney that creeped me out and I didn’t get any sense that he was fighting for social justice.)
Fast forward a bit and I was working for a national grocery chain that rhymes with Shoal Moods.
I was leading a team of six designers and my boss told me that the company was doing layoffs and my team was being cut down to two. She emphasized that I was safe, but they were going to lay off my entire team and post two jobs they could apply for. Jobs they were currently doing, I might add.
I was told not to tell my team, that I had to keep this a secret while also asking the remote team members to fly in for this meeting where they’d be laid off. And they would have to decide on the spot if they wanted to take the severance or reapply for their position. This was highly unethical, in my opinion, and no way to treat an employee the company supposedly cares about.
So I told all of my team members, one at a time because they needed time to process what was happening and they needed to prep resumes and think about next steps. It was unfair to blindside them and I refused to be a part of it.
That story isn’t about visual design but about user-centered design in that I put my team’s needs ahead of the company’s policies. George Aye offers these three principles to anyone practicing at the intersection of design and the social sector:
Good design honors reality
Good design creates ownership
Good design builds power
I utilized these principles because I assessed the reality of the situation (my team was about to lose their livelihoods), I gave them a bit of ownership over their future (a week’s notice is better than no notice) and I gave power back to them (they were able to walk into their layoff meeting with dignity and state their informed decision calmly).
Fast-forward again, to the nearly present, to Q3.
Margaret Gould Stewart said in a talk at SXSW, “We always want to push the envelope, explore the ways in which science and technology can solve problems and amplify human abilities.”
And this was true for me. For my Q3 project, I wanted to create an app that could tell me which of my fellow students were at school. That’s all I wanted from it; no location tracking or data selling or messaging. Just, who’s at school right now? The real goal was to minimize stupid communication: Are you there yet? – Hey, is anyone at school because I think I forgot my jacket/laptop charger/water bottle?
But the truth was that I couldn’t prevent people from using this app in ways I didn’t intend. My privilege was that I felt safe at school and didn’t mind any of the 17ish people on my app MVP knowing my comings and goings. If this got out into the world I couldn’t keep bosses from “spying” on their employees and tracking their time at the office. I couldn’t keep people safe if they were the only one in the building and someone on the shared app wanted to harm them.
So I quietly stopped pursuing it. I did my homework assignments but I did not want to let this out into the world and I didn’t pursue it after the quarter ended. And I’m glad, especially when I read this sentiment, also by Stewart, that we should be “Designing just as much to combat misuse cases as we design for use cases.”
But someone else did create it and it’s not well-received. Hopefully, everyone else can learn from my mistakes after reading these stories.
Which is not what I tend to do on road trips, for the record.
At this point in the process, we’re taking the banking app wireframes we’ve designed, using the development plan we created with the developers last week and designing two roadmaps for launch. The first is an “ideal” roadmap, with all the bells and whistles we’ve included in our app. The second is a “constrained” thin-slice flow that allows the app to be created but with only the features we deem most important.
In this roadmap scenario we have 2 developers working on the app. I chose to lay out my roadmap by Flow on the left and labeled the project with who would be working on it, Developer 1 or Developer 2 (Dev 1 and Dev 2). That format made the most sense to me but later I wished I’d made Developer swim lanes with color-coded projects for easy reassigning.
In my first roadmap, my hours estimates are as follows:
Login Screen (inc. pre-login items) — 112 hours
Profile — 144 hours
Main Accounts page — 72 hours
Investment Account — 24 hours
Checking Account — 204 hours
Savings Account — 64 hours
Total — 620 hours
In this ideal scenario, the product is finished in under 60 days. I felt like the most important items to build out first were the Login page and Profile page but they weren’t dependent on each other, which is great because both developers could start work at the same time. The Profile page is an overlay with a lot of functionality that can be accessed anywhere in the app.
I spent more time than I expected to doing math and reassigning projects to make the product launch on time without the developers sitting idle or one working way more hours than the other. But it worked out pretty even, which I’m happy about.
For the second roadmap, we had to get our developer hours down to 320, or four 20-hour work weeks. My original roadmap had nearly double that so I had to trim a lot. Surprisingly, the financial modeling I’d built last quarter wasn’t very time consuming for the the developer I talked to so I kept it in. I started by removing things that felt bloated, like separate help pages for all kinds of accounts.
Instead, clicking this “Help” button would send the user to a help page in the browser:
I quickly deleted third party aspects like Creditwise and Zelle (everyone I know uses Venmo anyway). Beyond that, the Capital One app is already pretty streamlined so I was finding it hard to trim functionality while maintaining a usable app. I was taking out small features, like adding a profile pic or having the ability to change your Debit Card PIN in the app. Eventually I decided to err on the side of technology and I made the choice to delete the Deposit a Check feature in both Checking and Savings for this thin slice launch. It was a tough decision but it allowed me to add back in “smaller” elements like changing a Debit Card PIN or locking a Debit Card. In the Savings Account screen below, you can see I’ve removed the Deposit a Check function as well as the Direct Deposit Form, the Account Info and the Statements page. Those can temporarily all be accessed on the browser.
After cutting all the features I could, my new developer hours looked like this:
How many women connect with the idea of celebrating failure? What does the full customer journey look like for an ATX Fail Club member? These are the questions we tackled this week.
Since our last update…
We crafted social media posts to test our messaging and gauge the number of women open to celebrating failure. We shared posts from Spanx CEO Sara Blakely about the way she has reframed failure to be a positive. Our Instagram post was the most successful receiving 17 “likes” in one day. These posts drove 6 new users to our website where 1 person signed up.
We also met and fleshed out what the ideal customer journey might look like. Starting when a woman first discovers the club and ending when she is fully engaged and helping to grow and spread the venture.
Another accomplishment was getting our event registration and purchase options ironed out on the website. We previously had it set up through an app in the site for people to register, but the payment options were not ideal. This week we created an event on Eventbrite and integrated this into our website for the April failure dinner.
Lastly, we created first drafts of the mission, vision, and goals of our business. We think these will be useful on our website to better explain what the club is about, and help us moving forward align our decisions more closely to the goals and outcomes we hope to achieve with ATX Fail Club.
Time flies when you’re juggling multiple responsibilities. This week other obligations and things coming up caused us to reevaluate our initial plans. Next week, we hope to front-load more to schedule and get all the necessary supporting materials lined up early on to make this less likely to repeat itself.
We shared a video on facebook and twitter, and an image on Instagram with the image receiving more interaction. Either, image posts are more impactful than videos in gaining traction, or Instagram is a better way to engage with our audience on social media. Facebook still appears to be the best way to drive users to our website with 4/6 new users coming from Facebook and 2 from Instagram.
Our Next Big Question:
Test reactions to our newly drafted mission and goals. Are these relevant for our target audience?
Now we’ve got to…
Outline a clear testing plan for this week so that we can divide and conquer.
Define what our goals and metrics are for testing and how we will know if we are successful.
Sign up for a 20-minute video-call feedback session to offer input on our concept. You will answer a series of questions and conduct a short activity and there will be time at the end of the session for additional feedback. Click here to sign up.
Last week we took our wireframe flows from our banking apps and began to work with developers to start the process of building them out. In a perfect world we’d have all the screens built out and then present them to the developer to answer any questions and explain anything that wasn’t clear.
I had a quick call with Eric, the developer I’m working with, to chat about where I’m at and what my goals are for this project. I told him that I felt super behind he didn’t shame me for it. He would rather meet and understand the scope sooner rather than later. I told him that my goals for this project are to understand how a developer thinks. I have a print/graphic design background and I know the printing process very well and it affects how I design. I want to be the same sort of digital designer.
Eric and I met on Friday for a little over an hour and I went through all of my flows.
Deposit a Check
Find Security Code
Budget & Spending Trends
I definitely didn’t have every single screen built out nor did I have my redlines done, which turned out to be okay. Eric said he never asks for redlines for clients. What he would rather have from me is a Style Guide and markup notes on any custom animations. He also said that he always estimates 1 day per screen, unless it needs something extra. Using t-shirt sizing, “Small” = 1 day, “Medium” = 1.5 days and “Large” = 2 days. Nearly every screen I showed him was a “Small” with the exception of my Budget screen, which was a Medium and my Spending Trends was a Large.
Since I hadn’t built my screens and had no idea how many my app would need, I created a spreadsheet of everything to be done in the app. My final count was 72 screens which would take Eric about 14 weeks to build. If I’ve forgotten any screens, which I surely have, it will take longer.
Here’s a sample of just the screens needed to be built before the user logs into the app.
I have a list of what information and elements Eric wants to see in the Style Guide so I’ll be working on that. I will also continue to build out the wireframes.
As I watched my fellow students present their wireframes I started to understand why a redline would be necessary. So I’ve started the process of redlining my designs.
Am I an Order Muppet? Let me just say that when I was Art Director at Whole Foods Market I was sometimes called the branding police. I would do a store visit and walk the floor with the designer and if something wasn’t in alignment with the brand, (wrong colors, wrong font, unapproved photo) I’d pull it and ask them to redo it and talk to them about why.
We were having our annual summit and there were over 30 store designers in the room and we were having a quick “show and tell” where the designers each shared one best practice in under 2 minutes. One designer brought something that was clearly outside of brand standards but he was so proud of it and it had actually increased their sales.
Several people were looking at me, like, “Well, are you going to say something?” And I felt the clock ticking. I felt my heart rate going up and I knew it was now or never. And I chickened out. I said nothing, thanked him for sharing and moved to the next person.
I felt like a coward. And a failure. How could I call myself a leader and not lead? How could I say I loved branding and not enforce the brand standards?
I shared this with a coworker after the session and she said, “Are you kidding me? You know how sensitive Ángel* is! Calling him out in front of his peers? You would have CRUSHED him!” She was right. I hadn’t failed, I’d trusted my gut. I pulled him aside later and gave him that feedback, which he was receptive to.
Designing for vs. Designing with
When I was rebranding the materials at Castle Hill Fitness I had pretty free rein (within a budget and within the new brand guidelines, of course). So when it came time to redesign their class schedule, I thought outside the box. At Whole Foods, lots of my coworkers went to Castle Hill Fitness (it was right across the street) and we had the schedule posted on the bulletin board in the hallway. So I thought, I’ll make a poster!
And I did.
It folded up to a half-page size for easy portability and I was pretty proud of it. Several months later, some CHF employees took the schedules to an event and when people started to open them, they saw how complicated it was and set them back down. Some people didn’t even take them. I made a really cool product that nobody wanted to interact with!
So I iterated. The next version folded to the same size but was a z-fold so it was easier to read quickly.
Had I understood the value of user-centered design, I’d have asked clients what they wanted in a class schedule (designing with) and done some user testing before the final print instead of just printing what I thought was cool and assuming that everyone would think it was cool too (designing for).
My Privilege / the best of intentions
Richard Anderson asked us to read about a high-end grocery store in an area of San Francisco where the people on the streets “have little hope of eating food of any acceptable level of quality.” And I was reminded of privilege and how easy it is for the privileged to be blind to the needs of those around you. And yes, by privileged and blind I mean me.
About 7 years ago I volunteered for a program through the Austin Public Library called Talk Time. Talk Time is a program for English conversation practice with other English language learners and English speaking volunteers. I was the volunteer. The program is open to any adult who speaks some English and wants an informal and safe place to practice with others. All I had to do was show up and speak English to people who wanted to learn it. I didn’t need a curriculum or lesson plans, just an openness to conversing with strangers. People weren’t always forthcoming so I usually tried to think of neutral questions to ask and we’d go around the room and answer them.
In one of the sessions, about 10 people came in at once. They’d just arrived that morning from the Democratic Republic of the Congo. I wasn’t aware of all the violence that was displacing the Congolese people. And I still tried to ask my questions that I thought were neutral. One question I remember asking was–and I’m horrified/blushing just thinking about it, “What’s your dream vacation?” One woman answered, “This is my dream vacation. I’m here, finally, I’m safe.”
Unlike my previous 2 stories, there’s no real feel-good ending to this story. I didn’t find out that my gut was right; I didn’t get to iterate and make it better. All I can do is keep trying to face my privilege and at the very least, not offend people and at the very most, use it for good.
Last week Laura, Vicky and I narrowed our three design concepts down to two. Here are the three we’ve been working on this quarter:
DESTRUCTION BOX: Self-care, self-reflection, and stress relief, all tied up in one monthly box. Instead of nurturing, pampering, or creation, subscribers are encouraged to express anger, rage, and destruction by symbolically destroying feelings of impostorism.
JVL CONSULTANCY STEP THREE: A human-centered design firm providing company leadership with actionable solutions and recommendations to help hire, retain, and promote top talent while moving toward a more balanced and inclusive workplace.
ATX FAIL CLUB: A safe space to share your stories of failure and impostorism in your life. Curating dinner parties and storytelling events for women-identifying people to come together and celebrate stories of failure.
While logic would point to us narrowing it down to our two most developed ideas, we opted to move away from what was arguably our easiest idea, the Destruction Box, and use that energy to focus on the more wicked problems addressed by Step Three (name still subject to change) and continue to develop the ATX Fail Club.
But do not despair, the Destruction Box isn’t going away entirely! Every user we talked to mentioned that regardless of the feelings of release/empowerment/joy they might get out of symbolically destroying feelings of impostorism, they’d be snapped back to reality pretty quickly when they had to clean up their own mess. So we’re considering incorporating some small acts of destruction at the end of our ATX Fail Club events and we’d do the cleaning up.
This week we:
worked on developing our service blueprints
continued to refine the offerings of Step Three
reached out to more contacts, some of whom we’ll connect with in Q4 due to scheduling
interviewed 3 people, 2 with daily work in these spaces
worked on the outlines of our pitch decks
We narrowed down Step Three’s offerings to three:
Recruitment Package: We will review all of your job postings to ensure you are attracting top candidates. Handbook & Benefits Audit: Ensure that your handbook and policies have the right guidelines for your business. Culture and Retention Package: Create a mentorship pathway within your company.
Recruit. Retain. Recognize.
Two weeks ago we made some lo-fi Service Blueprints for all 3 concepts. Here’s an example of the one we made for Step Three:
We focused on what artifacts were used, who used them (customers or employees), where they used them (customer-facing or nah, aka front-of-house or back-of-house) and how. It was helpful in that it really made us think about every aspect that goes into creating and planning these concepts. One challenge we discovered is that when you don’t really have a complete concept of your business, it’s hard to build one of these.
NEXT STEPS: As we’ve worked to flesh out our ideas for Step Three, it will be super beneficial for us to build a separate service blueprint for each of the three services we’re offering. If we don’t do that in the next week it will be one of the first things we do in Q4. (As well as updating our lean canvases for each service.)
Our assignment over the past couple of weeks was to add financial modeling to our banking apps. I literally use You Need a Budget every day and still thought, “What’s financial modeling?” (It’s an abstract representation of a real world financial situation.)
I added a few functionalities to my Capital One app, loosely based on both YNAB and Mint. What I felt was most important was to see an overview of the total budget breakdown, a visual of spending so far for the month, the ability to categorize a transaction and an alert for out-of-the-norm transactions. (We’ll get deeper into these shortly.)
From there I conducted 5 user interviews and asked them to walk through the flows and talk me through their impressions. Of the 5, 3 use 1 banking app and mostly for checking their balances and not much else. One uses it frequently, not just for checking and savings but also investing. And one used 2 banking apps and a budgeting app (You Need a Budget).
Below are the screens I presented as well as what I learned about them from doing my user testing.
This is the home screen for the checking account.
My intention on this screen was for users to see a top-level view of their budget for the month and an alert for out of the norm spending. Once they clicked on the budget donut, they’d be brought to another screen, which had a breakdown of all their categories.
User Feedback: None of my users knew what to do with the donut image. They understood that it was a budget overview but they wanted more information about it instantly. I’d basically designed a glorified button.
Once they did click on it, they got to this screen. (“Oh! Here’s that information!”)
User Feedback: My biggest discovery by far in doing these interviews was the fact that, while I’d laid it out in a clear way, there were no numbers. There were no numbers in super key areas, especially considering that this was a banking app. This was less of an executive decision on my part and more of me learning how detailed a wireframe should be.
Other useful feedback for this screen was that a line showing where we are in the month would help them get a better sense of where they were at in their spending.
From here, users could click a category to see monthly spending trends compared to their budget as well as the transactions that are filed to that category.
User feedback: Yes, numbers on the graphs, numbers on the budget. Other questions included, “Am I budgeting the same amount every month?” “What happens if I change my budget, where does that line go?”
Another function I had added was a feature where the app lets you know if your spending is out of the norm. Clicking on a transaction with an alert icon would take you to a screen with more information.
User feedback: “Obviously my average spending isn’t including February but I’d like to know that for sure.” “Since this graph is evenly spaced, it wasn’t obvious to me that these are specific transactions, I thought it was a monthly average.” “I don’t care if I spent more than normal, I want to know if I budgeted for it.” One user wanted a place to make a note for her own records. Another user was worried it could be fraudulent and wanted a quick link to deactivate her card and alert the bank of fraud.
Another function I added in (based on my YNAB usage) is the ability to categorize a transaction. In my testing, I explained that this was a new-to-you Shell and in the past you’ve categorized Shell purchases as either travel or transportation, depending on the circumstance. We’re going to categorize this one as Transportation.
When I was trying to figure out how to design this, I read an article on why drop down menus on mobile devices were terrible and read their listed solutions and I opted for a Start Typing option.
User Feedback: First, my categories were too small. One user didn’t even notice the little alert icon. Another user said he really would have preferred a drop down menu because what if he didn’t remember his categories? Nearly everyone got stuck on the last screen because I forgot to add some sort of “Done” button.
My takeaways from these user interviews, besides adding numbers to the screens, were that I get more useful info from people who regularly use their banking and budgeting apps, some of my type was too small and other functions were oversimplified. In general, people are very interested in seeing their spending trends for the month so that’s a place I can dig deeper.
Next steps: make all these edits and present them next week in class.
It’s been a minute (since Q1) since I wrote a reflection post. And at the time I was full of nerves and had quit drinking coffee because it was making me too anxious. Q2 was much better because I realized I was in charge of my own success. And failure. So I made sure to fail in the ways I was comfortable with (I’m not staying up late drawing things; I was an art major, I’ve done that) and striving in the ways in which I wanted to grow (how do I make a concept model of impostorism? How do I tell a story people will care about?). I also began drinking coffee again.
And we’re officially in the last 2 weeks of Q3 and I have a ton of wireframes to do today so this seems like a great time to procrastinate reflect. Also because last week was hard. I got some family news I wasn’t sure how to process on Tuesday. I thought about skipping class that night. I went climbing at Austin Bouldering Project with a friend, changed clothes, and drove straight past AC4D. On purpose. I took a deep breath, turned around and drove to Springdale General and drove past the school. Again. I never do this. I normally just go to school for every class, there’s no decision to be made.
In the end, I went to class and I was glad. I went to all the other classes that week without any sort of indecision and we threw a failure dinner on Friday night which I did most of the prep for. (To be clear the dinner was not a failure, it was a successful dinner with 6 attendees who shared and celebrated stories of failure.) And Saturday we had studio and I was super distracted and felt like I was dragging my team down.
I felt so done, so exhausted. I’d felt done that morning before class. I thought about it and I’d felt done since Tuesday. Why? Oh, right, the family news. I’d been plowing through the whole week with no break. With that knowledge, I bought myself a comfort food dinner (Whole Foods soup bar beef chili over a baked sweet potato and topped with all the sour cream), lit a fire in the fireplace and curled up to drink wine and watch Fyre documentaries. (Okay, just one, the Netflix one.)
In this program, justifying breaks can be so hard and filled with so much guilt. Right this minute I could and probably should be emailing people follow-ups and building out wireframes and updating my landing page or creating a demo and working on a more in-depth service blueprint or 2 and creating/updating 2 presentation decks and scheduling something like 15 user interviews this week.
But I do not regret my breaks (including this optional refection blog post). It might all get done, it might not. It certainly won’t get done at the level of fidelity I’d prefer. All I can do is hope I’m learning what I need to be learning and know that all these things are first iterations and I can redo them for the portfolio if I need to.