dev school v2.

Good management is 360°—for the first half of the quarter, we tackled managing internal processes: How do we take a product (and a team) from concept to ship-ready artifact, on deadline? This week, we tackled the external-facing aspects of management: Showing, and selling, what we built to others.

A feature brief shares some things in common with a pitch deck: A successful feature brief will have a good value proposition, a clear mission, and viable ways to achieve it. Like a pitch deck, you’ll be showing people that there are users for this product; that you know something about what they need; and that the thing you’ve just built resolves this need.

But unlike a pitch deck, which is usually honed to a very particular audience, a feature brief is designed to translate to anyone, anywhere—so it needs a bit more technicality and “show me hows.” A good feature brief will share the high-level value of what your product is, and how it works. It should be equally compelling, understandable, and believable to the higher-ups in your own company and to a stranger on the street.

This week, we presented our feature briefs as printed and bound products. See my whole brief here.



pilot pre-work: recruitment and tools

Since our last update…

  • We presented our first-run pitch deck for our mentorship service. There was a lot in that pitch! A digital service that facilitated quality 1-on-1 mentor pairings. A couple of digital tools that solved one major pain point: Scheduling and logistics. A couple of digital tools that solved another major pain point: Onboarding and facilitation. At least one theory of student behavior change. A business plan for housing this whole system inside existing student support organizations.

As we said, there was a lot. Too much. Wayyyyy too much. It was totally unclear what “the thing” was, what the absolute most important cannot-fail part of it is, and even who our primary user is.

Based on primary research, competitive landscape analysis, and problem reframing, we really like our full solution, above. But through practicing running it in front of a public audience, it immediately became clear that we have significant trimming to do to whittle our idea down to one simple, “AHA!” compelling concept.

Which is timely, because this past week was for:

  • Designing a pilot test; and
  • Recruiting ideal participants.

Pilot test: We’ll be focusing on testing a single aspect of our service — facilitated resources for mentor-mentee meetings. We’ve developed two lo-fi resources, one for the first meeting (goal setting and future partnership flow) and one for the second (lateral-thinking exercise for practical problem-solving).

Our falsifiable hypothesis is that good mentorship is not about “the perfect match” — it is about having good resources, frameworks, and modules to stay engaged, flexible, and learning at every phase of mentorship.

And we’ll be testing that hypothesis over these next two weeks! Mentorship pairings will meet twice over the next two weeks, work through our modules, and provide feedback on what worked, what didn’t, and whether they’d continue this experience.

Recruiting: We are focusing this service for first-generation Americans (college students (mentees) and professionals (mentors)). We’re reaching out to people based in the Austin area for two 45-minute meetups. We’re requiring no pre- or post-work and will match people based on location for easiest possible meeting. In most to all cases, these pairings will not previously know eachother.

We’re recruiting previous student participants from our research, student service organizations in Austin, and others in our Austin-AC4D network.

Lessons learned:

  • Re: narrative: For our final presentation, we are going to start building it way earlier, and run it way more times, for other people. Our concept is important, but so is being able to show why and how it’s important
  • Re: wireframes: We made digital versions of wireframes to show features of the mentorship service as we were talking about it. We got feedback that this was highly effective — as we move forward with piloting and our final pitch deck, we’ll be keeping this structure of showing > telling
  • Re: pilot test: Downselecting to one “secret sauce” is tricky. We ultimately chose the mentor resources because we found it to be the best example of how our product is different; the most customizable in terms of user; and the most testable in terms of “does this actually work?”

Now we’ve got to…

  • Set up mentor-mentee pairings from our recruiting pool (we’ll be doing that matching today and through the weekend)
  • Check in with each pairing and collect feedback
  • Identify potential magic moments in the mentor-mentee pairings, and modify our resource wireframes accordingly

One way you can help right now is…

  • Contact us if you have a lead on a potential pilot participant we should reach out to! We’re currently recruiting for first-generation American college students (to be mentees) or first-generation American professionals (to be mentors). Must be in Austin. Reach us at,, or

power tools.

Microsoft has released a card game for ethical decisions around AI. Their seven ethical principles are as stated below:


While the game itself reads mostly as a light-touch brand engagement tool, it strikes me that each of these cards represents a mechanism for wielding power. “User control” provides agency to the user. “Inclusive feedback” means many users have a voice. “Transparency” should help provide understanding.

But of course, power tools are notoriously tricky to wrangle. For every attempted use of power for good, there’s the inverse questions of use and ultimate levers: Who determines which users get to give feedback? Who decides which controls to let users have (and which to deny them access to)?

Designer George Aye developed rules for what makes design “good,” and it’s his third rule I find most interesting: Good design builds power.

Good design builds power.

Being the change-minded designer that I am, I interpreted this as a radical challenge: Can power be an abundant resource, built and shared by, for, and among citizens at large?

It’s a provocative question for designers in part because our field is presently in debate about whether designers can (or should) identify as activists. As designer Pierce Gordon reminds us: Every system is a product of design intentions, whether good, evil, or neutral.

Racist, sexist, classist, xenophobic systems have been designed over centuries of institutionalized inequality.

We don’t have to look to wicked systemic problems to see design’s power in our daily life. “Most design is manipulative,” writes Jon Kolko — the act of subtly directing people toward actions they may or may not be conscious of choosing “is interaction design 101.”

The best interaction design can be helpful, used for good, even liberating and “emancipatory,” as Pelle Ehn calls it. By recognizing the design at work in our current systems, we have more opportunities to design real solutions. And that work starts where we are.

Tonight I lead the class in a game: Good idea, bad idea. We rapid-ideated a handful of truly bad product-service design ideas on a whiteboard. (A shower toaster! Fyre Fest II!) I then showed my version of Microsoft’s principles, retooled to our conversations about power. I called this my power tools deck.

[image of power tools deck]

I then asked one half of the class to make any modifications or problem-reframes necessary to turn “Fyre Fest II” from a bad idea into a good one. I asked them to consider the power tools at play — how could they use Fyre Fest II to help give inclusive voice? What could they do to build transparency into the process? Within just a few seconds, they were describing a festival that would correct some key things that went wrong with the first (real) Fyre Fest.

The other team discussed the shower toaster, and pretty quickly got to some interesting ethical places. Namely, what do we do about a hilarious(ly bad) idea that could be used for good and could also pretty obviously be used for destruction? How do we build something ethical?

In less than 5 minutes, we resolved some power-for-ill issues with one bad idea and hit the root power dilemma of another. It was a quick, messy exercise, but it got to George Aye’s key point: Building power is one of the trickiest design challenges there is. What I was testing for was this: Yes, and — can we get started, even in 5 minutes, with a silly thought exercise, as design students?

Right where you stand. That’s where you do good work.

I think so—I hope so. I’ve appreciated the words of designer Mike Monteiro, who gives us a simple entry point for beginning to design around power and inclusion.  “The answer is so obvious as to be painful,” he writes. “Right where you stand. That’s where you do good work.”

thin slicing.

In Q3, we learned how to identify what must exist in order for a product to serve its purpose (the “minimum viable product.”)

In Product Management, we are learning how to take that MVP and match it to human constraints: The labor available to build the thing.

We had two challenges this week: Produce a “thin slice” (or, streamlined) version of our ideal app, and map it to worker days; and then trim it again, to match a constraint of 40 work days total (or: a team of 2 developers, both available to work 20 hours).

After meeting with my developer, I’d already trimmed quite a bit. But my developer had given me a wide time estimate re: how long building my flows might take.

Initial hours estimate from developer
Initial hours estimate from developer. 

Here’s what I learned-and-built:

I. Pad extra time around your estimates for unexpected delays

I choose to map my flows to the 1.5x padded points estimate—my developer was reasonably sure he could execute what I was looking for (cutting out my need to map the “extreme case” hours), but it’s good practice to follow the rule of projects: Something will always go wrong. So I chose a medium-padded version to be confident that my MVP banking app will be achievable.  

II. Develop minimum success criteria for each task for clear milestones

My developer estimate sheet matches each screen to the hours required. My next step was to enter each capability into roadmapping software, and include logic criteria: What each screen must be able to do to be successful (in an MVP version). I tagged those criteria to each task, so my developer team would have them at hand while building.

What must each screen be able to do to be considered "done?"
What must each screen be able to do to be considered “done?”

III. Map each task to time estimate for sequencing

First, I mapped time by flow: Login, Accounts (passive: viewing), Accounts History (active: scrolling & downloading), and Deposit a Check. I included a milestone after each flow, signaling when an end-to-end experience was complete.

I sequenced the build by base-level need (i.e.: Login, followed by passive Accounts viewing, into more active actions).

I set the project kickoff to April 1, and gave my developers weekends off ;).

Thin Slice—Roadmap by Flow
Thin Slice—Roadmap by Flow

When mapped, it became clear that the deposit flow took nearly the same amount of time as all the other flows combined. I had mapped to flow tasks, because as a product manager, this is most intuitive for my purposes (checking to ensure sequencing is correct). But it occured to me that developers may work better looking at flows organized by person. So I also made a developer-view flow, organized by task.

TDBank.Product Roadmap.Existing - View 1 (6)
Thin Slice—Roadmap by Developer

Even with padded time, this estimate came under the next challenge of 40 work days. So instead of further slicing my flows thin, I had an opportunity to choose what to do with extra days.

IV. Build for function before building for feature

What to do with 7 extra developer days? In my original flows, I had financial modeling tools and a cartoon financial advisor. But in the flows above, I’d also left off error screens and retries—what happens when you try to take an action you can’t or aren’t ready to take. I chose to add in 3 error functions I’d previously cut.

Example Error Flow
Example Error Flow

Setting the parameters for error functionality (how many times can I try to deposit a check before it’s denied?) requires liasing with the bank and their guidelines. So my developer had padded estimates for these functions at 1.5-2 days each. Taken together, this got me to 39 days.

Additional hours by developer
Additional hours estimate from developer. Click here to see the full spreadsheet estimate.

Mapping it out to the roadmap looked like this:

Ideal Slice—Roadmap of Flow
Ideal Slice—Roadmap by Flow

Here, I aslo added in V1 and V2 versions for launches: What must be included for an MVP launch (at 3 weeks), and what would nice to have for a “more complete” MVP launch (in 4 weeks), on May 1.

Again, I also created a developer view:

TDBank.Product Roadmap.Existing - View 1 (18)
Ideal Slice—Roadmap by Developer

… And created an MVP to launch on May 1!

dev school.

We’ve been repeatedly challenged to learn this rule at AC4D: The quickest way to understand whether your concept works is to show it to someone else. This week, our challenge was to show our Q3 banking app wireframes to a working developer, work through their questions and responses (and rejections!), and get an estimate of workdays needed to make and ship our app concept.

While I still have a lot to learn about shipping a product from concept to market (that’s what the rest of this Product Management class is for!), our 1-hour meetings with a developer were grounding, humbling, and exciting all at once. Here’s a few things I learned from my first real-world meeting with a third-party developer:

Get Your Shit in Order.

I got through Q3 learning Sketch on the fly. Which means I learned some sophisticated things quickly, and also missed some square-1 basics. Coming out of Q3, my workflow looked like this:

accounts bar, Q3 wireframes

Screen Shot 2019-03-18 at 5.30.36 PM Screen Shot 2019-03-18 at 5.30.15 PM

Not only was my process disorganized—it was terribly inefficient. I still produced some serviceable wireframes, but the UI was stylistically—and functionally—a bit all over the map.

example of flows, Q3 wireframes

Screen Shot 2019-03-18 at 5.35.06 PM Screen Shot 2019-03-18 at 5.35.16 PM

This works ok for a lone designer who knows where she’s going and why. It’s totally unworkable for a team effort, especially with outside consults or clients. So my first shift was to start thinking like a managerIf I am the product lead, what parameters, systems, and symbols need to be in place so others can follow along? 

So I revamped my flow to be easily followed, searchable, and indexed:

accounts bar, Q4 wireframes

Screen Shot 2019-03-18 at 6.07.17 PMScreen Shot 2019-03-18 at 6.07.44 PM

And I learned to save key components as symbols, streamlining both my building process and others’ ease in identifying each flow.

Templates Exist for a Reason.

My first lesson from Chap, the developer I met with, was that anything customizable takes significantly longer to build (meaning way higher developer hours/expense). We sat down to look at my wireframes together, and each time we hit a customized button or login field, he would ask, “Is there specific purpose behind this being customized?” Usually, the answer was “No”—iOS would be fine, and I’d just either not known that was an option, or had just tried to make something cute for the fun of it. Where that approach may work for user testing on the design end, as a product manager you inherit significant constraints—specifically, money, and time.

At his encouragement, I revamped my login screens to use existing iOS buttons and alert formatting. If I’d customized something with specific intent, I kept it. If iOS would work just as well, I swapped it.

You Have No Idea How Long Anything Will Take to Build. 

It turns out I am very bad at predicting what will take a long time. Bitmoji? Only 1 day. Edge detection to capture a check for mobile deposit? Up to 5 days. Linking your app with a third-party bank account? Entirely dependent on any existing agreement between your bank and the other bank, and whether a plugin exists or we have to build one from scratch…so this could take anywhere from 1 day to several weeks. Which brings me to:

Come With As Many Scoping Problems Answered As Possible. 

I had some major blindspots coming into our meeting. I didn’t know if this bank app integrated with others. I didn’t know how many login attempts a user could make before the bank would suspend their account. I didn’t know how far back I wanted users to be able to scroll back through recent transactions before being required to just download their statement. Chap raised several questions around bank data-sharing and “length of time” in my apps’ features, none of which I knew how to answer. This creates uncertainty for the developer, and as Chap told me clearly: The more complexity and uncertainty you throw at a developer, the higher their burden…and they will quote you a (n expontentially) higher rate accordingly.

Chap’s “developer days” estimate. Left: Initial estimate. Center: Scaled 1.5 if mild uncertainty/unclarity. Right: Scaled 2.0 if significant uncertainty/clarity. Note the huge spread between “best case” and “worst case” quotes.

developer’s “developer days” estimate, Q4 wireframes

Screen Shot 2019-03-18 at 5.53.32 PM Screen Shot 2019-03-18 at 5.53.14 PM

With Chap’s feedback in hand, I revised my wireframes: More customized to iOS style; fewer screens to do the same job; and key components broken out for quick reference.

Those are below:

flow: login

Screen Shot 2019-03-18 at 6.08.14 PM              Screen Shot 2019-03-18 at 6.08.29 PM

Screen Shot 2019-03-18 at 6.08.40 PM

flow: check account

Screen Shot 2019-03-18 at 6.08.50 PM

flow: deposit a check

Screen Shot 2019-03-18 at 6.08.58 PM

Screen Shot 2019-03-18 at 6.28.56 PM

Screen Shot 2019-03-18 at 6.09.08 PM

Screen Shot 2019-03-18 at 6.09.27 PM

Screen Shot 2019-03-18 at 6.09.36 PM


Screen Shot 2019-03-18 at 6.23.35 PM

Screen Shot 2019-03-18 at 6.23.44 PM

Screen Shot 2019-03-18 at 6.23.55 PM

Screen Shot 2019-03-18 at 6.24.07 PM

Screen Shot 2019-03-18 at 6.24.29 PM 

design from what you know.

As designers, we are familiar with schools of theory that urge us to use our wealth of design for other people who are in need—and similarly-passionate schools of thought that tell us that to do is hopelessly narcissistic and that to parachute in, no matter how thoughtfully, robs others of agency.

Through this, I appreciate the words of Candace Faber. Faber suggests that to draw this dichotomy is to begin with the wrong problem frame.

To Faber, to distance ourselves from others is to ignore how similar we really are—and that our tendency to impose these distances is out of a desire to deny that we could ever be in a similar circumstance. 

“There is not a single person whose investments are totally safe or whose sense of belonging in society could not be overturned overnight.” —Candace Faber

I want to suggest that designing from what we know and love is not only responsible—it is provocative. Design is a problem-seeking process. To design from what we know and love is to first acknowledge that our own contexts have problems, and next to permit ourselves to imagine possible solutions.

A few months ago, writer and professor Anne Helen Petersen wrote a viral essay on “millennial burnout.” It provoked immediate add-ons, backlash, and critique (as is the recipe for anything that attempts to define something about millennials). What I found most interesting about this column was its attempt to redefine an ill-structured problem. Petersen took stereotypes about millennials (“lazy,” “entitled”); economic realities (gig economy; erosion of labor unions; the first generation in 100 years to earn less than their parents); and new communal/relational/psychological realities (disappearance of community foundations and religious traditions; declining rates of marriage and childbirth; the rise of social media) and put it through an analysis of human behavior. “Given this context, how do I understand the behavior I am observing across an entire generation?”

Given this context—how do I understand the behavior I am observing across an entire generation?  

Crucially, Petersen begins the work with herself. She does not position herself in a posture of privilege, seeking to understand an “under-explored,” anonymized population—her work goes through her own heart. The resulting essay is confessional (self-analytical), observational (tracking behaviors of friends, colleagues, and students), and analytical (extrapolating to larger contexts). She is sensemaking, on the way to coming up with a problem definition.

That definition is remarkably simple: That we as a generation are facing systemic burnout. But she follows with a provocation: That millennials’ attempted solutions for burnout—to do more; to be more; to pour money and time into attempts at “self-care” (taken together, what she calls “a culture of self-optimization”)—not only fails to work our way out of burnout, but in fact contributes to it.

“I never thought the system was equitable,” she writes. “I knew it was winnable for only a small few. I just believed I could continue to optimize myself to become one of them.”

What I find interesting about this problem definition is that it reframes quite a bit about our state of the world—both our participation in it, and the ways it makes us ill.

Defining burnout shows, first, that the tropes of the “lazy” “entitled” millennial are not necessarily wrong, so much as grossly incomplete. And second, that our cultural obsession with efficient self-optimization is not only the wrong solution, but a contributing factor to the problem.

It suggests that our language (“millennials are killing homeownership!”) around the problem of burnout is wrong, because our underlying assumptions about human behavior (“millennials are pampered and can’t handle the adult skills needed in the real world!”) is wrong.

If the drive to self-optimization is a compounding factor, Silicon Valley’s obsession with efficiency may not be the wrong motive so much as the wrong solution to a salient, wicked problem. Our particular generation’s extreme drive to self-optimization and self-improvement in the lens of the marketplace is not at all workable as a collective (or even personal) solution. Something much bigger and more comprehensive is needed in how we understand how society is structured.

Petersen’s burnout insight isn’t new, so much as a new way of defining a problem. But the model has potentially very interesting implications as far as what solutions might look like. 

Our task as designers is to define the problem, and then attempt to make solutions. As I consider what solutions to burnout could look like, I’m carrying the words of Faber:

There is only our choice to treat one another with dignity and compassion — or not.

And why build solutions for “others” while rejecting that those same solutions could be the ones that I, too, will—today or someday—desperately need?


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.


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…


Accounts copy

Accounts Scrolldown


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.


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:


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