Improving Humanity by Improving AC4D

As the ninth cohort to (soon) graduate from Austin Center for Design (AC4D), this assignment felt particularly appropriate to the end of our 8-month journey.

Our task: to develop and present a case study of how to improve AC4D within one of the following areas: financing, bootcamps, continuing programs (for alumni), and recruiting.

AC4D’s main offering is a 1-Year Course to earn a Certificate in Interaction Design and Social Entrepreneurship. My intent was to develop a strategy that could significantly impact participants of the 1-Year Course. That area is recruitment.

Video of the full case study.

Since AC4D was founded in 2010, design teams, processes, and fundamentals have gone from nascent to ubiquitous within the larger business world. Capital One, USAA, even Wal-Mart now have design teams and process that were once only achievable by design firms like frog design or Argo Design.

IDSE 401 Assignment 4.003

The influence of interaction design is strong, particularly in businesses with influence. AC4D has a duty to its social entrepreneurship roots to not only influence business, but to graduate students who can affect “wicked problems.” These are the large, complex solutions like poverty and natural resource management that have no easy fixes, or one set of key performance indicators.

The problem is that AC4D’s cohort does not reflect the diversity of the United States, nor Austin. It has typically recruited, taught, and graduated people who look like me (white) and have a history like mine (privileged.)

IDSE 401 Assignment 4.008

One of the key takeaways from our Theory classes at AC4D is the recognition of “designing for” versus “designing with” and how designing for wicked social problems is not as easy as implementing the “correct” solution. Take perhaps the most wicked problem of them all- inequality. Do you suppose that the most privileged members of a society can single-handedly design a solution for a minority community? No. Nor should they.

IDSE 401 Assignment 4.010

Design requires expertise, but expertise formed by working in and with, and on behalf of communities that designers aren’t often members of. There’s limits to what a non-members can do, as there are limits to empathy.

That’s why AC4D should launch a targeted effort to recruit local, minority community members to join AC4D.

IDSE 401 Assignment 4.015

The time is right for AC4D as well: with the school now in a larger studio space, the average cohort size has doubled, from 8 to 16 students per year.
IDSE 401 Assignment 4.018

The goal: For 25% of the 2020-2021 cohort to come from Austin’s diverse community. We begin with 5 local chamber of commerces, and the method is lightweight, and low-risk. Each step builds on the next, proving if the outreach is worth devoting more resources.

IDSE 401 Assignment 4.019

The method is simple: communication with chambers of commerce for a complimentary presentation to its members, and a the basics of AC4D’s outreach and scholarship efforts.  AC4D reps present on design thinking and its rapid rise in the business community. They end the presentation with an ask: encouraging minority candidates and their contacts to apply, with scholarship details.

IDSE 401 Assignment 4.020

As leaders in making design education affordable, AC4D is well suited to attempt this outreach strategy. The future of wicked problems depends on all communities having access to creative problem solving methods and practices.

IDSE 401 Assignment 4.028

IDSE 401 Assignment 4.029

The Future of Design (Or, How Things May Not Be That Different From Now)

Yuval Noah Harari
Yuval Noah Harari, author of Homo Deus: A Brief History of Tomorrow.

I would like to tell you about a book I’ve just finished. It’s one of the finest books I have ever read.

Reading this book also bolstered the belief that I’m in no position to make the previous claim. I’m a human, a fledgling designer, and a biological creature. Which makes me a product of evolution, prone to cognitive dissonance, and recency bias.

The implications of these faulty human traits become clear in Yuval Noah Harari’s Homo Deus: A Brief History of Tomorrow. But more than proving we’re faulty creatures, Harari’s thesis should resonate with anyone who has a stake in design.

Humans, Just Another Animal? 

Harari is a historian, a realist, and most likely, atheist or agnostic. He contends that humans have dominated the planet due to our creation of fictions.

Our fictions are the fuel that propels our dominance on the planet. These stories define our uniqueness within the animal kingdom: the ability to organize in groups far above 100. The utility of money is a tangible example of a shared global fiction. A $100 bill is a piece of paper, but we all agree on the fiction that it has value.

Harari details how our ability to organize under shared fictions has led to the Anthropocene, the current age where human activity is the dominant force on the Earth’s environment. But it’s not only the Earth we’re changing.

We’re beginning to modify our genetic code, we’ve extended our lifespans, and we can ingest mood-lightening pills to ease our worries. Harari writes that as we reshape our biology with greater precision, it’s the old and new fictions that will guide what we create.

Huxley, Orwell, and Atwood all warn us through their literature that as we gain greater biological control over ourselves, we’ll lose our humanness. But maybe those warnings aren’t predictions just yet. Today, mitigating depression with an accurate dosage of chemicals has made life livable for many people. The trouble, Harari writes, is that our scientific developments in the life sciences (biology, behavioral economics, cognitive psychology) are quickly eroding the dominant shared narrative most of us live by.

You’re a Humanist, Like It or Not 

The dominating narrative of our age is humanism. Most of us have grown up with a feeling that “I am a unique individual with a clear inner voice that provides meaning to the universe.” Humanism sanctifies life, happiness, and the power of Homo Sapiens. It’s a story that says, “It’s up to me to choose what is right, what is art, what ice cream is best.” It also says “It’s up to you to choose the same for yourself.”

“Feelings” can have a very touchy-feely connotation, but it’s also humanism that fuels capitalism, choice, and our sense of freedom. It’s what legitimizes voting, and urges us to seek more equitable justice.

And it’s here that Harari’s warnings begin:

The humanist belief in feelings has enabled us to benefit from the fruits of the modern covenant without paying its price. […] What, then, will happen once we realize that customers and voters never make free choices, and once we have the technology to calculate, design, or outsmart their feelings? If the whole universe is pegged to the human experience, what will happen once the human experience becomes just another designable product, no different in essence from any other item in the supermarket?

We’re Walking, Justifying, Narrative Machines

If you’ve ever concluded that humans are irrational and fickle, you’ll not find much argument from Harari. What sets his writing apart is how he synthesizes scientific developments in light of our ancient human fictions.

A few of the unsettling scientific developments in irrationality:

  • fMRI scanners have proven your brain makes decisions before you’re aware you’ve made them
  • Split brain experiments have shown that humans are experts in cognitive dissonance, sliding into rational explanations even under bewildering circumstances
  • Behavioral economics has shown humans “narrative self” consistently overpowers our “experiencing self,” which turns the irrational, unpredictable choices we make into the illusion of a coherent, individual story (referred to as “System 2” in Daniel Kahneman’s terminology)
Daniel Kahneman receiving the Presidential Medal of Freedom. Many of his experiments led to the conclusion that we have a "narrating self" that makes justifications inconsistent with our "experiencing self"
Daniel Kahneman receiving the Presidential Medal of Freedom. Many of his experiments led to the conclusion that we have a “narrating self” that makes justifications inconsistent with our “experiencing self”

Dear Algorithm, Tell Us What To Design

Most of us don’t design by religious guidelines or by a dictator’s demands, we design for an environment where individuals are free to choose: my barstool or Ikea’s, your app or Apple’s. We believe in choice, and we design knowing there is a choice on the user’s end (most of the time).

Harari foresees a conflict here. On one side, the humanistic legacy and individual choice. On the other, the developments of science and technology, along with the rise of algorithms which increasingly make choices for us. Harari writes: 

Humans are relinquishing authority to the free market, to crowd wisdom and to external algorithms partly because we cannot deal with the deluge of data. In the past, censorship worked by blocking the flow of information. In the twenty-first century censorship works by flooding people with irrelevant information. […] Today having power means knowing what to ignore. So considering everything happening in our chaotic world, what should we focus on?

This leads me to imagine a loop that will impact designers at a high level:

  • We’ll continue to design based on witnessed human behavior, but will have to fight louder for a voice among the screams for large quantitative data
  • Big data collection and the algorithms will increasingly affect what gets made
  • What gets made = what gets used
  • We’ll increasingly study human behavior that’s created or influenced by algorithms

Pessimistic enough? I suppose Harari brought it out of me. But his book isn’t simply pessimistic. It’s an exercise in reflection and an attempt at broad foresight. More optimistically, it helped me gain a sense of the big picture of creating things for fellow humans.

Are we in danger of designing for “data fiends” who may trust algorithms over individual feelings? In reaction maybe we’ll design for the opposite, an “intentional ignorance,” or peace of mind that purposely avoids the prescriptiveness of data. Perhaps the data will show us more clearly our cognitive dissonance and we’ll act differently, more efficiently, or even more ethically.

Whatever we’re called to design, we should recognize the fictions we’ve been operating on, and act on the the stories we want told in the future.

Ally Bank: Mobile App Redesign Strategic Roadmap

In January 2019 our cohort at AC4D began the long process of designing a mobile banking app. Over two classes, Designing Digital Interfaces and Product Management, we’ve practiced a myriad of skills: designing concept maps, wireframes, user testing, adding additional app functionality, and meeting with developers for app development.

This past work has culminated into this document: A strategy brief. You can view the full brief here, or peruse the following description and reflection on the challenging but rewarding process of mobile app development.

Assignment 3_Design Strategy Feature Brief .001

The purpose of this document was to build trust between the Ally design team and other departments that require sign off.

I attempted to make this as clear as possible from this screen:

Assignment 3_Design Strategy Feature Brief .004

In our scenario, Ally does not have a banking app, which led me to a value promise based on insights.

Assignment 3_Design Strategy Feature Brief .005

The road map provides a step-by-step breakdown of the app’s development, here’s the opening roadmap slide:

Assignment 3_Design Strategy Feature Brief .010

This high-level roadmap leads to a more specific breakdown of how we can build the core functionality of the app in 20 working days:

Assignment 3_Design Strategy Feature Brief .016

What are we building? Key features are detailed in the Capabilities section:

Assignment 3_Design Strategy Feature Brief .018

Reflection: 

This assignment forced us to communicate with many audiences, and play different roles ourselves: design teams, including User Experience (UX) and UI (User Interface) designers, developers, product managers, and C-suite executives who would make a decision.

I plan on adding an Executive Summary to this document. And if I was to do it over again, I would be sure to recruit a wider age range of users.

Through this assignment, I gained the confidence to work within Product Management frameworks, and to communicate with a wide range of people and roles who have a strong impact on product development.

 

 

Mid-Term Progress Update: Optimizing Effective Advising

Cristina Suazo, Zev Powell and I are building a tool to assist advisors of non-traditional college students broach the topics of self-advocacy and social and emotional learning. Our tool is a questionnaire that optimizes the short time advisors have with their students, making sure that the sensitive root causes of problems are the center of the conversation.

This week:

Our team focused on preparing a mid-term presentation, complete with design artifacts and product mockups, to prepare for our final Capstone presentation on Saturday, April 27. Here’s what we accomplished:

  • Storyboard: We created storyboard drawings to show how a college student and an advisor would interact with our tool.
  • Mockups: We also created examples of how our digital tool would appear on a student’s phone, and on an advisor’s computer.
  • Current/Ideal State Journey Maps: We got up to version 4 of these artifacts, which visually represent the current state of advising (how social and emotional indicators are unseen). We also made an ideal state of how this changes if our product is used.
  • Presentation Practice: We ran through our draft presentation twice, once with Emiliano Villarreal, an AC4D professor.

This coming week we will:

  • Get feedback on our mid-point presentation, making a plan for the final four weeks of our program.
  • Refine our three major artifacts.
  • Determine if we need to engage in more pilot testing.
  • Book additional AC4D alumni and network for presentation critiques.

How you can help:

Put us in touch with:

  • Any college advisor/advising department at a 4-year university, anywhere in the United States. We want to know what systems they use to maintain their relationships with students.
  • Anyone who designs products for any higher education learning institution, in order to improve our artifact and pitch
  • Contact Cristina and/or Adam at cristina.suazo@ac4d.com and apruem@gmail.com.

Welcome to Toad Design: Your New Hire Training Video!

Welcome Toads!

So glad you’re joining us. You’ve just been hired, in case you didn’t check your inbox today. You will be a junior designer at our office starting Monday! Get excited!

In order to help prep you before meeting your fellow toadies, we put together this little training video. It’s just over 5 minutes, so sit back and enjoy.

Author’s Note: If you haven’t guessed, this is a work of satire and exaggeration.

I found this negative tone to be a framework in which to imagine the worst case scenario for a junior designer. Of course, businesses are never this transparent about their aims, whether they be good or bad.

During our AC4D Theory class, I’m continually grappling with the realities of the world versus the noble standards of ethical designers. Working in a typical design environment its easy to simply do the work that’s given to you. If a project’s goals seem nefarious, most people don’t quit their jobs if a project tests their moral mettle.

As a designer, I hope to change the landscape of design by working for private businesses that work publicly- literally, on public projects for local, state, or federal governments or similar institutions. Call it my civic calling.  I have some experience in seeing how good work can be done in education, public health, and water conservation, albeit through through advertising- a fickle and fleeting craft that rarely creates behavior change in these areas.

One last note. A well known design firm and their mascot were an easy muse for me here. This is not an accurate reflection on their business practices. In fact, this firm has worked for the United Nations. My hope is that they will make this trend, and other leaders in design will follow.

 

Three’s A Crowd: Designers, Developers, and Clients

Background

So far in our Product Management class at AC4D, we’ve re-built and tested a banking app with wireframes (mockups of how a screen will look). Subsequently we met with software developers to gauge the feasibility of our new features.

Over the last two weeks we’ve slowly added another perspective in our design mix- the client. Unfortunately, the good folks at Ally Bank (the online-only bank I’ve chosen) haven’t been able to visit our Austin, Texas studio, but as designers we’ve begun to create artifacts that speak to precisely how our apps will meet client needs.

How We Deliver

Each of our banking products requires a product roadmap to show who, when, and how our banking app will be delivered. A flow is a set of steps a user needs to take to accomplish a goal. Let’s take my Log-In flow as an example:

The Log-In flow for Ally Bank's mobile app
The Log-In flow for Ally Bank’s mobile app

My developer mentor estimated that this flow would take three working days for one developer to complete. Our assignment had us operate under the assumption that we have two developers working 40 hours a week to build our app.

Product Roadmap: Ideal State

My product map is structured on two axes: time (in days); and resources (in this case, two developers to do the work.) Log-In, a mandatory task for any banking app, should come early in the process. Notice Log-In is first in Developer A’s queue. I tend to make first versions on paper and whiteboard for efficiency.

The first version of my product roadmap, with each sticky note denoting one working day.
The first version of my product roadmap, with each sticky note denoting one working day.

I then digitized this version of a product roadmap:

Screen Shot 2019-03-27 at 4.13.44 PM

This is where an inefficiency appeared. Developer B had a lot less work, so I moved around some flows in order to balance the workload:

Screen Shot 2019-03-27 at 4.17.43 PM

Now the workload is more even between developers.

App development (and interaction designers) generally work in “agile” workflow systems. This means that multiple tasks can be accomplished at once. In other words, it’s the opposite of an assembly line where “A” must happen before “B.”

While I could have even moved flows around further and end up with one “open day” per developer; the flows have a general sequence logic. I wanted Developer A’s “Log In/Log Out” flow to occur in parallel with Developer B’s “Security, Privacy, Forget Username & Password” flow. They may have similar issues, and can collaborate if problems arise.

In this “ideal state” roadmap where we take as long as we need; in total the core app development will take 42 days workdays, or 22 actual working days for developers.

Product Roadmap: 20-Day Releases

Often, designers and product managers don’t finish an app in one attempt. More often, firms publish a base functionality, and continually add and update features. In our assignment’s second scenario, I imagined publishing app features in 20-day increments. In my particular case, my whole app took 22 total days, so I inserted extra features and functionalities (like Live Chat help) to make my banking app more robust.

This how my product roadmap changes with this 20-day constraint:

Constrained Roadmap v1

 

Here we see significant features added at the 40-day and 60-day mark. I also changed “open” days to “QA/open” so our clients will know we’re completing a quality assurance process at the end of our 20-day sprints, rather than taking a day off.

A Roadmap for All Audiences

The roadmap above is not client-ready. While a draft roadmap is instrumental in getting developers, designers, and product managers on the same page; it’s too grey and dull to be put in front of a client. In order to gain the client’s trust in the process, a little bit of clarity and color can lessen a client’s worry.

Here’s a more polished version:

Ally Bank Client Facing Product Roadmap

With this roadmap, all audiences can feel that there are clear and legitimate benchmarks that will be meant. Some journeys are better without maps, but for adventures in app development, a product map is a must.

You can view all of the above artifacts in one PDF sequence here: https://drive.google.com/file/d/1HyraIUGcH4Q5xmwW12zvk5XnNB-zaLvn/view?usp=sharing

 

 

 

Designer Needs Developer: My Blueprint for Building an App

Begin, Again.

“Starting Over!? Nooooo!” said my internal monologue. I knew I had to begin again.

In the final quarter of our year as Interactive Design students at AC4D; we’re learning the pathway to bring a design into the real world. And that pathway can have many restarts or forks in the road. In this case, I’ve redesigned my banking app, Ally Bank, for mobile Apple devices.

I spent the last few months making mockups (called wireframes) on paper and using the program Sketch. I tested my redesign with users, made changes, and went back and started it all again. Then I realized my wireframes looked sloppy, and more importantly, didn’t meet Apple’s Human Interface Guidelines.

Yes, just like cars and trucks have to meet certain size regulations (thanks Federal Highway Administration!) so do mobile operating systems (thanks Apple!). This was the key reason to go back to the Sketch drawing board and make wireframes that a developer could work with.

The saying goes, “developers are lazy.” In fact, they say it themselves. But this is just a cute simplification. More accurately, developers don’t want to do the work of designers. Our class paired us with a professional developer. But before I would go and meet with a professional for an hours estimate, I had to have my wireframes in a decent place. This involved knowing my features, each of my buttons, controls, and an awareness of edge cases, the particular instances where the user doesn’t know what to do.

A rough guide to help a developer get there bearings: Redlining
A rough guide to help a developer get there bearings: Redlining (or in this case, Ally purple)

Designer Meets Developer

I met with Mark Phillip, CEO & Founder of Are You Watching This?! and a very experienced developer. Meeting with Mark was the impetus for creating the guide above, which will help give a developer basic parameters to begin coding.

I showed Mark all of my wireframes grouped in flows. Each flow is a particular task, such as checking the details of an expense. Check out the flow below as an example:

07_User wants to view expense detail and call merchant
Example Flow: User wants to view expense detail and call merchant

Meeting with Mark provided a few key insights:

  • Give a big picture view of the app you want made, perhaps a concept map of the whole system
  • Use iOS standards and guidelines (and Android when needed); particularly built-in functions like date pickers which Apple has already developed
  • Keep tasks on one screen (with pop-up buttons); it can flow better, and it’s cheaper
  • Common customization features can be time-suckers
  • Extensive “redlining” is not necessary, just have visuals, and know what happens when the user takes an action

The flow below is an appropriate example of not making a developer’s life easier. Here, our user wants to send money to an existing contact. But the time-consuming development factor was surprising to me. Allowing the user to select any possible day at any reoccurring frequency is a developer’s nightmare.  The finicky nature of our Georgian calendar causes developers to have nightmares. I plan to reduce the user’s options’ for reoccurring transfers to three particular instances: one time (now); weekly, and monthly.

User-wants-to-send-money-to-an-existing-contact-pt-1
User-wants-to-send-money-to-an-existing-contact-pt-1

 

User wants to send money to an existing contact, pt 3
User wants to send money to an existing contact, pt 3

Cost & Conclusion

Mark was extremely gracious with his time and advice. Based on his estimates to do front-end development; he estimated my 14 flows would take just over 339 total hours, or roughly, 21 days for two developers, or 42 days for a single developer.

Based on a freelance developer hourly rate between $120 – $300/hr; the app would take between $40,000 – $101,000 to build. And that does not account for back-end development (the systems to retrieve all your money data) nor would that include the very extensive task of app management.

With an audience of over six million customers, Ally Bank is most likely hiring a full-time team or employing an internal team of developers to keep this online-only bank functioning.

As for myself, after this assignment I’ll be better prepared in two instances: moving from paper to digital wireframes, and having the visuals for all edge cases before meeting with a developer.

View a comprehensive view of my full flows, hours and cost breakdown here.  

 

Why We Need Help Helping

The internet is a mess. Empathy is commoditized. And awareness of systemic change hasn’t changed our systems.

In our readings for Quarter 4 Theory class, we’ve discussed the above topics, and we are closer to articulating how design can impact our world for the better. Part of that realization is knowing our limits as designers, but also as humans, primates, with limited cognitive capacity.

This friendly Brit can help us understand these limits.

screen-shot-2018-09-24-at-15-18-00
Dr. Robin Dunbar. Professor Emeritus of Evolutionary Psychology at Oxford. He recommends your wedding be less than 150 guests.

One limit is 150. Give or take. 150 is the cognitive limit on the number of individuals we can have a relationship with at a given moment. This is the key limit proposed by Dr. Robin Dunbar, who is one of the few academics famous for an inexact number, Your actual number may be 123, or 205, but whatever the exact amount, these are the folks you’d choose invite to a big party.

The number has historical weight- this 150-ish range correlates with the size of Neolithic villages (6500 BC); the size of a modern Army company, and the typical size of a department within a large organization.

The Dunbar number is actually 3-4 tiers of numbers, starting with your closest friends and family (averaging 5 people) and moving outward. As you move outward into an “extended network” of people (acquaintances); numbers of people increase. In the outer circles, these are people you’d recognize, perhaps even forget some names, but generally have a sense of who they are, and their relationship with you.

401 Assignment 1_v03.001
The 4 overlapping regions of Dunbar’s number.

Dunbar notes that we spend nearly 75% of our time with our nearest two circles of people. Compare that 20 or so people closest to you with the fact that there are 7.5 billion people alive on planet Earth, and our warm feelings of humanity can feel pretty insignificant in the big picture.

Hence the problems with empathy, giving, and charity. Our brains and society lack the capacity to have meaningful relationship about all the underprivileged, poverty-stricken, or under-educated people in the world. As much as we’d like to help, the numbers don’t just feel daunting, they are.

As designers, what Dunbar shows us is that we should utilize these limitations to push for systemic change in wicked problems. It shows us how we’re paralyzed by huge numbers and crave tangible, visual, human stories, which are often used in design research.

I don’t yet know how these limits can lead to the design of services that promote systemic change, but it does show why systemic change feels so elusive.

Impending Doom & The Future of Design

Yuval Noah Harari
Yuval Noah Harari, author of Homo Deus: A Brief History of Tomorrow.

 

I would like to tell you about a book I’ve just finished. It’s one of the finest books I have ever read.

Reading this book also bolstered the belief that I’m in no position to make the previous claim. I’m a human, a fledgling designer, and a biological creature. Which makes me a product of evolution, prone to cognitive dissonance, and recency bias.

The implications of these faulty human traits become clear in Yuval Noah Harari’s Homo Deus: A Brief History of Tomorrow. But more than proving we’re faulty creatures, Harari’s thesis should resonate with anyone who has a stake in design.

Humans, Just Another Animal? 

Harari is a historian, a realist, and most likely, atheist or agnostic. He contends that humans have dominated the planet due to our creation of fictions.

Our fictions are the fuel that propels our dominance on the planet. These stories define our uniqueness within the animal kingdom: the ability to organize in groups far above 100. The utility of money is a tangible example of a shared global fiction. A $100 bill is a piece of paper, but we all agree on the fiction that it has value.

Harari details how our ability to organize under shared fictions has led to the Anthropocene, the current age where human activity is the dominant force on the Earth’s environment. But it’s not only the Earth we’re changing.

We’re beginning to modify our genetic code, we’ve extended our lifespans, and we can ingest mood-lightening pills to ease our worries. Harari writes that as we reshape our biology with greater precision, it’s the old and new fictions that will guide what we create.

Huxley, Orwell, and Atwood all warn us through their literature that as we gain greater biological control over ourselves, we’ll lose our humanness. But maybe those warnings aren’t predictions just yet. Today, mitigating depression with an accurate dosage of chemicals has made life livable for many people. The trouble, Harari writes, is that our scientific developments in the life sciences (biology, behavioral economics, cognitive psychology) are quickly eroding the dominant shared narrative most of us live by.

You’re a Humanist, Like It or Not 

The dominating narrative of our age is humanism. Most of us have grown up with a feeling that “I am a unique individual with a clear inner voice that provides meaning to the universe.” Humanism sanctifies life, happiness, and the power of Homo Sapiens. It’s a story that says, “It’s up to me to choose what is right, what is art, what ice cream is best.” It also says “It’s up to you to choose the same for yourself.”

“Feelings” can have a very touchy-feely connotation, but it’s also humanism that fuels capitalism, choice, and our sense of freedom. It’s what legitimizes voting, and urges us to seek more equitable justice.

And it’s here that Harari’s warnings begin:

The humanist belief in feelings has enabled us to benefit from the fruits of the modern covenant without paying its price. […] What, then, will happen once we realize that customers and voters never make free choices, and once we have the technology to calculate, design, or outsmart their feelings? If the whole universe is pegged to the human experience, what will happen once the human experience becomes just another designable product, no different in essence from any other item in the supermarket?

We’re Walking, Justifying, Narrative Machines

If you’ve ever concluded that humans are irrational and fickle, you’ll not find much argument from Harari. What sets his writing apart is how he synthesizes scientific developments in light of our ancient human fictions.

A few of the unsettling scientific developments in irrationality:

  • fMRI scanners have proven your brain makes decisions before you’re aware you’ve made them
  • Split brain experiments have shown that humans are experts in cognitive dissonance, sliding into rational explanations even under bewildering circumstances
  • Behavioral economics has shown humans “narrative self” consistently overpowers our “experiencing self,” which turns the irrational, unpredictable choices we make into the illusion of a coherent, individual story (referred to as “System 2” in Daniel Kahneman’s terminology)
Daniel Kahneman receiving the Presidential Medal of Freedom. Many of his experiments led to the conclusion that we have a "narrating self" that makes justifications inconsistent with our "experiencing self"
Daniel Kahneman receiving the Presidential Medal of Freedom. Many of his experiments led to the conclusion that we have a “narrating self” that makes justifications inconsistent with our “experiencing self”

Dear Algorithm, Tell Us What To Design

Most of us don’t design by religious guidelines or by a dictator’s demands, we design for an environment where individuals are free to choose: my barstool or Ikea’s, your app or Apple’s. We believe in choice, and we design knowing there is a choice on the user’s end (most of the time).

Harari foresees a conflict here. On one side, the humanistic legacy and individual choice. On the other, the developments of science and technology, along with the rise of algorithms which increasingly make choices for us. Harari writes: 

Humans are relinquishing authority to the free market, to crowd wisdom and to external algorithms partly because we cannot deal with the deluge of data. In the past, censorship worked by blocking the flow of information. In the twenty-first century censorship works by flooding people with irrelevant information. […] Today having power means knowing what to ignore. So considering everything happening in our chaotic world, what should we focus on?

This leads me to imagine a loop that will impact designers at a high level:

  • We’ll continue to design based on witnessed human behavior, but will have to fight louder for a voice among the screams for large quantitative data
  • Big data collection and the algorithms will increasingly affect what gets made
  • What gets made = what gets used
  • We’ll increasingly study human behavior that’s created or influenced by algorithms

Pessimistic enough? I suppose Harari brought it out of me. But his book isn’t simply pessimistic. It’s an exercise in reflection and an attempt at broad foresight. More optimistically, it helped me gain a sense of the big picture of creating things for fellow humans.

Are we in danger of designing for “data fiends” who may trust algorithms over individual feelings? In reaction maybe we’ll design for the opposite, an “intentional ignorance,” or peace of mind that purposely avoids the prescriptiveness of data. Perhaps the data will show us more clearly our cognitive dissonance and we’ll act differently, more efficiently, or even more ethically.

Whatever we’re called to design, we should recognize the fictions we’ve been operating on, and act on the the stories we want told in the future.

Banking Not Budgeting: The Perils of Adding Features

Background

Designing Digital Interfaces at AC4D is a mixture of visual design education, user testing, and like many of our courses, an exercise in asking “Why?”

We’ve been tasked with redesigning a banking app of our choice. My choice is Ally Bank, an online-only institution. We redesign by creating wireframes- draft versions (either paper or digital) that can be quickly modified and tested.

Four weeks ago I began to tweak existing features such as checking balances and depositing checks. Over the last two weeks our cohort have been tackling something much bigger: adding budgeting functionality to our banking apps.

My process began with drafting a “Process Flow Diagram.” Essentially, it’s a visualization of how budget functions would fit into existing functions, from the user’s perspective. A process flow details all the choices a user would make when they view a screen, in this case, a mobile app.

 

A Process Flow Diagram
A Process Flow Diagram

After completing a a process flow, I created wireframes of screens that included the new budgeting functionality. And I began to form “missions” for users in order to test the viability and usefulness of Ally’s new budgeting functions.

Here were the “missions” I gave my users, and the reasons why in bold.

Assignment 4_Financial Modeling.010

Why Are We Doing This?

In full awareness of putting the cart before the horse, these reflections came after my user testing. This assignment gave me the opportunity to:

  1. Expand my research capabilities as designers by user testing
  2. Apply a system-wide awareness (using process flows and system maps) into instituting a new app function
  3. Gain greater empathy for users in using a new function
  4. Gain greater empathy for my imaginary coworkers at Ally Bank, whose work could be affected by adding the new functions

Banking Not Budgeting 

I tested five users, all non-Ally customers. Zero of my five users used their bank for budgeting. None. It didn’t matter whether they used their banking app daily, or only used their bank’s mobile site twice a month.

A snapshot of my five users.
A snapshot of my five users.

This leads us to the reason why aggregative budgeting apps exist. The most popular being Mint or YNAB (You Need a Budget). These two apps can do something that single-bank applications cannot: pull in data from two or more financial institutions, budget all expenses in one place, and set goals that relate to a user’s complete financial state.

This led me to a difficult realization: either I imagine that Ally can have the capability of collecting info from different institutions (a la Mint or YNAB); or I operate in the complete opposite sphere, where Ally only tracks Ally expenses and transactions. I opted for the former, which I would come to regret.

“‘Current Flexible Cash’ What the heck is that?”

…stated one user. Current Flexible Cash was my idea to give users a “safe to spend” amount, a subset of their checking account. The idea was for users to know how much cash they have on hand that’s available to make urgent cash purchases.

Here’s how it was introduced. Users saw this designation on their first screen, “Snapshot.” Stuck in the middle of the screen, users communicated it seemed unimportant, and the graph, “confusing.” As they continued their missions, they saw that “Current Flexible Cash” was connected to both “Budget Categories.” Any money that wasn’t budgeted, or in Savings was considered “Flexible”.

Users saw "Current Flexible Cash" on their first screen. Then confusion ensued.
Users saw “Current Flexible Cash” on their first screen. Then confusion ensued.

I attempted to introduce this “Flexible Cash” concept in a tutorial, which popped up when users clicked the middle button of the Snapshot screen:

The brief tutorial on "Current Flexible Cash"
The brief tutorial on “Current Flexible Cash”

From my users’ near unanimous feedback, budgeting is not the expected functioning of a banking app. If introduced, it must not conflict or even interrupt the more common banking tasks. I still have hope that users can find value, but the structure, and especially placement of budgeting functions needs to improve. Perhaps “budgeting” should be its own tab.

User Conclusions

All of this confusion resulted in my major takeaway from these tests: in the way I presented budgeting with Ally, users found no immediate value added. For them, the primary goal of a banking app was to check recent activity was accurately documented. Or to recognize inaccurate or fraudulent transactions.

Big Questions & Next Steps

Moving forward, I plan to operate on the reverse assumption of this user test: Ally will not have data from user’s other institutions, and therefore should create budgeting functions that don’t rely on external data, but still provide value to the user.

Ally could theoretically have Mint or YNAB functionality, but why should it? How do we create value with these functions when most use banking apps simply as  an official ledger, checking to making sure all is well.

These are the questions I’ll keep in mind when moving forward in doing a Heuristic Evaluation and Cognitive Walkthrough with users.

The questions I will keep in mind moving forward in the Ally functionality process
The questions I will keep in mind moving forward in the Ally functionality process