focusing in on mentorship

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

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

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

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

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

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

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

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

Meet Pax.

Falsifiable Hypothesis: For a bank to successfully add a new financial modeling system to users’ daily banking apps—for the purpose of giving budgeting tips, financial alerts, and suggested spending limits—some user support will be required.

Falsifiable Hypothesis: A choose-your-own-avatar model will remind users that real humans made the app, helping users feel in control, affirmed, and empathetic. This will lead to a positive on-boarding experience.

Test: Introduce 3 TD Bank Financial Assistant avatars, and try out 4 wireframe flows with users this week.

13

This week, we are testing our financial models with users. I was curious about the on-boarding process required for users to learn a new, complex system that is housed within an existing routine that is simple and familiar. What resistance will they feel to learning this new advanced model? What will help assuage any fears, confusions, or annoyances? What will guide them through the process with the most ease, and leave a positive aftertaste of the experience?

In designing the financial model flows, I am also testing a “human-approximation” approach. Using an “interactive” avatar as a stand-in for support is not new (everyone remembers the disaster that was Clippy). But my most positive experiences with any financial service have come down to human interaction, and I’m wondering if other people feel the same: That sitting through 5 (or 10, or 30) minutes of data-entry into savings spreadsheets feels like more drudgery than I want to bother with, but 5 minutes with a cute automated bitmoji-bot helping me figure out how to spend my money is possibly instructive, and definitely entertaining.

I haven’t tested this yet, and results are very much TBD. But below is a look at some examples of what this could look like. More to come…

15

Accounts copy

Accounts Scrolldown

3.Transaction

3 things that testing wireframes can teach us about design

This week, we took our wireframes out into to the field for user testing.

Wireframes are frame-by-frame representations of how a user moves through a digital platform in real time. Wireframes serve as a step from “information architecture” (how an app’s data all fits together in the backend) to real-world UX that we all see and enjoy.

When you’re designing an app, testing wireframes can uncover pain points and problem areas in the flow of an interaction…before you sink major resources into actually building the app.

Testing wireframes can also help designers get out of their own perspective—which is what happened for me this week! I’ve used my TD Bank app for years, and having spent 2 weeks mapping concept maps and flows, I created wireframes I thought were straightforward and user-friendly. They were, sort of. But they also created some confusion and frustration.

I took 2 redesigned wireframe flows to 4 people for testing: Check Accounts, and Deposit a Check. None of the participants use TD Bank, which was helpful as this meant they would lack familiarity and a prior sense of what they “should” do to go through the app. One user told me she is “not at all digital,” which yielded especially interesting and valuable feedback.

Here are 3 lessons I learned from testing wireframes:

 

1: Your audiences determine your design. Sometimes, these audiences are at war.

Right off the bat, users were confused by the large “Contact” button I’d added to the home screen.

I was surprised, because at a mentor critique in Chrissy’s class last week, a UX designer had liked this choice.

Eric: “Make it as easy as possible to get in touch!”

But in my testing, users were confused — or actively turned off.

User A: “Who would I be contacting?”

User B: “Is ‘Contact’ really used that often?”

User J: “I don’t want people to call me!”

I’d added the button throughout the app, in an attempt to create a sense of TD’s helpfulness and availability. But it was hitting a wrong note, which meant it actually interfered with interactions throughout each flow.

Screen Shot 2019-01-28 at 9.27.46 PM

A client and a UX developer may have different opinions. An expert and users may disagree. In this case — since the users are my primary audience — I opted to just chuck the Contact button altogether.

2: Sometimes, less is less.

My Check Accounts flow hit a snag when users got to the Accounts dashboard. I’d included only a Checking account, in an attempt to streamline the process. I thought it’d be easier for users to go through a flow with only one account option and wanted to design for them to succeed. Instead, users were frustrated as to why they only saw one account.

Screen Shot 2019-01-28 at 9.47.26 PM

User A: “Normally I have Checking and then Credit Card…why is there just one?”

User B: “Where is my Savings account? I would have both.”  

In an attempt at simplicity, I’d sacrificed usability. I’d also overlooked the pride and sense of reliance people have on seeing their accounts represented in the place they expect. Design is about creating simplicity out of complexity…and that requires understanding which complexities to keep in.

3: Building to your outlier can uncover (and solve!) hidden problems.

User A, who had told she was digitally un-savvy, also hit another snag on the Accounts dashboard. She wasn’t sure what to do next, and didn’t know to click the Checking Account bar. Though I had assumed everyone I would be talking to would be very comfortable with apps, her confusion was eye-opening. If TD is making an app for everyone, how could it design its app to be truly accessible to everyone?

In my redesign, I included a “View” button below each account. I wanted to include a visual (or audible!) cue for people who may not have the sight, familiarity, or dexterity to navigate the app otherwise.

Solution5

I hadn’t gone into testing considering the accessibility implications, but User A’s challenge helped uncover a whole other lens to consider in my redesign.

This week we’ll be continuing to refine our redesigns. For now, view my full collection of wireframes in this presentation deck.

TD Bank app redesign: wireframes

Last week, we redesigned the concept models for our personal banking app.

This week, we moved to wireframing. We began by writing scenarios and storyboards for each “flow” — i.e., the most common types of user actions.

Then, we built “wireframes” — visual representations of how a digital product will work. The challenge of wireframes is to capture every possible interaction users might have with each screen, to show how they will move through the app.

The TD app is already very user-friendly — I didn’t see any major redesign features necessary. But there were way too many menu options, which all largely pointed to the same function. So, my redesign is less “dramatically reworking user interface” and more “eliminating superfluous menu buttons.”

You can see the change in homescreens, for example, here:

Homescreen, TD Bank app
Existing homescreen, TD Bank app
My redesigned homescreen
My redesigned homescreen, TD Bank app

For wireframe flows, I chose to redesign the two functions I most frequently use in my own app: Checking my account, and depositing a check.

The original app displayed the menu before the login screen, which created anxiety [“Have I been logged in this whole time? Can anyone who picks up my phone have access to my bank account?”] and then frustration [“Oh…I *do* still have to log in before I check my account, that’s annoying.”] I redesigned the homescreen to show the login first, then menu options.

I also reimagined the menu as a series of round buttons. The round-button-menu theme shows up in other parts of the original app, but not the homescreen. I liked this aesthetic, and wanted to make it consistent. The menu screen now introduces those visual elements upfront—and dramatically streamlines the number of clickable menu options on the very first screen.

Checking your account is largely “non-functional”—that is, there aren’t many actions you can take on these screens. Clicking on Accounts will show you your balance, activity, account details, and statements. I wanted to continue the active menu options, too, to provide prompts to further action. Here is the redesign for the Accounts flow:

Checking account: Flow
Checking account: Flow

This Deposit Money flow is largely unchanged from the original TD Bank app. The progression is systematic, and the interface is intuitive. Here is the redesign of the Deposit flow:

Depositing a check: Flow

Depositing a check: Flow

A good way to tell if a flow is successful is whether the user experiences any confusion in navigating from one screen to another, or whether the user takes the wrong action to get to a goal. Tonight, we’ll be testing our first round of wireframes with classmates and class visitors. Many iterations to come…

concept map: td bank

At first pass, TD Bank has a logical, user-friendly app. Primary banking functions (account balance, transfer, mobile deposit, send money, pay bill) live in the header menu, in bright, attractive icons.

Homescreen, TD Bank app
Homescreen, TD Bank app

It’s when you start to poke around the rest of the app that its structural problems become clear. Namely—redundancy. There are SO MANY MENUS AND TABS in this app. But, confusingly, most of the information is repetitive.

Pretty sure we've seen some of this info before
We’ve seen some of this info before…
...We've definitely seen this before
…We’ve definitely seen this info before

As a result, the background information architecture looks something like this. There’s a clear hierarchy and easy navigation at first, only to get more redundant as we go further into the app:

20190109_184356

When redesigning the app, I’d start by identifying TD’s main goals for its app: Checking balance and transactions, depositing or withdrawing money, and transferring money. I’d then remove every duplicate navigation tab here, and re-arrange others to be more immediately findable.

The result would look like this. The topline nagivation has largely stayed the same. Unique features like FAQs and Feedback, once buried far into the app, have been added to a relevant parent tab (changes shown in green). And other non-core functions have been moved to the secondary menu (changes shown in green).

The “future state” concept map for the TD Bank app looks like this:

"Future state" TDBank app concept map
“Future state” TD Bank app concept map

swiss cheese of success: a concept model for persistence

The “Swiss cheese model” is a risk analysis model used by engineers, aviation specialists, and cybersecurity experts. The idea is that even the best-designed human systems (inevitably) operate like Swiss cheese—mostly sound, but with holes here and there. For the most part, systems operate as predicted. But when the holes in a stack of systems all line up a certain way, an unexpected event can slip through.

For the last three weeks, our team (myself, Shelly, and Susi) has been conducting research into how first-generation Americans in Austin perceive the role and importance of post-secondary education. One stakeholder, a student advisor at a post-traditional college completion organization, had especially salient points to make about barriers and influences on student completion: that students consistently name “relationship with my advisor” as the most important variable in their persistence; and that job changes are the number one factor in throwing students off their planned trajectory.

In our conversations with young first-generation Americans, many participants have also centered the role of family expectations, high school support networks, and legal documentation/financial aid access as determining factors re: their educational opportunities.

As we began to map out concept models for what we were hearing about persistence, influencers, and barriers, we found ourselves sketching something similar to the “Swiss cheese model”—a look at what can happen when young first-generation American students attempt to persist toward a degree. While this type of model is often used to predict negative events, we found something compelling about reworking it to show a positive situation.

In this light, the model also suggests just how hard it is for students attempting persistence to succeed.

Post_Traditional_Student_Concept_Model_v1_flat

Here, the “slices” represent external factors that impact behavior and opportunity.

The red lines represent “stopped out” student pathways, those who may sail through to success in some areas only to be met by barriers in others.

The blue line represents those students who successfully navigate each influencer/barrier in the path toward their educational goals.

As you can see from the concept model, persistence requires a precise alignment of the right conditions at the right time. And within the larger context of post-traditional students who attempt to persist, successful completion is rare, and not exclusively (or even primarily) due to a lack of individual effort or responsible studentship.

This model can describe all post-traditional students, to some degree—first-generation American students aren’t alone in feeling the pressures of family or a lack of mentorship or the necessity of holding down a job. But as we continue to conduct interviews, we suspect that the family and culture slices in particular may yield rich nuances and insights into the unique experiences of first-generation American young adults in Texas.

More to come…

insights with we are blood.

When telling our service client that we were developing “insights,” we felt the need to clarify. The word “insight” is usually treated as shorthand for “brilliant intuition,” so we knew that marching into a room of stakeholders announcing that we had insights into a service we had spent a limited amount of time with could seem, well, “obnoxious.”

But insights are not the same thing as impressions. As with everything in the design process, an insight means something specific, made up of a series of smaller processes.

To get to insights, we first examine the context, by interviewing a number of users and stakeholders and observing their behavior. Before we do anything else, we collect each of these tiny interaction points as data.

From there, we begin to make sense of this data: pulling out stories that illustrate a complex, nuance human experience of this service; combining and recombining those stories and data points to get at underlying themes; and slicing a particularly dense interaction to pull apart all of the dynamics at play in one interaction, in one environment, over time (what we call service slices).

Finally, we turn each of those themes and pain points into “why?”s. Only then are we prepared to start developing insights.

Even then, insights are largely guesswork. But unlike instant, superficial observations from newbie designers who just stepped foot into a massive mobile blood donation operation (us, mid-August), we are now equipped to offer meaningful and provocative observations about the service, because we are now armed with deep, 360-degree knowledge of a sizeable amount of data—much of which is data that company leadership has not had much access to, or synthesis around, before.

And that is not obnoxious at all—instead, it can be a viable value add to any service organization.

Here’s an example from our work with Central Texas-focused blood donation group We Are Blood:

A lot of people have been positively affected by blood donation … [but] you don’t know who gets your blood.

—Joseph, 19

“Joseph” is a long time donor. He loves giving blood because it makes him feel connected to a larger community. But he openly admits that he doesn’t know where his blood actually goes. And he’s not alone—several donors and phlebotomists alike made note of this.

As we worked through the data, this theme kept popping up for us, because a core tenet of We Are Blood’s mission is to inspire people to give blood. But they aren’t telling donors or the public about who actually gets the blood that donors give. 

There’s one good reason for this—HIPAA regulations place some constraints on disclosing recipients. But there are many other potential ways to tell these stories, and we found that presently, We Are Blood isn’t proactively pursuing these avenues.

To build from a provocative theme into an insight, we need three things:

a value statement,

a supporting phrase, and

a provocation.

To make a strong insight, the combination of all three of these things will stand on its own as a complete idea—one that, like it or not, agree with it or not, anyone can understand.

Here’s our full insight to the story from Joseph (and others):

Delivery on value promise is essential for successful service. But in contrast to WAB’s mission statement—to inspire new donors to give and to create a feeling of family—donors have no idea where their blood goes. This is a problem because WAB’s entire brand ID is built on this emotional payoff.

We drove this home with this image:

Screen Shot 2018-11-14 at 5.41.51 PM

We called this girl “Suzy.” Suzy is a stock image of a girl in a hospital. We don’t know anything else about her story. Why? Because we never have the access or the opportunity to learn it.

Instead, we do know the stories of Pat, and Gina, and Katie, and Jane, and Joseph, and dozens of others who work or show up to mobile drives. We can (and should) tell their stories in other insights…but one common theme among each of those individuals is that they don’t know “Suzy’s” story, either.

When we presented this insight to We Are Blood, leadership in the room agreed that this was an issue. They noted that they had tried various methods to tell these stories, all of which had been unsuccessful over time. We then had an invigorating discussion around things they had tried, what elements worked and didn’t, what other barriers existed to getting these stories told — and why they aren’t proactively trying to tackle this problem right now.

The next step in the design research process is to take a stab at new ideas. Some of those ideas came up in our discussion with WAB; others live on post-it notes on our wall, waiting for us to push them further.

A good insight will, above all, spark discussion and the curiosity to build new things. We’re excited to move forward into these new ideas—knowing that however provocative they may be, they will be built on a solid framework of insights, now shared by us and our client.

sketch library.

To sketch tech interactions, I took photos of team members holding phones for a variety of purposes: Watching a video, texting, swiping, taking a photo, talking. Using an existing visual model is helpful for capturing proportion and dimension … especially when drawing HANDS.

20180929_020236

I began my next iteration with pencil. This creates flexibility in practicing finger shape, position, and angle — and minimizes early mistakes, like “too many knuckle wrinkles in weird places.”

20180929_020221

This was closer, but the phone lines weren’t precise, and the right hand dimensions were a bit mismatched. For my next iteration, I traced this basic form, then added precision, detail, and line heft to the phone, and slightly adjusted right finger placement.

20180929_020159

In looking back at this iteration, the placement and visibility of the fingernails on the right hand look off. I’ve also actually lost some of the fidelity by removing the pencil lines. After consultation with the class, my next hand iteration will include light pen lines around key interaction points (bent knuckles; left finger wrapping around phone), as well as fingernails moved to the top of the fingers.

To be continued…

design existentia.

Don’t let our emphasis on “making things” fool you: Human-centered design is an existential discipline.

For the last 20 years, design theorists have been publicly weighing the ethics of designing with users or designing for them. User-centered tech is the newest frontier, but this debate first went global when design, well, went global. In the mid-1990s, socially-minded entrepreneurs began to look seriously at the systemic problem of global poverty. Universally, they came to argue that the existing global model of capitalism-plus-federally-funded international development was not sufficient as a response to rising inequality.

You probably know the name Muhammad Yunus, founder of Grameen Bank, inventor of microfinance, and pioneers. You may also be familiar with the names Dean Spears, researcher into cognitive depletion and economic decision-making models of the poor; Emily Pilloton, early adopter of the idea of place-based social impact; or Sally Osberg and Roger Martin at the Skoll Foundation, who in the mid-2000s led efforts to define and fund the idea of the “social entrepreneur.”

Each of these individuals, along with international development-careerperson-turned-journalist Michael Hobbes, businessmen C.K. Prahalad and Allen Hammond, and influential design theorist Victor Margolin have grappled with the best models for ethical social impact, and where design fits into—or drives—that model.

 

Poverty is a clear example of what designers called a wicked problem: something difficult or impossible to solve due to contradictory, incomplete, or constantly-changing components of both the problem and the criteria for success. Wicked problems do not want to be solved.

But it is clearly a problem that deserves the trying. And herein lies the existentia of human-centered design. If we agree that poverty is a negative for the people living in it; and that resources exist both within and without impoverished ecosystems that can help alleviate or solve this negative — what’s our next move?

Many designers, myself included, would say here: The people living in poverty have the best ideas and answers about what is needed to improve their lives (as all of us do for our own lived realities). The role of the truly-human-centered designer is to listen, gather data on people’s stated desires and their behavior, and work with the people to design what they say they want and need.

But human-centered design is still a fairly ivory-tower discipline. Who has the networks and the money to train to be a designer? Who has the portfolio and influence to hire design services before proof of concept? Do the people who could most benefit from human-centered design have a way of accessing these tools on their own, should they want and need them, in an unforced way?

(This tension is present even at our own scrappy school. Our class is overwhelmingly white. Our instructors are overwhelmingly male, though the students are majority female. And while no students have said this program is financially easy, the fact that AC4D does not qualify for federal loans means that each of us, to some degree, has enough of a social, financial, and/or familial safety net that we have decided we can incur tens of thousands of dollars of life-work expense for a year of training.)

If the answer to that last question — Do the people who could most benefit from human-centered design have a way of accessing these tools on their own? — is no, then we have to ask: How are we best to take design’s problem-solving approach to people in other places and circumstances without inherently doing some degree of white-savior unasked-for evangelizing? (In designer terms: How do we ensure that we ourselves are not the “non-native product introduced to a fragile ecosystem”?)

And if that’s what we’re doing … are we respecting the agency of the poor any more than an openly exploitative model?

Is your head spinning yet?

It turns out “making things” is a very intricate challenge if you believe that a third word is implied: “make things responsibly.”

To me, the designer who best represents one way forward is Emily Pilloton. Yet she doesn’t quite resolve this last tension, of evangelizing from what is ultimately an outsider’s position. Her exhortation to place ourselves physically in a place, and work from where we are planted, is to me the most ethically sound argument, that recognizes the agency of the user and respects their participation in the process.

But I wonder if we can take her challenge one step further: Instead of moving ourselves to places that we determine are in need of our services, could we instead plant our feet in the communities and networks we are already in, regardless of their wealth? If instead of communities of poverty, we exist in deep community with developers and designers and investors and founders and thought leaders … can we consider that our design field for embedded user insight? Can our design provoke those who are most insured against provocation?

In the meantime, we have these models to consider. In the spirit of understanding how these models would, and do, play out on Earth … this comic looks at how each of these design theorists approaches the wicked problem of poverty, and where I might fit, and why I want to play along.