Because we have these ways of seeing

Our most recent section of Theory of Interaction Design and Social Entreprenuership focused on what limits what we can imagine. One can start with the question, “Is imagination boundless?” That’s a romantic thought, but if we consider things that are routinely labeled “unfathomable,” we ca start to see the boundaries of the human mind.

Take Glen Berger’s “three incontrovertible facts” from his forward to his play Underneath the Lintel:

“1) The universe contains well over 500,000,000,000 galaxies, with each galaxy containing over 1,000,000,000,000 stars, of which, our vast, blazing and life-bestowing sun…is one. 2) The Earth is 4,600,000,000 years old, in which time, from the Pre-Cambrian Era to the Present—a dizzying, terrifying number of inhabitants—amoebas and trilobites, dust mites and Neanderthals—have all struggled to live from one hour to the next. (Indeed, more living creatures are in my stomach (and yours) at this moment than the total number of human beings that have ever existed.) 3) I will die. I will be dead in sixty years, though it’s entirely conceivable that I’ll be dead before the week is out.”

The three incontrovertible facts Berger lays out here are unfathomable  to me. 1,000,000,000,000 stars – I cannot hold the concept of that many stars in my head, much less imagine them all at once. As much as I have seen and contemplated death, I honestly cannot imagine what the moment of expiration will be like, or what it’s like after. Berger’s facts help me put a few initial boundaries on my understanding of the limits of my own imagination.

A saying I heard once in high school that I firmly believe and which may or may not have been inspired by John Berger's Book "Ways of Seeing"
A saying I heard once in high school that I firmly believe and which may or may not have been inspired by John Berger’s Book “Ways of Seeing”


Role of Imagination in Design

In design thinking, the designer must rely on her own understanding of the world and of her research in order to frame a problem and come up with a solution. 

Design is premised on our ability to think creatively in the face of constraints and imagine the way things could be. Our imagination, then, is a fundamental and critical part of design – so understanding it’s boundaries should be of primary concern to us.

The readings in this past section have highlighted several was in which our imagination can be limited, which have a deeper implication for how we should approach design. 

I believe that the human imagination is limited the three primary factors of knowledge, biology (the physical structures and chemical processes of our mind and senses), and context.

Three Limits to the Human Imagination
The Limits to the Human Imagination


Knowledge: What we know – who we are

The first limitation of imagination is what we know. We are each just one person, and the things we know about the world are circumscribed by our education, our personal beliefs and our emotions. 

Byron Good references how doctors in training are drilled with “facts” about the physical aspects of people that they may cease to holistically include their social-emotional aspects.

“I would occasionally be walking along a street and find myself attending to anatomical features of persons I passed, rather than perceiving them as persons with social characteristics…” Byron Good

Designers are not usually experts in the domain for which they are designing. How much a designer knows about a particular problem area and what she believes about it will influence the solutions she creates. A lack of knowledge or understanding can lead to the implementation of ineffective, tone-deaf or harmful ideas. If a designer is an expert, it is also possible to have an “expert blind spot” due to being too close to a problem. 

Biology: How we think  – education, language, perception and prediction

The physical structures and chemical processes of our mind and bodies affect how we think and what influences us. Language, Cognitive tendencies, and cultural norms all influence how we view the world. “Reframing” is a device of language that creates new context by revising a narrative.

Context: What already exists –

Context involved power dynamics, current environment, and is interpreted to create “meaning.”

“Radical innovation comes from changes in either technology or meaning.” – Norman and Verganti


Context affects how we interpret a situation and can even affect what we know to be "fact"
Context affects how we interpret a situation and can even affect what we know to be “fact”

What does this mean for how we should approach design? 

Acknowledge our own limitations, use methods of overcoming our imaginative barriers, never assume we know the whole story, include others in our acts of creation to fill in gaps of understanding (participatory design), or perhaps even acknowledge that you are not the best person to work on a particular problem space. 

Limits to what we can imagine also affects what we design and how users will be affected. Design should foster empathy and understanding between users, such as doctors and patients, in a way that breaks down prejudices. I am hesitant to use the word “unbiased” because I do not think that human beings are capable of a purely “objective” point of view. We are creatures of subjective and limited perspective. We cannot hold every fact in our heads at once, if one can even argue that we can discover every “fact.”

I agree with Norman and Verganti that radical innovation comes with changes in meaning. I studied the History fo Ideas because I believe that. A good example of this is Dubberly, et al’s piece on reframing health to Embrace Design of Our Own Well-being. 

The authors describe a framing shift from people in the role of patients being told what to do to their own health advocates and managers. This re-framing has new language that shifts work and responsibility to the individual and creates a new societal-level meaning for health care. It’s largely the care of one’s self. While this in no way “solves” healthcare, it does bring a focus back to each individual’s well-being over all time, rather than just the minutes spent with a doctor or nurse. 

The thing that has largely sparked this movement is one of the biggest limiters of imagination not yet discussed: Money. Insurers would have to pay out much less if their customers were more healthy. And a modern understanding of physical and mental health is premised on day-to-day self-care. 

Money also limits what we can imagine
Money also limits what we can imagine



The ultimate and pervasive limiter of almost all initiatives and a big driver of what we will be allowed to create in and formal capacity. Clients and businesses will have their own needs and requirements. We need to keep in mind that these constraints will almost always be the heaviest ones. 

Where I want to design

I’ve been keen on designing in the realm of immigration for years. It’s why I came to AC4D. The image below is a map I drew in a journal three years ago as I planned my career.

The career map I drew in a journal in 2015
The career map I drew in a journal in 2015

The readings on power and this recent section on the limits to imagination have made me question that goal. Should I if I am not an immigrant? Who can I bring on board? What will my institutional constraints be? Will I be able to design for those with less power, or will I be required to design things to entrench power imbalances? In that environment, what will be the boundaries of my imagination?

This is a deep question to be considered before I take on any job or project, and throughout.


Reading List

How Medicine Constructs Its Objects / Tenacious Assumptions in Western Medicine
Byron Good / Deborah Gordon

Free Ideas from a Human-Centered Designer for Hospitals that Want To Be (or Make it Seem Like They Are) Patient-Centric
April Starr

Reframing Health to Embrace Design of Our Own Well-Being
Hugh Dubberly, Rajiv Mehta, Shelley Evenson, Paul Pangaro

Metaphors Can Change Our Opinions in Ways We Don’t Even Realize
Steve Rathje

Making by Making Strange: Defamiliarization and the Design of Domestic Technologies
Genevieve Bell, Mark Blythe, Phoebe Sengers

People are people, but technology is not technology
Gary Marsden, Andrew Maunder, Munier Parker

Incremental and Radical Innovation: Design Research vs. Technology and Meaning Change
Don Norman, Roberto Verganti

The Dilemma of Empathy in Design
Richard Anderson

Design Thinking and How It Will Change Management Education
David Dunne, Roger Martin

Design Fiction
Bruce Sterling

Why Futurism Has a Cultural Blindspot
Tom Vanderbilt

The Law of Accelerating Returns
Ray Kurzweil

Why Nothing Works Anymore
Ian Bogost

You Are Already Living Inside a Computer
Ian Bogost

Your vision should speak for itself: Design Strategy Feature Brief

Three months ago, we unwittingly began crafting wireframes for a banking app re-design that is culminating here in a Design Strategy Feature Brief.

Roadmap to the Roadmap

We began by sketching the existing digital system and reconceptualizing how we thought it should look. Next we built out the wireframes and conducted user testing to see how usable our system was and what changes we ought to make. We partnered with developers to size our apps (estimating how long it would take to build out each feature) and created a strategic product roadmap for the app’s rollout based on which features should be built out and released first for maximum user value.

Feature Brief
This assignment challenged us to create a document that could stand on its own and support our decisions for the product rollout to various types of stakeholders. We will not always be present to argue for our decisions, so our vision needs to be able to speak for itself. Below is the introduction to my feature brief that frames the problem to be solved, target users, and the guiding principle for the app design.

Preface to the Bank of America app design strategy feature brief
Preface to the Bank of America app design strategy feature brief


View full Design Strategy Feature Brief here.

Challenges and Learnings


Much of my app re-design focused on recreating the existing banking app features as I learned about digital concept mapping, controls, data visualization, accessibility standards, think-aloud user testing, differences between mobile and desktop environments, and how to use Sketch for wireframing. *Phew* That was a lot to take in in one sentence, and it was a lot to learn in 8 weeks!

Ultimately, I did not create an ideal vision of my banking app based on design pillars (north-star goals) or deep insights. I stumbled through the process and learned through reflection on shortcomings and mistakes. This made crafting and promoting a future vision of the app’s rollout that various stakeholders would find compelling very difficult as I had to extract insights and argue for why I made particular decisions retroactively.

Since my all user testing involved participants in their 20’s and 30’s, I premised my simple banking app on pervasive digital products that stress people out and annoy them. I wanted to create a banking app that would be more utilitarian than feature-heavy in order to lessen the burden of *another app* on the lives of generations of people growing up connected to everything through a digital lens, from their social media reputation to their own heartbeats (e.g. Fitbit).

1 of 3 core design insights
1 of 3 core design insights gained from user testing + design theory


In a conversation with Scott Magee, I realized that I could have made a stronger argument for designing my banking app to suit my limited user testing with mostly Millennials.

“Only, I do not actually believe that.” – me

In our feature brief review with an alumnus, I was challenged with the question, “but Bank of America is an established brand with a broad user base; what about older users?” I answered that a simplified app would serve older users who, perhaps, have less digital savviness precisely because it was simplified. Only, I do not actually believe that. User testing with the intended users is the only way to confirm that all users form something “simple.” Scott pointed out that since this was a new app rollout, it was smart to target a smaller audience first (early adopters) in order to minimize risk.

Feature Brief

My strategy brief originally contained language that contradicted itself and confused the reader about who was “building the app” (an outside consultancy or an in-house design team?) and if the app already existed or if it were to be completely new. This was because my perception of the assignments kept shifting over the past three months. In our Designing Digital Interfaces course, I understood that we were mapping an existing banking app and then “redesigning it.” By listening to classmates’ presentations over time, I realized that assumptions of existing infrastructure, such as whether or not the bank had brick and mortar locations, had critical impact on how the app should function, what would be the most important features to include and to roll out first as we progressed into this Product Management course.

To best frame and prioritize my decisions, I should have considered the narrative of why this app was being created and the existing infrastructure from the beginning. Even though it was left to us to imagine which scenario we were solving for, I should be honing my instincts to begin any project by understanding and mapping/sketching the ecosystem in which it currently resides. Rooting my understanding of the problem space in reality as possible would have helped me craft better arguments for decisions and led to less confusion about my intentions for the app.

FundEDU: Crafting a Narrative

We are half way through Q4, so this is our mid-point update for Kim Nguyen, Aaron Steinman, and my project creating the education crowdfunding platform FundEDU.


We exist to create a world where financial pressures no longer force working students to prioritize work over school, allowing them to achieve their long-term goals.

Since our Last Update

Up until now we had been defining our end-to-end vision by creating artifacts for internal sense-making, such as the service blueprint and a customer journey map. This helped us flesh out how we wanted the service to work and surfaced areas that were unclear or about which our team needed to find agreement.

This week we began creating outward-facing artifacts that we could use to explain our solution and get others onboard or excited about it. We have built out several wireframes that display the key touchpoint of our platform. We will use these wireframes in our mid-point presentation today and as a demo for users, both potential donors and students. 

Below is a mockup of the FundEDU homepage, which prompts students to create a campaign, shows a gallery of running campaigns, and gives an overview of how the service works.

FundEDU Homepage wireframe
FundEDU Homepage wireframe

While crowdfunding may seem like a well-understood concept, the best way to get someone on board with your idea is to show something with which they can interact. This page shows how both donors and students will gain information about what they can do next, whether that be starting a campaign or looking at those in need of funding.

Since we think that donors will be the most important user group (we assume that students will be more incentivized to use our platform because they could receive funding for school) on which to focus in order to make FundEDU work, we also created a mockup of the donation confirmation screen (below). Along with the confirmation of payment, the screen shows other campaigns to which the user could donate. This will be useful in our solution demos with donors to see how they would potentially respond to a prompt to donate to a stranger.

FundEDU donor confirmation of donation page
FundEDU donor confirmation of donation page


Lessons Learned

There is a gray area between considering what questions are important for our idea and making something to try and answer those questions. What one needs to discuss, what is important to find out, should be considered in order to define a relevant direction. An artifact, however imperfect or low-fidelity will spark a more focused and meaningful conversation than just discussion. It became clear once we began the wireframes that the rough blueprint and sticky note customer journey map were helpful for us to define our value proposition and lay the groundwork for discussions about the content of the wireframes, which was a more granular exercise.

Our next big question is: Will potential donors be inspired enough by stories of students requesting financial assistance for higher education to donate to them?

One of the great draws of platforms like Gofundme and Indigogo are the hard-luck and deep human drama of emergencies and human suffering. FundEDU strives to equalize the worthiness of each campaign by creating a platform for this single category of causes. While some campaigns may include stories of very difficult situations, overall, anyone who comes to FundEDU can expect to see students hoping to achieve academic goals and asking for some assistance to do just that.

Now, we’ve got to

Our next steps will be to conduct solution interviews and demo our wireframes with both students and potential campaign donors to validate our most critical assumptions, define our Minimum Viable Product and then test it with real users.

One way you can help right now is

We’d love to hear from you!

Please contact us if you:

  • Have donated to a crowdfunding campaign of any sort
  • Are a student currently participating in a crowdfunding campaign for your education
  • Have any thoughts about our project or the concept of FundEDU

Ask BAE-AI: Ethical Dilemmas in Design

In the not-so-distant future, a popular newspaper decides to use artificial intelligence to provide advice on ethical dilemmas in design based on the popular Dear Abby column. It is called BAE-AI [Bay*eye].


Benevolent Autonomous Ethical Artificial Intelligence

Screen Shot 2019-03-28 at 10.48.35 PM

Dear Great Success, 

It sounds like you made a product without thinking about the social consequences, and perhaps without even knowing you cared. The first thing you should do is take responsibility for what you put out into the world. No matter what you design, you are manipulating people. It’s critical to consider whether that manipulation of behavior is towards a person’s goals or towards social good. Games are designed to draw people in and keep them coming back. As Lis Hubert would say, “do you like the world you are helping to create?” If not, then change your tune and perhaps your game. 

If you are really concerned about how your niece is using technology, sit down with her and with her parents and find out how you might design valuable life lessons for kids like her, or build in features that parents can control that make the game less obsessive for a younger audience. It sounds like you have talent for good design. Just add three more principles of designing for good by George Aye:

  1. Honor reality
  2. Create ownership
  3. Build power

Screen Shot 2019-03-28 at 10.50.46 PM

Dear Single Serve,

The tyranny of convenience strikes again! As Tim Wu says, more than individual expression, people love convenience and easier ways of doing things can be a powerful force that shapes economies. There’s no changing what has already occurred though. This design will endure long after the last cup is single served. But there is still something you can do. You can work towards changing the current situation into something better. 

As an innovator, you can be an activist for the cause of creating more sustainable products. You’ve had a lesson that the materials you choose have an affect on the individual experience, but also on the entire ecosystem. Going forward, consider where your ideas fall on the four quadrants of design responsibility, shown below.

If the product only brings good to the individual with an unsustainably sourced product, then run the other direction. Everything you create going forward can touch on all four quadrants showing that it benefits people using it, and also does little to no harm, or even improves society and the environment. 

Screen Shot 2019-03-28 at 10.56.03 PM

Dear “Good” Designer,

You obviously already know that designing with the best of intentions is not enough for the socially-minded. Considering the products and services we create as just neutral artifacts that people can choose to ignore fails to consider the power inherent in restructuring people’s surroundings and choices. In the words of Richard Anderson, “all design has social impact.”

But I also believe that it is impossible to “do no harm.” As a designer, you will face tradeoffs that produce winners and losers for everything you create. Designing for social and environmental good and designing for equity are solid north stars as you navigate uncharted waters. 

As to practically applying what you believe, well that requires a lot of mental effort, consideration, reflection, and a willingness to admit when you’re wrong. Before you begin any project and while you are executing on it, continually ask yourself critical questions such as:

  1. Who loses power from this design? Who gains power?
  2. Does this design do something for users or support the users to do something for themselves?
  3. If your design were implemented and then disappeared, could the users recreate it for themselves or are they dependent on this design?

Develop a list of critical questions that you can carry with you to every project, and use them. Keep reading about ethics and power in design to develop your own moral code. As you gain experience, you will find yourself applying and continuously adjusting that code. Sometimes, I even believe that you may need to take some projects you disagree with to completely understand why you do. But cultivate that line you never want to cross and then design the other way.

*No AI, benevolent or otherwise, were unleashed upon the world in the making of this story.




Urban Design and Architecture in the Service of Colonialism in Morocco
Assia Lamzah

Designing for Democracy at Work: Introduction and Chapter 11
Pelle Ehn

It’s Time to Define What “Good” Means in Our Industry
George Aye

Go Ahead – Ask People What They Want
Richard Anderson

Radicalizing Innovation: Are Activists the Invisible Designers?

Jon Kolko

The World that UX is Helping to Create
Lis Hubert

Anxiety and Surveillance: Pillars of the New Economy
Nicholas Carr

Using Attachment Anxiety in Emotional Design & Marketing: How Companies Use Social Pain to Stop Customers from Leaving
Brian Cugelman

The House that Spied on Me
Kashmir Hill, Surya Mattu

The Tyranny of Convenience
Tim Wu

Design Ethics
Richard Buchanan

Ethics Can’t Be a Side Hustle
Mike Monteiro

Are Designers Becoming the New Activists?
Richard Anderson

Defining Design as Activism
Ann Thorpe

Able, Allowed, Should; Navigating Modern Tech Ethics
Margaret Gould Stewart

Designing with Vectors of Influence
Uday Gajendar

Bringing a Product Vision to Life: Banking App Product Roadmap

Getting from Vision to Product

Once a product has been conceived, sketched out and user tested, the process of bringing that vision to life can be long, complex, and involve several cross-functional teams. In order to communicate the plan of execution and get all those people on board with the plan, a product manger creates a product roadmap. The roadmap is a visual tool that shows the strategy for the rollout of each part of the product over time.

After meeting with my developer to size my banking app wireframes, my next step was to create a roadmap for how two developers would create it. We learned  in class that the most efficient way to launch a product is by building the smallest version of a useful and usable product first and then adding features and capabilities on in later releases in such a way that each release adds value to the user and/or the company, depending on the product goals.

Before starting on my roadmap, I defined some assumptions and product goals in order to know what my early releases would prioritize.


Since the original banking app I started with has brick-and-mortar locations, I approached my roadmap with the assumption that my bank had physical locations as well as an existing website. I also mapped only front-end development as that was what I received in my sizing estimate.

Product Goals

The primary product goal would be to meet user goals and preferences based on the user feedback I received while testing my wireframes last quarter. This meant that company goals, such as driving users to new products or to open more accounts, would not be considered. Next, I would prioritize essential banking functionality. Lastly, I would consider the effort to build a feature in terms of work days versus the value to the user, again, based on user feedback during testing.

The challenge was to first create an ideal roadmap that included every feature of the app and assumed two developers would be working on it 40 hours per week.

Prioritizing Features

In order to figure out what features to release when, I developed a value system based on how much value each feature delivered to the user, the primary product goal. The four tiers of value were low, medium, high, and essential. You can see this process in the spreadsheet below. The features in red are less valuable, while features in black are essential banking functions that would allow the user to accomplish basic goals, such as checking their balance, and would thus be included int he first release.

Screen Shot 2019-03-27 at 6.03.20 PM

You can find the full spreadsheet here.

Thin-Slice Hero Flows

An effective way to downselect features and prioritize them is to examine the wireframes themselves and delete extraneous content. Below is an example of the log-in process that suggests eliminating the non-essential features.


The slimmed-down wireframes are called thin-slice flows. They are useful for showing which features will exist and how they will look after each new feature release. Below is the same log-in flow with the non-essential features removed.


What remains is the smallest feature set that can possibly deliver value to the user. The user can log on to the app and check her balance. This will be the only feature set in the very first release. While only having the ability to check her balance will not make the user happy, it is still useful enough to launch and build upon.

Later feature releases will include major capabilities, such as depositing a check and paying a friend. This is followed by adding back in the lower value features to make the app more pleasing to use.

Product Roadmap

In order to visualize the feature release strategy explained above and to work out how two developers working concurrently will share the work, I organized everything in a spreadsheet, which you can see below.

Screen Shot 2019-03-27 at 5.59.11 PM

You can find the full spreadsheet here.

The ideal roadmap releases the entire app within 6.5 weeks, or 61 work days with two developers. If the product launch were constrained to just one month, it could be released by the end of week 4, denoted by the first red line.

It made sense to organize the work by developer rather than wireframe flows because my previous feature release strategy broke up some of the flows quite a bit. However, I tried to keep each developer working on a single flow wherever possible because humans will be more efficient and happier working on something with which they are familiar rather than continually familiarizing themselves with something new.

Each release contains a feature set that allows the user to accomplish a new goal. It was difficult to figure out how the developers should share the work and still complete their work around the same time. Any extra days were converted to “buffer days,” which would allow for delays or more user testing.

What I Learned

Figuring out the smallest feature set that could provide value requires a set of criteria for judging “value.” A banking app seemed straightforward at first as I figured users would need to be able to use traditional banking functions. My first questions was, what is essential? Once I sat down to start downselecting features, I quickly realized there would need to be a method for choosing what to release after building the log-in and check balance features. Prioritization based on value delivered to users and product goals helped me to order the second release of capabilities.

However, I was left with 37 smaller features that could have been released on-by-one because they only supported the flows that already existed. I figured no user would want to find something new and unrecognized each time the app was opened, so I needed to limit the final feature releases to just two. Since all of the remaining features were of roughly the same priority, I figured I could chart each feature on a cartesian graph measuring value and effort, a valuation method we had learned in class. This helped me see that some features that would be faster to build and provide slightly more value to the user (again, based on feedback from the testing phase) should be released first.

I broke this iteration of the roadmap down into weeks, which was confusing for showing how work days versus buffer days were allocated and did not allow me to map out the build feature by feature. In the next iteration I would measure time increments by days and would allocate each discreet feature to a specific day.

To Build an App: Partnering with a Developer

Our Product Management class has kicked off Q4 by asking us to complete and refine our banking app flows and then partner with a developer to figure out how long and how expensive each piece would be to build through an end-to-end product evaluation. Up until now, we have been creating wireframes of what we would want a banking app to look and act like. This class is focused on how to actually bring that vision to market.

I was partnered with Chap Ambrose, an avid developer and alumnus of AC4D. To prepare the wireframes for the meeting with my developer, I had to break down the flows and label features and capabilities. This process shows how each piece of the app functions within a small slice of the experience so that it can be easily understood.

Below are my feature flows with callout explanations of specific features.



Features_2 Features_3 Features_4 Features_5 Features_6 Features_7 Features_8 Features_9 Features_10 Features_11 Features_12 Features_13 Features_14 Features_15 Features_16 Features_17 Features_18 Features_19 Features_20 Features_21

Cost of application build assuming the bank already exists 

90.5 Days

724 Hours


From Human Connections to System Change – Why I Design

Theory of Interaction Design and Social Entrepreneurship

Like many AC4D students before me, a compelling reason why I applied to this program was it’s theoretical component. To form a theory of design for one’s self is to have a set of guiding principles and an informed mental conception of how the world should be based on reflection and consideration. Should is such a tricky word, though.

This past section in our Theory of Interaction Design and Social Entrepreneurship class, we read blogs and articles that put a harsh spotlight on designing for “good.” Readings touched on designing for the homeless, crowdfunding, corporate social impact campaigns, and the colonial aspects of westerners designing for other cultures.

I saw this section as running into the questions of both the role of the designer and how designers ought to approach design. Formerly, I would have advocated for not designing for or with other cultures unless invited. My undergraduate focus on the Middle East and the politicization of Islam gave me a healthy respect for the depth of chaos and trauma cultural and economic hegemony can wreak. Singer/songwriter Phil Ochs may be crass, but he captures well the moral failure of forcing democracy on other nations for our own gain.

But, what if, through design, I had the opportunity to make someone’s life better, or perhaps even an entire population? Is it enough to make incremental changes to improve problems, or should I push for board, systems-level shifts? As we are racing through this last quarter of the program, these questions seem less hypothetical and more urgent. The heaviest question seems to be, “if it is so easy, inevitable even, to screw up or demean someone’s life, why design at all?”

Human Connections

Once, when I was 17, I stopped by a Subway on my way home from work and ordered a sandwich. There were two other teenage girls behind the counter when a man in disheveled clothing walked in and, head down and apologizing over and over, put a mound of coins on the counter and asked for anything they could make for him. One teenager came over to the other at the register and said with dismay that she didn’t know what to do because the man didn’t have enough money. I immediately offered to pay for whatever the man wanted, took my sandwich, walked out to my car, and cried. I cried because it struck me hard that I hadn’t helped the man at all. He was just going to be hungry again in a few hours. He might need medical assistance, or a warm place to sleep. And I hadn’t fixed any of that. I felt like he and I were both just trapped in the way things were. 

Thinking over that situation now, I still agree with my assessment that my actions didn’t change that man’s life in any indelible way – but, that also doesn’t mean the interaction was meaningless. 

In my role as a community member, I was moved by another person’s need and tried to help a fellow human. Such a capacity for compassion and the desire to help is  fundamental to our nature and can be the basis for meaning and purpose in our lives. 

These close, organic interactions elevate peoples’ well-being, as well as those around them. This is evident at the restaurant Robin Hood in Spain, about which author Lauren Frayer writes.

Robin Hood restaurant in Spain providing free meals to evening guests
Robin Hood restaurant in Spain providing free meals to evening guests

The Restaurant takes in paying guests for breakfast and lunch, and serves free dinners to those who cannot afford them in the evening.

Humans on the Internet

This same sense of compassion moves many to find ways of helping their fellow humans, and with the internet as a tool of instant connections leveraging that human motive, compassionate giving morphs into viral fades of giving. 

The Ice Bucket Challenge to raise funds for ALS research is a perfect example of this phenomenon. While the unsponsored “challenge” leveraged crowdfunding that gave the ALS Association a huge windfall, the uneven distribution of resources means that many other worthy causes do not get viral exposure or funding. The term “cause” even seems problematic if the objective is to move towards a more equitable and healthy society – why must diseases have to compete for public attention at all? 

What this means for designers 

Everyday and uncommon human connections create the proverbial fabric of society and our human bonds of affection, but they cannot alone shift unfair and uneven social outcomes. Designers by nature of their work, have the ability to push cultural shifts or conceive of better systems. As Jon Kolko explains, designers ought to be

“encouraging behavioral change and explicitly shaping our culture in a positive and lasting way.”

Design sits at the nexus of human connection and system change. While not a seat of absolute power, there is considerable responsibility in listening to and bringing the smallest voices to the table.





Chaos Theory
Dahlia Lithwick

On the Importance of Theory to Design Practitioners — Jon Kolko & Richard Anderson in Conversation
Richard Anderson

The Fallacy of Good: Marginalized Populations as Design Motivation
Joyojeet Pal

The [Human] Codebreakers: What Every Company Gets Wrong about Developing for the Emerging World, and How to Do It Right
Jessi Hempel

Rethinking Business Plan Competitions
Michael Gordon, Daniela Papi-Thornton

Did This New Nonprofit Crack the Code for Building Developing World Housing?
Adele Peter

Save Africa: The Commodification of (PRODUCT) RED Campaign
Cindy Phu

Sex Doesn’t Sell Any More, Activism Does. And Don’t the Big Brands Know It
Alex Holder

Our Misguided Focus on Brand and User Experience
Jon Kolko

Everything is Fucked and I’m Pretty Sure It’s the Internet’s Fault
Mark Manson

Fortune at the Bottom of the Pyramid: A Mirage
Aneel Karnani

The High Line’s Next Balancing Act
Laura Bliss

Reflections on Gratitude
Richard Anderson

A Bad Idea for ‘Fixing’ Homelessness That Just Won’t Go Away
Candace Faber

Spain’s ‘Robin Hood Restaurant’ Charges the Rich and Feeds the Poor
Lauren Frayer

Yet Another Dilemma
Richard Anderson

Banking App Redesign: Financial Modeling

Financial Modeling User Flows
Financial Modeling User Flows

This project was interesting because, unlike standard banking functionality, it required me to build something with which many people may not be familiar. The participants all had either never used a financial modeling tool, or had used one of which I was not familiar and which formed the basis of their mental models for controls and navigation.

It was a challenge to try to anticipate how users would perceive functionality, where things should live, why they are trying to accomplish the task I set up, and if they would ever use the features I was building in a natural, unprompted setting. 

1. Results: Many testers were not familiar with financial modeling or budgeting apps and tended to have manual hacks that were laborious, such as reviewing all transactions for a month by pulling up banks statements for 8 different accounts (Laura). I believe that good design should not push a feature onto a user. It should rather make obvious a simpler way to accomplish his or her goals. 

Learnings: In order to do this, there should be a useful tool within the accounts that leads to the financial modeling functionality, but only through a tool the user might find useful when reviewing their individual accounts. Discovery can happen after a positive iteration with a useful tool. 

2. Results: Participants were confused about the safe to spend and, occasionally about the savings goal because they had not set those up to begin with. The participants who had little or no experience with financial modeling functionality relied on the wording of the goal and clicking around rather than prior experience. 

Learnings: Because of this, some of my testing felt too contrived. While testing a new product may require a user to perform a task they would not usually try, there should be careful thought in what the task will be and how it is worded, so that it feels natural for the user to explore the product and dicker the functionality – not force themselves through it. For instance, instead of asking users to see if their Spotify promotion ran out by comparing this months bill to previous months, I could have asked them to see if they are spending a lot more on gas recently. 

3. Results: By contrast there were different styles of exploration by testers, which affected the participants’ experiences and the quality of feedback I received. Some were slow and asked me for reassurance and I felt confident in asking them what they thought. However, some participants wanted to click around and explore everything just out of curiosity and to get a sense fo the whole environment. The result was a rapid tour of the app that ended up frustrating one participant in particular after he found the screen that accomplished mission #1, but clicked out of it without taking it in. He spent ten full minutes searching for that screen because he though eh had already tried that avenue.

Learnings: I am still practicing setting up and facilitating a user test. I improved in setting up expectations for how a desktop test would function, explaining pacing, and talking out loud. All of the participants seemed prepared and unfazed by the limited functionality and were great about sharing their thoughts with regular or minimal prompting. 

However, I was not prepared for participants to just want to explore the environment and for those who did that quickly. I wanted to give each of them space to familiarize themselves with the app, but failed to slow people down sometimes. 

Part of the issue was that participants kept wanting to go somewhere familiar to accomplish the mission, such as their accounts. Since I had not anticipated this, I had neither connected the accounts flows, nor built financial functionality into them. Tying back to my first learning, I believe linking the financial modeling functionality in the accounts could be more useful to users as they explore.

In my next round of testing, I intend to be more structured in how I regulate the speed of the test. I will set the user up to know that I will ask them to pause on most of the screens to tell me about them first and then I will keep that as a firm structure. 

Designing for the User: Ideation to Lo-Fi Prototyping

This week our team of Kim Nguyen, Aaron Steinman, and myself  began creating and testing low-fidelity (lo-fi) prototypes of our four capstone project concepts. We will test and validate these ideas for the next three weeks to decide which one we will move forward with and build in Q4.

Getting to Ideas

Building on the research we conducted in Q2 with post-traditional prospective and working students, we applied rapid ideation techniques to come up with over 100 design ideas in our problem space.

Aaron moves a sticky-note design idea into the feasible/impactful-not fun quadrant
Aaron moves a sticky-note design idea into the feasible/impactful-not fun quadrant

The challenge was to use our insights combined with prompts, such as patterns we see in the world, and write down ideas – lots of ideas. All the ideas. I had a ton of anxiety about my ability to come up with “good” or “innovative” ideas. The rapid ideation methods helped to just start thinking.

We then filtered out the ones we found less fun, impactful, or feasible to make until we had just four sticky-note ideas left. This was a harrowing process as the results would dictate the direction of our final project.

I keep reminding myself that we need to keep what we learned from the people to whom we spoke in mind and we need to validate our design decisions based on real user feedback. The most important questions to answer moving forward is: Are we designing with the user? Are we building on a solid foundation from what we heard in the field?

Lo-Fi Prototyping

This week we considered how to test aspects of our four concepts by creating lo-fi prototypes and getting out into the field. The prototypes are ways of conveying the idea to others in order to quickly gather feedback to push iteration. Below is a synopsis of our current four concepts.

Concept 1:  Crowdfunded College

A platform that supports students soliciting loans for their education by crowdsourcing


Working students have to prioritize work over school, which leads to stress, lowered academic performance, or stopping out.


College students and prospective students will want to crowdsource student loans in lieu of working.

Testing Method and Prototype

We created a workflow diagram to explain how the concept would work.

Crowdfunding College Workflow Diagram
Crowdfunding College Workflow Diagram

We will test this diagram alongside a short storyboard to help validate the idea. Since the user would have to go through a lengthy process to solicit and repay loans, showing people the process should help them consider if that’s something they would find valuable.

Concept 2:  Me Mentor

An app that promotes habits of reflection 


Our participants told us how their time in school was challenging, not only because of the workload and academic rigor, but also the emotional and energy drain that it takes to operate through obstacles. We also heard an overwhelming need for a support network and positive people in their lives.


Low-income, working college students will want to and have time for goal setting and reflecting.

Testing Method and Prototype

We created a worksheet that helps with goal setting and reflecting and created a landing page to drive traffic. Anyone who signs up with their email can receive it for free.

Me Mentor_Guide_1

Concept 3:  Pre-Hire

An organization that uses the “apprenticeship model” to connect students to jobs in their field of study that supports their learning


Much like the Crowdfund College concept, Pre-Hire tries to answer the problem of being torn between the two competing demands on working students’ time: work and school. 


Employers will be willing to hire and support students in completing their course of study (e.g. with flexible hours).

Testing Method and Prototype

We created a pitch for employers to quickly grasp the concept and let us know if they would be on board to proceed.

Slide from the pitch to employers for Pre-HIre
Slide from the pitch to employers for Pre-Hire


Concept 4:  College Etiquette for the Bathroom

A book that delivers information about going to college in a humorous way


We learned from our research with prospective students that some did not go to college after high school because they did not have a “plan.” When they think about going to college now, they perceive the process to be a “simple” series of steps. This obscures the truly complicated web of obstacles to applying and persisting to a degree. 


High school students will be interested in learning about college through the medium of a humorous book.

Testing Method and Prototype

We created a book cover and a table of contents to show potential users and gauge their interest.

College Etiquette for the bathroom cover mockup
College Etiquette for the bathroom cover mockup


What’s Next

This week was a tough slog towards prototyping and understanding how to test our ideas. We will need to catch up on testing early this week, iterate, create new prototypes to test further aspects of our concepts. And then we’ll do more testing.

Usability of UI: Testing Wireframes

Usability testing is all about observing what people do, listening to what they’re thinking as they do it, and then discerning why they are doing it. I learned this week that understanding the motivations and feelings behind users’ actions is the key to figuring out how to move forward to refine a design.

Since last week, I have taken my banking app redesigned wireframes out to the field to test drive them with real people. This involved finding five strangers to sit with me for half an hour and recording their journeys through checking their balance, depositing a check, and paying a friend through the app.


Recruitment for this project might have been an issue if not for the AC4D community. I was able to test five friends of AC4D, including an alumna.  (Shout out to Adam and Cristina for organizing a quest and beer airframe testing meetup). While this was an expedient way to recruit, I wish I had tried to venture out and convince some people with no social connections to the school.

In our next round of testing, I plan to sit in a public space and try convincing complete strangers to give me their time and attention for compensation as small as a cappuccino. Starting conversations and practicing explaining the value of both design and wireframe testing to those with no prior knowledge of design will force me to internalize that sentiment.

All of my participants were within the age range of 32-45, and all used a banking mobile app for most of their transactions.

The Art of Think Aloud Testing

The two participants who were familiar with UX were easy to guide in think aloud testing, which has the facilitator prompt the user to continuously voice his or her thoughts. However, I struggled to word questions for the non-designer/developers. I would notice a behavior, such as moving quickly and missing an option, and could not figure out how to get at why they chose that particular path. Video recording the screen and audio recording the test helped me in review, but I shall write out a list of prompting questions for myself next time so that I don’t get completely stuck during the interview.

I also found that some participants became a bit frustrated at the slow pace of think aloud testing and me continuously asking, “why did you do that?” or, “what do you think will happen when you press that?” In the future, I will prepare my participants better for the sometimes halting pace of this kind of interview.

Problem Discovery

“I didn’t notice that problem until the moment you sat down in front of my wireframe.”

– My own internal dialogue

Testing revealed a bevy of design hiccups, but here are the top two issues I discovered:

Problem #1

Where do I click to take a photo?

In the flow to deposit a check, all participants got hung up on when and where to click to photograph the check. While most of this confusion had to do with the clunky nature of wireframes and the fact that we were testing on a laptop instead of a mobile phone, I noted that there was a universal preference to click the large photo area over the small camera icon button, which was the only way to take a photo.

Most participants wanted to click the red area to take a photo, while the green area was the only way to do so

One of the participants, Laura, clicked around for a few second before saying quietly, “I guess I’m not doing it right.”


In my next refinement, I will expand the clickable area for photographing and also try testing on a mobile phone through the Invision app.

Problem #2

To “Pay” or to “Send” money to a friend?

While working on my concept map for the app, I was reminded that nomenclature is a critical component of information architecture. I was confident that most people have had enough consistent experience with digital payment functionalities to share my understanding of the subtle differences in connotation between “pay,” “send,” and “transfer.” Testing proved that wrong.

Most participants associated ” bill pay” with a more formal debt, but there was still hesitation between that and “transfer/send” when asked to pay a friend $20 through he app.

Participants were somewhat confused about the meanings of "pay," "send," and "transfer"
Participants were somewhat confused about the meanings of “pay,” “send,” and “transfer”

I asked the participants what they associated with each term and found that inconsistent experience with how those terms are used across digital spaces and over time created the biggest confusion.

“I know transfer is they have to have your same bank, and bill pay is someone not inside your bank. But that’s not always how I feel like it works.”



Since mobile banking is a tool used by an extremely wide array of people and I learned there is inconsistency in how the terms are used in different contexts (think Venmo’s “pay,” Paypal’s “send” and the skeuomorph “wire transfer” derived from the telegraph), the solution may not meet every user’s needs.

I will try to test matching terms and concepts independently of the app first. I will try using a card sort method to test terms independently of the product and get some more data around which terms are more appropriate. I will also look for an icon that could more effectively convey a person-to-person transaction.

Moving forward, I will be refining the large and small user interface issues that surfaced during testing.