Wells Fargo Redesign – Product Strategy & Feature Brief

How do you sell features? You don’t. You sell vision and value.

I started the development of my Wells Fargo redesign six months ago. During that time, I created many screens and flows that correlate to tasks. At this point however, it’s time to communicate this work to the c-suite at the company where I developed this redesign. These past two weeks, we created a product strategy and feature brief about our mobile banking app’s development to do just that. Though it’s called a feature brief, I needed to use this document to communicate the vision and value these features will bring, not only to the company, but to the user.

Strategy brief Cover

In this assignment, I created a deck that could be used to brief executives or investors about the rationale and strategy regarding my app’s development. You can view the full PDF deck here. It was a great lesson in how to communicate and sell our work to people who aren’t our fellow designers or developers. In the next phase of our education, out in the “real world”, selling our work will be a critical skill to learn.


Research, Insights, & Value Proposition

The driving force behind communicating the rationale for the work is in the research. For this project, we made up our research because it was outside of the scope of our skill development. We’ve learned to do research for many other projects, including both primary, contextual inquiry and secondary research including market and trends analysis. What research did I come up with?

Currently, “millennials are moving away from home at an astounding rate”! This was the crux of my story. I reasoned that because millennials are moving away, they now need to pay bills, and the financial management apps they currently use, like Venmo, are inadequate to manage the recurring payments and other financial needs they’re encountering.

Enter Wells Fargo. The introduction of so many millennials into the banking market is Wells Fargo’s opportunity, I claimed, to develop features that would welcome this new group of users and convince them to use Wells Fargo’s services.

Overview of strategy brief
The overview provides the framing for the background and purpose of the development effort.

A key part of design research is not only this high level secondary research but also primary research through interviews with individuals. Design research often culminates with developing behavioral insights about users to drive the design of their products. In this case, Wells Fargo’s design research is evidenced in four key insights. Each of my Insight pages explains how research informed the insight, a sample quotation and image of a user, and how this insight will inform product development.

strategy brief-03 Insight Insight Insight

As a result of the insights, we can now define how our product will be valuable for users. This definition of value is clarified through a value proposition, which really is just business jargon for a statement about how a product is valuable for users. My value proposition for Wells Fargo’s redesign is as follows:

Value propositionStrategic Roadmap

Now that we have a sense for our direction, we need to define how we’ll get there. Leading up to this point, I created features that allow users to complete tasks that are necessary and valuable to them in the context of banking via a mobile app. I have everything from viewing an account balance and depositing a check to managing alerts covered in my app’s design. These all are valuable for the app, but how will they be completed?

Two weeks ago, I completed what’s called a product roadmap. This document is the outline we need to demonstrate how to prioritize and sequence all these features’ development. You can read more about the roadmap in this post. In this strategy brief, I need to zoom out, however, and describe more of the rationale of the development from the perspective of adding value for users. It’s not as valuable for an organization to sequence their app’s development for purely technical reasons. How will the product gain traction in the marketplace? If we can create a useful, valuable product and then continue to create releases that build on that value subsequently, we can capture more value sooner.

Strategic Roadmap
The overall roadmap shows both the categories of development and where they lie in the year and across the release points.



Strategic Roadmap
Additional pages in the deck describe the production streams’ goals and development content.


With an eye to providing value to users as soon as possible in the course of the product’s development, I developed a roadmap strategy that sequences feature development based on the insights and value promise I initially created. By releasing “Quick Access” features, for example, we can help millennials develop affinity for the app early, since we know that these users want instant gratification and instant access to information. Once they have begun using the app more, we will develop the “Create Savings” features so they can begin to address their emerging need for frugality. Later, these users will be using the app and will have savings goals and budgets, and we will release the “Alerts” features in time to help them keep on top of their goals and new financial commitments.

Capability Overviews

Now that the executive or investor reading this deck has an understanding for the high level rationale for the product’s development, it’s time to provide a glimpse of the features that will help us create value for users. Features, which I am calling capabilities in this deck, are really just tactics. They are not valuable in their own right. This is why we should not attempt to sell features. What is valuable for users is not whether they can look at a screen with good looking graphs but rather that they can quickly develop an understanding of their financial standing. The graphs help support that goal.


Sample Feature overview page
Sample Feature overview page

For each feature, I provide just a snapshot of the screen. Again, executives do not need to know how users will step through completing a task – they need to understand how it provides value to users. (Unless of course an executive prefers that level of detail, which is another story.) A picture of the feature here provides a visualization to ground understanding of the task itself. The description that accompanies it provides additional narrative of how the feature value.

In Closing

As designers, we need to both gain a sense for users’ needs and wants and design products that help to fulfill them. Someone needs to know how to communicate the vision for the product in order to fund it. That someone could be the CEO, a product manager, or any number of people. I want to be able to be that person as needed. This project was instrumental in wrapping up the banking app redesign as it cast everything in perspective. The product needs to add value for a user, which should be evidenced by research. The devil is in the details of course, and key features will be necessary to create that value. This product strategy overview and feature brief distills those required elements for a successful product into one document, and it’s a good template to have as we go into the world and create truly great, valuable products for people.

Housing Assist Update

In the last blog post update, I mentioned that I am developing the details of the Housing Assist online application. The big task was to create the initial intake in its entirety. By last week, I had an outline of the initial intake, and in this past week I developed and did usability testing of the screens. In this blog post, I’ll go into the details and give a glimpse of what I’ve created.


The initial intake is the most important part of the application for residents applying for housing repair assistance. The Housing Assist initial intake gives residents quickly tests’ residents’ eligibility for a wide variety of programs. To make the intake, I needed to analyze and synthesize all the possible applications residents could fill out. I developed this analysis with help from experts such as John Lyons, the Program Manager at Meals on Wheels, the largest housing repair provider in Central Texas.

I then developed a logical workflow diagram that illustrated the shortest possible paths for residents to take through the initial intake. Based on those questions, the logic directs residents to answer more or fewer questions, and, based on their responses, residents finish the 20-30 minute intake with a clear indication of their eligibility for any program available in the region.


This week I created wireframes for the whole intake.

Housing Assist Landing Page
The Housing Assist landing page is where users start their application.


Basic info wireframe
This sample screen illustrates the conversational and minimalist design of the wireframes. These design principles allow for older residents to more easily navigate the application independent of intake specialists. This screen shows all questions, however a user would only see questions such as mailing address fields if they click yes. This conditional logic is applied throughout the online application.

Usability Testing

After creating wireframes, I then did usability testing with five individuals. The usability testing method I followed is called the think-aloud protocol. I gave testers the task of completing the application starting from the landing page. I did not prompt them at all as to what to do on each screen. As they made their way through the online application and filled it out, they spoke their thoughts aloud so I could better learn what they noticed on each page and how they were confused or making decisions about what to “click” or fill out.

Usability testing
I completed usability testing with five individuals. Standard research has shown that 5 individuals is the optimal number to test before testing reveals too few remaining errors to be worthwhile.

The usability testing took about 15-45 minutes. The wide range of participants’ technology savvy correlated with the length of time it took for them to complete the application. Since many housing repair assistance applicants are older than sixty years old, and since technology use drops off for elderly users according to Pew research, and according to my own primary research in Austin, Housing Assist will be marketed to residents and also to their caregivers and children. With this in mind, I conducted usability testing with a seventy-nine-year-old who never uses computers and also with four individuals ranging from thirty to forty years old. Two of these younger individuals were professional housing repair application intake specialists. In addition to gaining normal usability insights, the specialists’ review of the prototype helped me identify errors or omissions in the form that would lead to inaccurately calculating residents’ eligibility.

Usability testing with elderly woman.
One usability tester was a seventy-nine-year-old woman who does not use computers. This proved extremely useful. If I can revise the application so that even she could use it, it would be usable by most anyone. In addition, her testing will help me revise language or question order so that if someone else were to help her complete the application, it will still be sensitive to her interpretation of the applications’ questions and format.

The past week was significant to advance the Housing Assist concept. The usability testing revealed many errors ranging from language use unfamiliar to users to text that was too small for some people to read. I also learned how to better orient users to the purpose of the application as well as to help them understand their orientation and progress within the application.

What’s Next

There’s less than two weeks until the final presentation, and this week I will be focusing on refining the wireframes and other assets to be better prepared for assembling the presentation deck. I plan to have a draft of that deck ready for next week’s blog post as well as refined wireframes, so stay tuned for the next Housing Assist blog update!

What limits can we Imagine? It depends on how you think about it.


What limits what we can imagine?

Imagination is essential for design. The very heart of design thinking lies in our ability to think divergently and move beyond the boundaries of the given set of assumptions to allow our work to be informed by the unimagined. As designers, our ability to solve a problem or create the outcomes we seek is defined by what we see and what we can imagine. More foundationally, the way we see things and imagine the world is shaped by personal experience, our relationships, and the institutions, cultural, and commercial forces around us. To better depict these ideas, I created an allegory that illustrates these forces. Read on, and I’ll continue my explanation after the short ,illustrated story.



Review of the Narrative

What happens in this story? How does it represent imagination and design?

In the story of Divia the Explorer, there are two main characters – Anali and Divia. These birds represent two forces that thinkers like Roger Martin describe as analytical or non-integrative thinking (Anali) and design or integrative thinking (Divia.) Analytical thinking is characterized as limiting variables and constraining the bounds of a system to better analyse it’s causal relationships and often quantitatively optimize outcomes. On the other hand, design thinking is characterized by widening possibilities of the scope of system, allowing for multiple causes to define any given outcome, and evaluating qualitative features in defining outcomes that are not easily or at all quantifiable. The characters of Anali and Divia continue to represent these approaches to problem-solving throughout the story.

In the article entitled “Incremental and Radical Innovation: Design Research versus Technology & Meaning Change”, Don Norman and Roberto Verganti look at, among other topics, two types  of ways that technology changes. Through incremental innovation, products or systems are improved bit by bit, and in cases of radical innovation, they are changed so much so that there is a paradigm shift with regards to the definition and meaning of the product or system. These types of changes occur in the story of Divia the Explorer.

In the beginning of the story, Anali makes an observation of plants and finds a relationship between them. He essentially creates a radical innovation in the flocks’ food sourcing by inventing farming as opposed to relying on foraging. The birds’ normal course of action is changed by this invention. What happens next is how his analytical research creates a frame around their way of life that transforms it entirely. Instead of continuing to migrate, they stay put and harness nature as a thing to be controlled. The system is well defined in order to control the variables, and Anali, year after year, optimizes the crop’s output by incrementally improving the crop’s efficiency through small innovations.

Over time, this tightly constrained system saps the birds of their color. I believe this is what happens when we shutter ourselves from a wider world view and way of life that embraces the new. One day, Divia has a dream of exotic fruits. Inspired by this dream, she leaves home to find them, even without permission. This way of life represents the divergent thinking characteristic of design thinking. She seeks something new and unfamiliar. Why does she want to go? She just does. In reading about inventors, artists, and other visionary thinkers, their reasoning isn’t constrained to explanations that have to fit the logical frame of the current way of thinking. They often pursue their visions because of an inborn tendency. To explain the reasoning would rely on sign-posts of logic that are shared by others. For there to be shared sign-posts, the rationale would necessarily need to be common, and the creative is by definition uncommon and beyond the current way of thinking.

Anali has influenced others, such as Divia’s mother, and Divia’s mother warns her daughter of the dangers. This risk-averse thinking is typical of an analytical thinking that cares more for controlling variables than opening to possibilities beyond the envisioned worldview.

When Divia gets back to the flock, they have lost even more of their color, but once the drained birds have tasted the new fruit that Divia has brought back, they are inspired are reinvigorated. I believe this invigoration is what methods like divergent thinking bring to institutions or systems normalized with traditional paths and worldviews. Defamiliarization is another method that can reinvigorate thinking. This method, as described by Genevieve Bell, Mark Blythe, and Phoebe Sengers in their work, involves encountering unfamiliar contexts or things in order to stretch the mind. For example, in order to invent new forms or meanings for home goods, we could look back at home life in the 19th century – a realm most people are unfamiliar with. As a result, we may see objects, domestic relationships, and home life in such peculiar forms that they stretch our imagination of how we might invent new items for the home. Divia introduces the unfamiliar to the flock, and it changes their way of life as well. Anali does continue employing his strengths in farming and optimizing their efforts, but now they have adapted their way of life by incorporating Divia’s expeditions as a way to bring in new fruits for their farms.

In Closing

What are the limits of our imagination? Analytical thinking does not limit our imagination. Following a single, rigid way of thinking is what limits our imagination. Converse to analytical thinking, if we only thought divergently, our thoughts would diffuse and dissociate, lacking vigor or ability to concretize pattern or sense-making. It’s the flexible analytical and divergent thinking that creates imagination. In this way, Divia and Anali are not necessarily at odds. We should not put design thinking on a pedestal and belittle analytical thinking. Just as Divia and Anali find a way to make the most of their preferred ways of thinking and work, people in the world of humans must better work together. Whether it’s in the world of business and design or in healthcare with the battling traditional and holistic healthcare providers, we will all be better off respecting and complimenting our strengths and their place to make positive change.

Update for Housing Assist

Last week’s focus for Housing Assist was focused on developing the high level vision for the project. You can read more about that work  in this blog post. This week, I shifted gears and worked on mapping out what to prioritize in the last few weeks and also started on the biggest task remaining – creating all the screens for the first stage for of the online application, the initial intake.


What’s left

Given the full system for housing assist could consist of more than 1,000 wireframes, one question I wrestled with this past week was how many of them to develop with only three weeks left and one person to do the work.

My goal is to both illustrate the application concept in the big picture and also test the online application’s design paradigms through in-depth usability testing. To that end, I plan to illustrate the process broadly by creating wireframes from select points throughout the application. Those vignettes will include illustrations of wireframes from the Initial Intake, Detailed Intake, Document Collection and Certification stages.

Housing Assist Screens to Create
A broad selection of screens will illustrate the overall Housing Assist process concept, and the full variety of screens for just the first stage will allow for effective usability testing of design paradigms

To validate and revise the design concepts such as wireframe layout, information architecture, interactions, language choice, and conversational paradigms, I will create every wireframe necessary for the Initial Intake stage of the application. I will use those wireframes to complete usability testing over the next three weeks.

Initial Intake

To create the Initial Intake wireframes, I first chose to map it out in-depth. Fortunately, I had done a good deal of the work when analyzing the housing repair program applications.

Analysis of all housing repair applications
An analysis of all housing repair applications helped identify overlaps and distinctions between them.

One of the key design principles guiding the Initial Intake development is to require as little information input as necessary from the applicant in order to encourage completion of the form. If the applicant doesn’t know information off-hand while completing the form, it becomes more likely that he or she will need to stop and will not continue or complete the form. In order to determine which questions influenced the likelihood of a person’s eligibility the most,  I reviewed my application data with John Lyons, a Housing Repair Program Manager at Meals on Wheels. I then developed an Initial Intake with only a fraction of the required questions of the original forms.

Initial Intake Spreadsheet
I used a spreadsheet to track how each initial intake question mapped to different program eligibility requirements.

To cut down the number of questions further, I designed workflows that will automatically pull information from existing data sets such as the Travis County Assessor’s District and from the Austin Housing Repair Coalition’s list of previously served clients. I have been assured that both of these data sets are existing and would be simple enough to keep updated.

You can see examples of the workflow diagram below. Data in red boxes are required of the applicant.

Full Initial Intake
The full initial intake logical workflow.


Household member information
A sample of questions from the full intake logical workflow. For each household member in addition to the applicant, key information is necessary to collect

Next Steps

Now that the list of questions and their logical flow is complete, we will be able to begin creating all the wireframes to represent them in the application. After that’s set, I will begin usability testing early next week with individuals through Meals on Wheels programs.

Stay tuned for test results and wireframe updates next week!

The roadmap is not the territory… but it sure is helpful.

When you estimate that it will take the better part of a year and most likely hundreds of thousands of dollars to develop an app, where do you even start to break ground?

In the fall, I redesigned the Wells Fargo app with rapid prototyping and ideation. This quarter, we picked our bank app redesign projects back up and began planning how we would get them developed. The first project was to estimate the scope of the project. I blogged about that experience in this post. Now, the task is to take that estimate and turn it into a plan.

The word people use in industry for a product development plan is a roadmap. It lays out the scope and sequence of a products’ parts that engineers will develop as they bit by bit make the vision a reality.

How do you create that plan? That was our task.

Our only real constraint in creating the plan was that we had two developers working full-time, forty-hours per week. Other than that, our main task was to identify some rationale for sequencing parts of the product in a particular order.

The Thin Slice

Though we planned to develop the app piece by piece over time, as is the case with all software, we needed to plan for our releases. Each release is a new version of the product that internal or external customers will have access to use. That being said, each release should be composed to be valuable in its own right.

One of the primary releases to consider is called the “thin slice”. This is a version of the product that is literally a slice of what the full release would look and feel like. Sometimes called the “minimum viable product” (also called an MVP), a thin slice of a software application is a version that embodies the essence and value of the full version with the least production cost. I will be using the terms MVP and thin slice interchangeably throughout this post.

By defining and creating a thin slice, it allows a company to aim for delivery of a product version that customers will enjoy as fast and cheaply as possible. By getting the product to customers fast, product managers can assess if the value proposition they projected holds true or if their take on the solution resonates with their target market. If a company invested all its funds in the full release without aiming for a minimum viable product, they could easily find their money wasted if they were even a fraction off the mark. Creating quick releases instead gives companies time to redirect efforts or even double down on positive market reactions.

Defining the Wells Fargo Thin Slice


Though we didn’t have a time constraint required, I decided to aim for an MVP release about halfway through the full release development. Since we estimated the development to take about seven to eight months, I decided to fit in about three to four months of development before releasing the thin slice.

To define what fit into this three to four month development window, I first reviewed the estimate I developed with a consulting developer two weeks ago.

Wells Fargo Redesign Estimate
An estimate of features and task flows in the Wells Fargo redesign estimate.

From this list, I had about forty different components to develop

Which should I roll into the thin slice release? Which components or flows should I roll into subsequent releases?

To prioritize items, I relied on a few organizing principles. First, some simple features are just logistically and technically required for a banking app to be valuable to a user. No one will be able to use a banking application that won’t let them sign in – an app needs authentication. It needs navigation. It needs the basics. All those items get first dibs on the MVP.

Next, prioritize table stakes items like account summary, transaction review, and bill pay, transfer money, and mobile check deposit. These days, those capabilities are the least a customer will expect from a banking app.

Beyond the basics and the table stakes items, I felt it was necessary to incorporate some features that could differentiate the Wells Fargo app and create a superior value for customers. Three features that I decided to roll into the thin slice included Card-Free ATM, Fastlook, and my Favorites feature.

Each of these features provided convenience in novel ways. When I mentioned them to others, many people had never heard of these features but thought they were “cool”. The “cool” factor is gold in the world of product, and I took that cue to include these features in the thin slice.

With these principles in mind, I went through the list of features and flows to develop and indicated priorities regarding what made it into the MVP or not. Then I scanned the spreadsheet and assigned a sequence to the items within the MVP and after the MVP. I reviewed the sequence to be sure it made sense from both a technical standpoint (would feature b even work if feature a weren’t developed yet?) and a value standpoint (would customers really prefer feature d over feature c?)

Spreadsheet indicating features and components from the initial estimate prioritized for roadmap sequencing.
Spreadsheet indicating features and components from the initial estimate prioritized for roadmap sequencing.

I cut out a number of features from the original flows, including Make a Spending Scenario flow and Balance Alerts. Many of the features I did not include were in the original scope but I have not yet created wireframes for them. I therefore didn’t need to cut these out in my “rough cut”, but I did need to modify the menus to exclude them.


Picture of flows from app redesign
I cut two of the flows from the MVP – Make a Spending Scenario and Make a Balance Alert. They were not instrumental to add value for users.


Picture of menus from app.
I cut several features from the MVP that don’t have wireframes yet. I did have to cut them from the menus though.

Once I was satisfied with the feature sequencing, I moved these items into a road map.


The spreadsheet could have been enough for some people, but it’s a pretty terrible visualization tool. Roadmaps are meant to communicate and refine project plans, guide teams, and persuade investors or others of the soundness of your plans. The majority of communication is visual. According to landmark studies by Dr. Albert Mehrabian often referenced in communication studies and in discussions about presentation techniques, as much as 53% of communication is visual, and only 7% is verbal.

With this in mind, to create a roadmap, we visualize each component as a block with a length proportionate to the duration of time it takes for engineers to develop it, and we lay the components end-to-end for as long as it will take to develop all the components. In doing this exercise, we lay down the road that will lead us to a finished product.

For our exercise, we have two developers, so there are actually two lanes to our highway.

One decision I made in developing this sequencing was to assign certain components to each of the developers. Some component structures, like those in the Make a Bill Payment flow, are very similar to others, like the ones in the Transfer Money flow, so it makes sense for the same developer to work on both components. On the other hand, many of the features to develop are generic to many apps, like Authentication, Change User Name, Set-up Touch ID, and Change Password, while other features are very specific to banking. Assuming that one developer may be slightly (or much) more experienced in banking specific protocols and development, I assigned the developer labeled “Resource 2” with the majority of banking specific features.

Because the roadmap is so long, I needed to cut it into pieces for the purpose of including it in the post. I used natural breakpoints to cut it up. These breakpoints are the places where I planned releases. The first three releases are part of the MVP, and the last two are subsequent to the MVP. The figure directly below illustrates these parts.

Diagram of roadmap

Each release encapsulates a set of features that provide a set of viable functions. Release 1.0, for example, has the minimum necessary to be a useful banking app, including authentication, account summary, and transactions review.


Roadmap - Release 1.0
Roadmap – Release 1.0
Roadmap - Release 2.0
Roadmap – Release 2.0


Screen Shot 2018-04-02 at 10.40.47 PM
Roadmap – Release 3.0


Screen Shot 2018-04-02 at 10.43.23 PM
Roadmap – Release 4.0
Roadmap - Release 5.0
Roadmap – Release 5.0



Creating a roadmap has been exceptionally educational. One reason it was so beneficial for me was that it provided another opportunity to think visually and express project plans visually. I have spent plenty of time with just words and numbers in spreadsheets, and expressing those values spatially gave the same information much more meaning in the context of project planning.

Another lesson I learned is that it’s important to get detailed estimates. This was something I did not do. With only an hour to develop an estimate with the developer, I often only had broad strokes to work with. For example, the mobile check deposit would take “80 hours”. What if I want deliver just a slice of that feature in the MVP? I don’t know what any single part of it costs, so unless I consult a developer to get a more detailed estimate, I’m somewhat resigned to keeping it whole. That inflexibility puts unnecessary constraints on my project planning creativity.

We had a visitor come to our class last week named Jaidev Amrite. He’s an experienced product manager and gave us great insights into the world of product management. His number one tip – if you don’t become the product manager, be sure to make friends with him or her. Working through these exercises has made it loud and clear how critical and influential the product manager can be in an organization. Having learned more about the PM’s role, experience, concerns, and language, I can certainly appreciate why and how to be an ally to one.

Crafting a Vision of Housing Assist

Though there are almost a dozen service providers, one of the big challenges for homeowners is to actually apply for assistance. The variety of providers and the complex and demanding application forms can lead to residents giving up or getting less help than they are eligible for.

To better help residents,  I’m developing a concept for a streamlined, online application process that makes it easier and faster for residents to apply for all services for which they may be eligible.


This past week has been exciting as I worked to develop the vision for a long term solution. From sketching through digital creation, I worked to create a variety of media to better visualize and communicate the vision.

Service Blueprint

How does Housing Assist really work? A service blueprint is a diagram that illustrates how a service works. Though Housing Assist may seem like a product – that is, an online application software – the product is used over time and in concert with multiple parties. That process of use is more like a service than a static product. For this reason, a service blueprint helps clarify how the value is created that the product is intended to support across the ecosystem of users and service providers.

In the image below, you can read the service blueprint left to right, and every column is a phase or moment in time. The top row represents what the user, (read “resident”,) is doing. The “Front Stage” is that place where someone or something is visible and interacting with the resident. This could be a computer screen or a person. In this service blueprint, all Front Stage interactions represent the assisting service provider.

Backstage represents all those things people do “behind the scenes” to support the service, and supporting processes represent things like policies and automatic transactions that the service needs to support its functioning.


One of the first things I worked on was the service blueprint because it helps to create such a clear, big picture of what’s happening. You can see the initial sketch below it.


Storyboards also provide a clear picture of how the service works. The beauty of storyboards is that by making up a story about the product, we tune into our instincts for assessing its likelihood of working. We are the storyteller but also become the audience as we listen to the story we’re weaving. As we listen, we start to ask ourselves all sorts of questions about the story.

What happens next? How did that happen? Who told him about the service? Would he really react that way? Who is this “user” anyway?

Our human capacity and desire to understand causality comes to life when we tell stories, and it helps us take the temperature of their feasibility. Whenever there are gaps, to the extent our creativity is active, we will fill in the gaps and make a better, more seamless story.

Below is the latest iteration of the Housing Assist storyboard.

HA Storyboard v2

Customer Journey Map

Similar to a storyboard, a customer journey map tells the story of the “user” but in a more abstracted sense. It isn’t the story of Gary, as in the storyboard, but the average person who uses the service.

Housing Assist Customer Journey Map
Residents are supported through four discrete stages in order to front-load eligibility questions before getting into the more detailed, laborious documentation of need. Stages also provide a sense of completion and progress, motivating the resident to continue with the application.

In this diagram, you can see that I propose the resident becomes aware of Housing Assist through one of a variety of channels. Afterward, he or she will go through four stages to complete the housing repair application. By breaking it into stages and front-loading eligibility assessment for all programs and service providers, this ideal vision for Housing Assist saves residents and service providers time, and saved time means better use of resources.

One thing to note is the assignment of an assisting service provider. Though Housing Assist is meant to support and guide users through the application, I believe they would necessarily need a human to connect with for the challenging questions or simply because it provides assurance that the application will lead to a benefit. The assisting provider is determined by the eligibility profile of the resident and the provider’s capacity. If there’s a likelihood the resident will need services offered by a different provider from the assisting one, then a collaborating provider is informed. This will allow service providers to more efficiently and effectively coordinate their services with a resident.


What are wireframes anyway? The common term for pictures of an application is “wireframe”. In order to visualize the product, I developed wireframes for multiple points in the application journey. It was a long road to getting to that point, however.

I created scenarios that told a story about the use of the product.

Housing Assist Scenarios
Scenarios tell a story of how someone might expect to use a piece of software. These scenarios depict a resident applying for housing repairs using Housing Assist.

Afterward, I developed a diagram called an information architecture map to represent all the sections and features of the product that a resident could utilize in the course of using Housing Assist.

Next I sketched wireframes from key points along the way, and finally I rendered them in a digital format.

A sketch of the landing page of Housing Assist.
A sketch of the landing page of Housing Assist.


Housing Assist Wireframe
A sketch of a user utilizing the help function to look up where to find social security information.


A digital mock-up of what the Housing Assist landing page might look like.
A digital mock-up of what the Housing Assist landing page might look like.


Housing Assist wireframe
A digital mock-up of a Housing Assist question from the initial intake stage. The
uncluttered interface is meant to be accessible and the relaxed, assuring conversational style of questions is meant to be more inviting and usable than the typical application form.

Normally I would test how well user’s could understand the wireframes before bringing them to the fidelity seen below, but I needed just a couple at a high fidelity for this week to demonstrate Housing Assist in a presentation. I will be doing usability testing and refining the wireframes in the coming weeks.

Pitch Deck

The final item I made this week was a pitch deck. A pitch deck is a presentation slide deck meant for pitching an idea to investors. There are “presentation” pitch decks – meant for presenting of course – and there are “reading” pitch decks – meant to be read by individuals like a brochure. This Pitch Deck is a reading deck. It takes a common format.

  • Overview
  • Problem
  • Solution
  • How it works
  • Traction (which means proof that people want the solution devised)
  • Ask/Next Steps

Next Steps

As for next week, I will be shifting back to focus on the minimum viable product – the single application form I spoke of last week and in the deck.

MVP infographic
I analyzed six forms and weaved them into one. (Yet somehow I managed to weave only four of them into the current graphic.) This single application form will serve as a minimum viable product that Meals on Wheels will pilot as an intake form in the coming weeks.

Meals on Wheels has agreed to partner in piloting the form to do intake with prospective clients, and if the stars are aligned we will be able to fit in some testing this coming week. I look forward to testing and refining the form and will keep you all updated.

The Power of Design

Power without love is reckless and abusive, and love without power is sentimental and anemic. Power at its best is love implementing the demands of justice, and justice at its best is power correcting everything that stands against love.”

Martin Luther King Jr.

Love and power – they’re at the center of most everything we do. In the past two weeks, we read fifteen articles about the designer’s place in society and the power that they wield. This post is a reflection on these readings and the themes of power and design that they brought up.

Power and its Social Implications

According to George Aye, a lead designer at the Greater Good studio, “power is the ability to influence outcomes.” People have a real need to have power. Power gives individuals the ability to satisfy needs. In the most primitive sense, this can mean securing food and shelter to survive. Without power, we cannot “influence the outcome” of procuring food. We don’t only have a need to satisfy needs through power – power itself is a need. Humans have an inbuilt need for power, in part as means of assuring themselves that they can predictably influence the world around them to survive. This need for power, control, and predictability is at the heart of much what drives us in society.

The challenge is what happens when we exercise power. If we exert power on the environment, we shape it. We can make more predictable food sources through farming, using patterns and organisms in nature to create food systems that will sustain us. The fact is, however, we live in a social world, and our actions to influence the world through our power, both to satisfy our needs and to satisfy our need for power, will influence individuals. Oftentimes, then, our decisions are a mix of different individuals’ influences.

As a society, we are made up of individuals and collectives such as friend groups, families, organizations, companies, countries, and at the greatest level, we are connected by the common social contract – human beings. Each individual and collective does have shared needs, but in addition to being separate selves, because of our capitalistic, cultural, and political systems, we have developed unique properties and rights which means we have developed unique needs to satisfy.

What does this have to do with society?

When we wield our power, we must ask – “How does this power affect others, and how much am I willing to share my power to better allow for others to satisfy their needs as well?”

In society, our contracts and transactions become transactions of agreement in trading or sharing power. Are they fair?

We often give up power in order to gain something in return.

Power Transactions

In the case of Colonial Morocco, as Assia Lamzah covers in her article Urban Design and Architecture in the service of colonialism in Morocco, Moroccan residents lost to the French and had to give power up. In return, they were able to retain power because many traditional institutions retained power in government. In the case of labor agreements as covered by Pelle Ehnmerged in his book “Designing for Democracy at Work,” labor trades its power to the capitalist in return for wages. In the case of new home technologies such as automatic washers as covered by Tim Wu in his article “The Tyranny of Convenience,” or internet-connected home devices, as covered by Kashmir Hill in “The House that Spied on Me,” people traded hard-earned money for the convenience of these devices.

In each case, these trades ought to be equal, otherwise why would one agree to the bargain. We only rationally make a transaction when there is perceived trade in equal value – or when we believe we are getting an even better value than what we give up.

The challenge is that this trade is almost never fair.

In Morocco, the French colonialists secretly were ruling not only the protectorate as a whole but also the traditional institutions that most Moroccans believed were still under native control. In the case of capitalist labor transactions, the very nature of capitalism is to accrue greater value for owners, meaning that it is certainly not shared equally with labor. And in the case of technologies that provide such amazing conveniences, the trade is not equal either.

Power is about the ability to shape and control things. What happens when we use these technologies? One thing is that we purchase them for their convenience value. They do the work for us, and when they do the work for us, we actually lose our opportunity to develop the skill of completing that work. Another thing that happens with technologies is that they are often so complex that ordinary individuals don’t have the ability to shape or control them anyhow. The Smart home devices in Ms. Hill’s article constantly are sending data picked up in the home back to their home companies. In fact, the devices are legally still owned in part by the companies that sell them. So much for control. People have given up their ability to modify them in many ways in return for their technical sophistication, and they have given up their opportunity to do grow in the skill the technology is performing in return for convenience.

In all these transactions, there is an opportunity for more just transactions and fair sharing of power of the seller and buyer, employer and laborer, and government and its people. Where does the designer stand in all this?

Design and Power

According to Richard Buchanan, “design is the human power of conceiving, planning, and bringing to reality all of the products that serve human beings in the accomplishment of their individual and collective purposes.” That sounds a lot like design is equivalent to power.

Why do companies hire designers? They do so because they require designers’ capacities to shape things, like products and even behavior in the case of interaction design, in order to influence the company’s greater outcomes, like profit.

Designers sit at a critical place in society. They are trained to make things and devise plans to influence outcomes, and as such they are valuable in shaping how power is balanced in fulfilling different people’s needs through the products and services they design.

Our Next Steps as Designers

How will we as designers use this power? Will we use it to create unequal transactions, where consumers interests’ are not equally balanced with their employers’ interest for profit? Or will we fight to protect the integrity of our power by representing those who have the less powerful voice? In many cases, individuals are even unaware that they are getting the short end of the stick. Facebook, for example, is designed in many ways to hi-jack people’s cognitive functions and encourage more use, however unaware the user is. In this case, the user has lost the greatest power that he or she has – the power of the mind.

As designers, we need to realize the great power that we wield. We need to be arbiters of power, becoming more aware of the needs of an employer or client and the needs of the users. We need to be wary of our own selfishness as well. Will we balance our self-interest and needs for employment, prestige, and even power itself for the needs of the greater collective? And will we balance our own needs with the needs of the other – that person who most often is least like ourselves – the user?

These are the questions we need to grapple with as we head into the world, honing our craft in design. Theory is only useful insofar as it’s used. In the coming months, we’ll have our best opportunity to put these theories of design and power into practice. Let us put our power to practice in supporting justice, protecting everything that stands against love.

Making progress with Housing Assist

A lot has been happening with the development of Housing Assist, and working with organizations like Meals on Wheels of Central Texas, a leader in the area for home services, we’ve made a great deal of progress!

The focus for the last few weeks has been on developing the business concept and way that residents can more easily apply for and access home repair services.

In this post, I’ll cover some background on the project in addition to more recent updates and a look at my next steps.


Project Background

For those of you who are new to the project, my team spent eight weeks doing design research with the City of Austin, interviewing dozens of lower-income homeowners to understand opportunities to improve their experiences and quality of life in the city.

One of the key insights from that research was that many low-income homeowners struggled with the costs of maintaining repairs and improvements on their homes. From leaky roofs to mobility challenges to requirements by code enforcement to fix up their homes, these homeowners faced unsafe conditions or possibly having to leave their homes if they didn’t repair them.

A home requiring critical repairs. The owner gave up on applying for repair assistance.
A home requiring critical repairs. The owner gave up on applying for repair assistance.

The biggest challenge for these homeowners isn’t that housing repair services don’t exist – there are about a dozen organizations who provide the services. The challenge for many of them is that the options and requirements to pursue in applying for help is fraught with challenges causing many homeowners to give up or hit dead ends needlessly.

Housing Assist

How might we make it easier for homeowners to get the housing repairs they need to continue to keep and live healthfully in their homes?

Housing Assist is a service that helps homeowners stay in their homes by centralizing and streamlining the application process. Instead of directing applicants to each of the many service providers, applicants are directed to answer a handful of questions in a central, easy-to-use, website, and within moments of providing the responses, they get a clear response indicating their eligibility and their matching organizations.

With a central pool of applicants and assigned matching based on service providers’ eligibility profile, Housing Assist helps the Austin Housing Repair Coalition members better coordinate their resources, meet capacity for their grants, and serve the residents of Austin.

In addition, instead of receiving several confusing, overlapping, and redundant applications, homeowners receive consolidated versions of the applications they’re matched to and only need to fill out the one.

In all, the streamlined process and application help both homeowners and service providers to more effectively complete the application process, improving homeowners’ likelihood of getting the services they need to keep and live healthfully in their homes.

Recent Updates

Application Analysis & Vision for Housing Assist

Over the past three weeks, I have been fortunate to have time meeting with and discussing the details of the housing repair programs, applications, and processes with experts in the field from organizations in the Austin Housing Repair Coalition such as Meals on Wheels. These meetings have been instrumental to develop partnerships for piloting a prototype of Housing Assist as well as to gain insights into developing a solution.

There are several programs and organizations that individuals may apply to for assistance. Charlie Cloutman, the VP of Home Repair Programs and John Lyon, the Housing Repair Programs Manager helped me understand the programs, their application forms, and the processes to apply.

After analyzing the applications and their requirements, we developed a series of questions and processes that would be most likely to assess applicant eligibility. This information helped inform my later solution of developing a preliminary intake that will be so helpful in evaluating applicants’ eligibility and matching.

Image of Application Analysis
Homeowners applying for housing repair assistance need to complete as many as six applications. This analysis helped evaluate overlap and distinction of the forms’ requirements in order to design a streamlined application process.

To develop a single, unified form, I analyzed the six separate applications that residents may need to fill out in applying for home repair service. These applications can add up to over thirty pages of information and dozens of different kinds of documents required to prove their need. From identity verification to proving financial need and homeownership status, this documentation is necessary to ensure that funds go to the most needy and eligible, but, as is the case for many opportunities in society, those who are most in need are the ones least likely to have the knowledge, organization and other supports that help them complete a rigorous application process.

The question then is how to reduce the application workload while best serving applicants and providing granting agencies the documentation they require. To answer that question, I developed an analysis of the six distinct applications’ questions, requirements, and legal certifications, detailing the overlapping and distinct components. This analysis will be used to create a single application to send to applicants that synthesized the separate applications they would normally be required to complete.

If an applicant were eligible to apply for all six programs, instead of completing six applications and cross-referencing them to understand their different required documentation, applicants can complete a single, highly abbreviated and synthesized application form. When service providers receive this form, they can transfer the contents to the separate forms and get them signed for submission to the granting organizations. By reducing the workload and overwhelm for applicants, this process will also improve the likelihood they will successfully complete the application process and receive the help that they need.


The partnership with Meals on Wheels of Central Texas has been very fruitful. In addition to supporting my analysis of the challenge, they have come onboard to partner for the pilot as well. I will join them on an intake visit with a new applicant in the next two weeks and we will assist the homeowner to complete the full application form.

The opportunity will help us understand the usability of the form. In addition, the intake specialist and I will translate the form contents to the six separate forms, evaluating the work effort of the process and the accuracy of the form’s alignment to the six original applications.

Next up


The coming weeks will be focused on developing and doing usability testing on the wireframes for the online web form that will serve as the initial intake.

Customer Journey Maps, Service Blueprints, and Story boards

I have needed to shift the Housing Assist approach recently, making the past concept models outdated. (I have not included them in this post for just this reason. They would not match the content of this post and would confuse the reader.) I am developing new versions of those documents this week and will post them in my next post for Housing Assist.

Until then, stay tuned!

Shifting from Design to Product Management & Development

“Put on your thinking cap!” Do you remember your elementary teacher saying that?

I used to think it was a quaint thing to say, but there’s a lot of power behind the symbolism of the thinking cap. Over the last two weeks, I put on new thinking caps – the developer and product manager’s thinking caps.

Over the course of eight weeks in the winter, I redesigned the Wells Fargo Banking app. From concept maps and information architecture maps to mock-ups, usability testing, and many iterations of the wireframe designs, the app’s design slowly took form.

Wells Fargo Redesign – Concept Mapping

Wells Fargo Redesign – Rapid Prototyping

Wells Fargo Redesign – New Features

Over the eight week period of this quarter, we’re taking a very different approach to thinking about this app redesign. Rather than rather than thinking creatively as designers by putting down the constraints of what’s “realistic” from the business perspective, we are learning to think creatively from the perspective of developers and product managers. How do we make that abstract design into a concrete reality. The key word here is “concrete”.

To create a vision for how to realize this design, we are walking through various exercises typical to development and delivery.

  • Feature analysis
  • Sizing (Estimation)
  • Product Road Mapping
  • Thin-Slice development

This blog post is about Feature analysis and sizing and my experience completing these tasks with my Wells Fargo app redesign as the sample project.

Feature Analysis

First off, what is “Sizing”? Sizing is just another name for estimation. We want to create an app, but first we need to size it up, or estimate its potential cost, in order to keep the process in check. Without a good estimate, it’s easy to let development costs and timelines get out of hand, severely jeopardizing the success or viability of the project.

The first step to creating an estimate for the development cost is to break down the application into its individual parts. We can think of the app as having two types of “parts” – its features, and its elements. By breaking down the app into smaller parts, we can price out each of the parts in order to have a more accurate sense of the effort and cost to develop the larger whole.

What is a feature? A feature is a capability. The app for example, allows for depositing a check with your phone. The fact that we can do this is like magic. But to paraphrase a quote attributed to Thomas Edison, “All magic is science that isn’t yet understood.” That high-level capability is important to list as a feature for the app, but it isn’t broken down yet into manageable chunks that helps a developer understand what to code. So we can break it down further and further until we have the right level of detail so it isn’t too high level or too granular to be manageable by the developers who will need to code the app.

Image of Mobile Check Deposit Screen
Mobile Check Deposit Screen

In the case of Mobile Check Deposit, we can break this high-level feature down to things such as:

  • Indicate Account into which the check is deposited
  • Take a picture of the front and back of the check
  • Pull up Photo-Taking Tips
  • Input the amount of the check
  • Provide Check Deposit Confirmation to User

These lower level features spell out the various capabilities and actions one may take to deposit a check.

All of these features and sub-features or functions are very abstract, however. What do they look like? What are the pieces and parts that give form to these functions? These are the elements. Examples of these elements include screen overlays, dialog menus, dividers, drop-down or accordion menus, headers, sub-headers, input fields, date pickers, navigation bars, and more.

The first step in creating an estimate, therefore, is to fully analyze the application in terms it’s form and function, or in other words, it’s elements and features.


To identify the specific elements and features in the app, one could lay out every screen in no specific order, specifying the form and function of every part of each screen, but this would be a confusing and ineffective way to complete the task.

A much better way to complete the task is to show these elements and features in the context of use. To do this, we lay out what are called “Flows”.

Each flow represents the achievement of a goal by a user. “Deposit a check for $25 in the Debit account” is one example of a goal a user may set out to achieve. To achieve this goal, the user follows a series of steps through the app. These are laid out in the accompanying figure. The places where a user interacts with the app through screen taps is indicated by purple bulls-eyes.

Image of Mobile Check Deposit Flow
A “Flow” of screens through which the user moves as she deposits a check.

Now that the flow is laid out, I can analyze and communicate the elements and sub-features that compose the app and are evident in the screens. They’re all represented in the context of a process, further clarifying their function or relative use.

After analyzing the various flows I developed for the app and identifying the elements and features within them, I will next review them with a developer to create an estimate of their costs. Before I meet with the developer however, I want to be even more organized so I can clearly communicate these parts to him.


The next step I took was to organize these features and elements. With proper organization, it is much easier to communicate and handoff the app’s design and specifications to the developer. To organize the elements and features, I took screenshots of each of them and arranged them in a grid. I then gave each one its own identification code and title. Lastly, I added a description of the item to better specify its functionality.


Mobile Check Breakdown-53-53


Why should we spend so much work to communicate the design’s specifications? With this level of specificity, the developer is much more likely to create the app in the way the designer originally envisioned.

Without this specificity, a developer is more likely to not encode a particular functionality for the element, or she may come to a point where she has to come up with her own solution which likely is not the approach the designer had in mind. A developer may have good problem-solving, but this isn’t what they were hired to do in most cases.

For all these reasons, it’s important for the designer to develop materials to clearly specify the design’s form and functionality.

Link to Full Set of Flows and Elements

Developer Estimation

After developing the feature and element grid, I met with a developer to review the materials. I was fortunate that Andre Ortiz, an experienced designer/developer, volunteered an hour of his time to help me learn this process. We spent one hour together, analyzing the flows.

With each flow that we reviewed, we discussed the screens’ elements and functions. “What’s this button do right here?”, “Where does the list of accounts come from?”, “How do you expect the app to analyze a picture of a check to prove it’s real?”

These questions reveal many things. First of all, these questions facilitate the communication what the designer already has in mind for the app. Second of all, they reveal things the designer didn’t think of yet. Third of all, they reveal the perspective, knowledge, and mindset of the developer. The opportunity for such questions makes meeting and discussion much more fruitful than simply “handing off” specifications to a developer.

One example of something I had overlooked in the specification and design process was the behavior of the Account Summary screen as users scroll down it, opening accordion menus to view specific accounts and details within.


Image of Sticky Menus
The developer conversation yielded new ideas, such as the Sticky Menus feature.

Andre: “What happens when I scroll down here? What if I have five checking accounts? It’s going to get really long.”

Noah: “You’ll just open the accordion menus and have a long list. That’s it.”

Andre: “In the case that I have lots of accounts that extend beyond the top and bottom of the screen, what if the ‘Accounts Summary’ menu headers stick to the top of the screen as I scroll through the Accounts?”

This was a great idea. This conversation revealed something I hadn’t thought of. Now that we clarified that behavior, the app would be that much more easy to understand for users. In addition, this conversation revealed something about my developer’s knowledge and perspective. He practices a mix of design and development.

With this in mind, I know better understand his capacity for solving similar, unspecified design problems in the future. Conversely, I found that he did not have as in-depth an understanding yet of some banking app protocols. This meant that it would take longer for him to develop those portions of the app, in effect increasing the costliness of his services.

During the development estimation conversation, we pored over the flows in this way and he provided ballpark estimates of how long he thought each feature or flow would take to build. I kept a spreadsheet that tracked the estimates and discussion points supporting those estimates.

App Estimate Spreadsheet
A spreadsheet with specific feature and flow analysis helps keep tabs of estimated costs.

Link to App Development Estimate Spreadsheet

Estimation in Full

After the conversation, I added up the various estimates and found that the flows we covered would take roughly 915 hours to complete. This number included additional hours to “pad” the time, saving us both from the drama of broken promises and missed deadlines which could ruin a relationship and complicate other tasks dependent on the application’s completed stages.

Assuming I were to have two developers working forty hours per week, this work would be completed in approximately three months. How so fast? The truth is that I was ambitious in scoping out the full functionality of the application. Several parts of the app were not yet designed on paper, including the message center, transaction list and search, and customer service functions like replacing a card, managing travel plans, or disputing a transaction.

For the purpose of the exercise, I added all these items to my spreadsheet and used Andre’s estimates and justification to make my own estimates of how long these items would take to complete. The remaining features would take about 1,225 hours to complete, implying that the full development would take about 2,140 hours, or roughly seven months for two developers. This, according to Andre, sounded like a much more reasonable timeline to develop a full featured banking application.


The first big lesson I learned here is that it’s invaluable for designers to learn the end-to-end design process, including the development and shipping stages. In addition to simply knowing “about” the process, designers benefit from doing the process. Only in this way can we as designers learn the language, concerns, and perspectives of those individuals who are responsible for shipping the design.

By understanding their perspectives, it helps us work even better with those individuals. We’re a team, after all, developing products and services that are only truly valuable if they’re delivered properly. Even if the design was originally excellent, if it isn’t specified well, developers are disadvantaged in creating the product that was so rigorously user-tested, potentially leading to a substandard product.

The second key lesson I learned is that nothing beats a conversation. As specific as documented materials may be, a conversation provides the space and opportunity to ensure even more detail can be communicated or thought through regarding the product.

The last lesson I took away from this experience has been to “Know thy Developer”. Before this exercise, I hadn’t had in-depth conversations with many developers about products. During the exercise, however, we met with multiple developers who had substantially different backgrounds, demeanors, and skill sets. One was more entrepreneurial, another was more focused on front-end design, and a third had much more knowledge about physical products than the first two. I could hire any of them to develop this app, but what else do I get other than the baseline coding skills? What if a problem comes up? What opportunities might they see?

It depends on more than their ability to use a specific coding language. In hiring a contractor or agency for a development project, it’s important to weigh what other strengths or gaps they may have. I would prefer to think of them as being a member of the team rather than a hired gun. Given my team’s strengths, what skills, other than coding skills, might the ideal contractor possess to create the best outcomes for our project?


The design hat is off. I’ve put down my Adobe Illustrator pen, for the most part, and I’ve picked up the spreadsheet and project manager tools. It’s been enlightening to look at the product from this perspective. Stay tuned in the coming weeks as we develop a product road map and even get deep into coding a slice of our product’s functionality.


The Power & Perils of Doing Good

“The Great Rain” A story where doing good and doing business got all mixed up.



The following is a transcript from a radio segment recorded and aired 3/15/2018. AC4D FM. All rights reserved.

Theater Critic, Georgia Davis.

Georgia Davis: Sex doesn’t sell. Emotions do. Truly, emotions rule the world.


Welcome to Arts & Technology, a review at the intersection of the humanities and engineering of today’s world. Last night I saw the most intriguing play.

Written by Noah Ratzan, the play, “The Great Rain” is a rather short but potent illustration of the power and perils entangled with doing good in today’s consumerist society. I’m happy tonight to have the playwright with us here to talk about the work.

Georgia: Mr. Ratzan. Thank you so much for coming on the show today.


Noah: Thank you for having me.


Georgia: I saw the stage reading of the play just last night and loved it. The acting is obviously on a trajectory for the stars. Tell us a bit about the story.


Noah: Well, the story on the surface is about a kingdom with a king and a queen, far away, once upon a time. One of those kinds of stories. I made it that way so it could both appeal to children and adults. The premise of the story is much more than fairytales.


Essentially, the story is about the challenges of doing good in today’s society. You see, the king and queen are good at heart, but they are faced with a major crisis when a non-stop rain begins and destroys much of the village. Throughout the story, the rain never stops. So they need to think of something quick to get their kingdom back on its feet despite the rain.


Natural disaster is one thing, but this is where it all begins to truly go awry.


Georgia: How so?


Noah: So the rain starts, and this monarchy duo – in fact I represent them as an egalitarian duo rather than have the king in charge – they immediately look to their advisors to solve the problems. One by one, the advisors recommend a different solution that doesn’t quite pan out right, until they finally develop a better solution in the end, of course. It’s a Hollywood type play.


Georgia: Ha! Well, give us an example.


Noah: The first advisor, for example, recommends that they run a contest to see who can come up with the best solution. There are three solutions recommended, and the king lunges for the third. It’s the sexiest of the three solutions, recommending that the kingdom provide seed funding to an entrepreneurial startup called Iron House that will rebuild all the kingdom’s houses with technologically superior houses. Instead of mud, they’ll be built with iron nails, a new invention at the time of this kingdom.


Well, the houses are great, but then everyone realizes that only the rich have afforded them. The poor don’t have anything still.


Georgia: And are you suggesting this happens today? Where?


Noah: Definitely! Design competitions are all the rage. At business and design schools in particular, they often focus on a social cause like poverty, homelessness, or some political or economic problem. There’s a great article by Michael Gordon of Stanford and Daniela Papi-Thornton of Oxford University about this phenomenon.


Georgia: What’s the problem?


Noah: The challenge is generally in how constrained these competitions tend to be. There’s too much of a focus on what’s sexy, like entrepreneurship and big bold solutions. In the end, solutions that may be oriented toward supporting existing non-profit or government efforts are seen as less than worthy. This isn’t a good message to send to tomorrow’s leaders. In addition, students rarely have an opportunity to do in-depth research to gain a deeper understanding of the problem space.


All these problems are reflected in the play. The first of the advisors rushes to recommend a competition. In the end, great ideas that involve government are forgotten in the sublime and blinding light of the more technologically cutting-edge, entrepreneurial solution.


Georgia: How about the second advisor? His plan seemed to be pretty inane. She recommended selling blueprints to the poor. Who would think that could work?


Noah: Well, the fact is, some people really do think that selling to the poor is the best way to propel the economy and also support them.


Georgia: Like who?!


Noah: C.K. Prahalad is one of them. He was a big proponent of the Bottom Of the Pyramid economic model. He proposed that the poor, those at the bottom of the socio-economic pyramid, have a lot of buying power that’s overlooked by corporations. Instead of writing them off, he suggests that corporations market inexpensive products to them. In this way, corporations can profit more while the poor can also benefit by having a wider array of products within their reach.


Georgia: Interesting. I never thought about it that way.


Noah: Right, the second advisor’s suggestion is along these lines. Why not market something potentially valuable to the poor. It’s inexpensive, and it’s something that’s certainly valuable. There are many challenges with this bottom of the pyramid theory, however. Aneel Karnani is a vocal critic of C.K. Prahalad, and he makes good points about the holes in this theory. There aren’t actually as many poor as Prahalad proposes. Also, it’s very difficult to market to the poor due to cultural heterogeneity, and it’s difficult to distribute to the poor because of geographic dispersion of many of the world’s poor. In the story, I take a different angle. The fact is that the advisor just didn’t think the business model through. Blueprints are only valuable insofar as the consumer can bring them to life.


Georgia: If this person is an advisor to the king, why would they make such a mistake?


Noah: The advisors are all representative of designers in this story, each trying to solve the problem in their own way. One of the themes in the play that I wanted to make clear is that we all must spend more time in a problem space to develop stronger solution proposals. Though this advisor presumably has done “research”, it’s still very little. Designers who are worth their salt delve deep into a culture to gain better insights about those they’re designing for. Jan Chipchase is a well-known design researcher. I just read an article that outlined the dozens of interviews and in-depth research he and his associate, Lauren Serrota, did for a project in Saudi Arabia. This advisor suggesting they sell blueprints to these townfolk certainly hadn’t done his research.


Georgia: And the third advisor? I liked his proposal. Just so our listeners know what we’re talking about… the third advisor recommends that the housing construction business, Iron House, promote charity with a one-for-one campaign. For each house purchased, Iron House will build a house for someone in need. It reminds me so much of campaigns like Tom’s, the shoe company. What’s wrong with that?


Noah: Don’t get me wrong, there are certainly companies whose business model works in this context. A one-for-one campaign really can do good for the beneficiaries of the campaign. There are other implications, however, that aren’t always so clear.


Georgia: Like what?


Noah: First of all, sometimes these one-for-one campaigns totally miss the mark in the same way that the blueprints did – the beneficiaries simply don’t need these items. There are examples where shoes from Toms were given to people who simply don’t wear shoes. That’s a minor matter, though. One of the bigger problems is that these marketing campaigns complicate the way people relate to making a difference in the world.


How do we help others? One could help them directly, or perhaps even support organizations that help them, like donating to the Red Cross. One could even consume in a conscious way – refraining from purchasing items that were likely made using child labor, for example. Recently, however, businesses have begun to associate consumption of their product with supporting charitable causes. Buy a product that supports the (PRODUCT) Red campaign, for example, and they’ll donate to the Global Fund. The purchase or making of the product really has nothing intrinsically to do with HIV/AIDS, but the campaign takes on the role of the cause. Why? Who wouldn’t want to support HIV/AIDS?


Georgia: So you don’t think the (PRODUCT) Red campaign is helpful?


Noah: It is helpful. The Global Fund received five times its normal fundraising amount when the (PRODUCT) Red campaign started. The problem to me is that this business behavior changes our culture of compassion. Rather than support a cause, this marketing trend exploits people’s desire to help others in order to help them validate consumption of their products. Why don’t consumers just donate directly to the Global Fund? In her article on the topic, “Save Africa: The commodification of (PRODUCT) RED campaign”, Cindy Phu points to organizations like BuyLessCrap.com that even set up websites to subvert the (PRODUCT) Red efforts. Through the site, you can donate directly to these causes.


In the play, the third advisor’s scheme to increase housing sales fails. What’s more, it also generates increased hunger for the rich to purchase more land for the houses they’ve been incentivized to buy in order to support the poor. It reminds me of how Phu points to the fact that in supporting the children suffering from HIV/AIDs, wealthier westerners purchase Gap clothing that just may have been made using child labor. Terribly ironic.


Georgia: Yikes. Sounds dismal. Fortunately, your story has a somewhat happy ending.


Noah: Yes, in the end, they come to the fourth advisor. When confronted about the dire situation, she points out it’s not her plan at all. Her plan was to make a work education program for the poor. It was a plan that she offered in the initial business competition. The King and Queen overlooked it however because of the flashy ideas, sexy entrepreneurship, and cutting-edge technology offered up by the winning team.


The irony is that the fourth advisor’s ultimately successful idea could have been implemented from the outset. Joyojeet Pal, an academic at the University of Michigan, makes an interesting point in one of his articles about the seduction of technology. There’s an effect dubbed “Charismatic Authority”, where people are wooed by people’s charisma. The fact is that technology has that charisma too. This is the same problem that undermined the fourth advisor’s content pitch. Her idea was to lift up the kingdom’s poor with a workforce education program. What’s sexy about that?


In the end, the fourth advisor’s workforce education program is just what Karnani is a proponent of. Instead of making the poor into pure consumers, as C.K. Prahalad supported, we ought to help the poor develop the skills to contribute. Only after they’ve developed these skills does the housing situation in this fictional kingdom improve.


Georgia: It’s such a simple story. I had no clue there was so much behind it.


Noah: That’s the nature of the work. So much in design appears simple. The answers seem obvious in hindsight, but the foundation to good design can never be simplistic or superficial, or else it will likely be off the mark.


Georgia: Thank you Noah for joining us for this week’s edition of Arts & Technology, a radio segment all about the intersection of the humanities and engineering of today’s world.