Learning from Conversations with a Developer

A few months ago, I had built out an interactive wireframe of a bank app for the purpose of user testing.  Over the last two weeks, I was tasked with taking that design and size the feature.

All the Hurdles.

#1. Foundational Hurdles. The biggest initial challenge was to build out the remaining flows that I did not get the time to build. That is four out of a total of six flows. Additionally, I still needed to figure out how to make the app usable. These were very intimidating tasks because I hadn’t cracked the code on how to build wireframes quickly, how to map the user flows in a way that is smooth and achieve a clear goal, and going pedal to the metal was not an option as time is not a luxury at AC4D.

#2. First Meeting with a Developer. I was also to show my wireframes of the bank app to Eric Webb, a developer who has volunteered his time to help AC4D designers in training how to size and estimate the app’s features. Can’t do this if there isn’t much to show.

#3. Time. I need to do all of that as well as identify the key features, estimate the time it would take to develop the feature after a conversation with Eric, the developer.

I’ll be sharing with you how I overcame the hurdles and my journey in over the last two weeks.


The Process

Step 1. Meet with A Developer. Recognizing that I still had some wireframes to critique, I decided to meet with Eric earlier rather than later to get some feedback and suggestions on the existing mock-ups and understand what to consider from a product engineer’s perspective. As creativity does not happen in a silo, and developers also build things with users in mind, this conversation did provide a richer understanding of how to design for a user.

2. Complete more of the wireframe. Based on feedback from Eric, and hearing him talk through how he would implement parts of my design, and talk through what some parts of the design seemed unnecessary, I took some key takeaways with me as I rebuilt the existing parts of my app, and built out the remainder flows. Compared to 2 flows with repearted screens over the course 45+hours, I was able to build out unique, 28 key app screens that had a clear visual hierarchy, in less than 20 hours.

3. Second Meeting with a Developer. This is what I will be doing next. I will print out my screens and annotate (also called redlining) the components of each app screen as a developer helps estimate how long the app will take, and about how much it will cost to build the app.

Key Takeaways

While I did not get to a place with estimation, working with Eric and discussing the natural flow of an app and how users typically interact with apps was super helpful. Here are some key takeaways that I will actively include in my process in the future.  When designing keep the following in mind.

Use Existing Element over Custom Element.

Custom controls and UI take more time, to design, to build, test, and (for iOS apps) it may take longer to approved by Apple as you maybe not following their style guide properly. Making custom components for the sake of delightfulness comes at a high cost, literally.  Custom elements are best reserved for making the user experience & business interaction move valuable, efficient, and pleasing.

The result of this is more consistency in what you built, it’s faster to reuse existing components in design as well as in development, and the app is less brittle. When something breaks it is faster to identify and fix that single component that exists in several places.

The components of your app will have a pattern, which decreases the user’s learning curve as they interact with the app, and navigation become more intuitive for less tech-savvy users.

The components of your app will have a pattern.

Have Clear Defined Goal

Have a clear single defined goal for the app as well as for each flow. Without this, is it very hard to decide what elements, details, and information to include, let along how to outline the flow.  Knowing those things makes it infinitely easier to be decisive on where to place certain navigations, how to build a clear hierarchy, and you move faster.

Before_No Clear Goal After_Clear Goal


Consider Typical User Behavior 

When Eric asked me “When was the last time you logged out of an app?”  I, like many, couldn’t remember when I last did that on a browser or app. So, it was clear to me that keeping a Log Out link would be a waste of valuable phone real estate. I started paying more attention to how I bank and took a closer look at the things in the apps I’ve used that I never noticed before. All of the links I never touch in an app made it on a list of low priority elements that I will use to survey my peers and people I interact with daily. Some things that make it onto the list when it comes to my banking apps are: find a bank location, help, privacy policy, legal policy, terms & conditions, statements, setting a language preference, login information, notifications, alerts, bill pay.  As a result, I opted for moving the Log Out link into a hamburger menu.

Be Prepared, and Ready to Trim Ideas

After hearing from my classmates, when I meet with a developer to gauge feature estimates, I will be prepared by having the ideal state of the app screens printed to share and to make note of critiques on, be ready to explain why I made design choice I over other options, have all my feature named and listed, be ready to ask for alternative options and to ask lots of questions. I did not do a very good job asking questions about trade-off such as loading time (which impacts the user’s experience), and security features.


Mock Up Screens

Here are the flows I’ve created and will be used for estimations.





Accounts. Users can monitor their account.




Transfer Money. Users can transfer money between your accounts or to an external account.


 Pay A Bill.

Bill Pay

Making a Banking App (Somewhat of) a Reality

Last week we took our wireframe flows from our banking apps and began to work with developers to start the process of building them out. In a perfect world we’d have all the screens built out and then present them to the developer to answer any questions and explain anything that wasn’t clear.

I had a quick call with Eric, the developer I’m working with, to chat about where I’m at and what my goals are for this project. I told him that I felt super behind he didn’t shame me for it. He would rather meet and understand the scope sooner rather than later. I told him that my goals for this project are to understand how a developer thinks. I have a print/graphic design background and I know the printing process very well and it affects how I design. I want to be the same sort of digital designer.

Eric and I met on Friday for a little over an hour and I went through all of my flows.

Deposit a Check

Deposit Check Deposit Check 2

Find Security Code
Find Security Code
Spending Alert
Spending Alert
Budget & Spending Trends
Budget and Spending
Categorize Transaction

Categorize Transaction
I definitely didn’t have every single screen built out nor did I have my redlines done, which turned out to be okay. Eric said he never asks for redlines for clients. What he would rather have from me is a Style Guide and markup notes on any custom animations. He also said that he always estimates 1 day per screen, unless it needs something extra. Using t-shirt sizing, “Small” = 1 day, “Medium” = 1.5 days and “Large” = 2 days. Nearly every screen I showed him was a “Small” with the exception of my Budget screen, which was a Medium and my Spending Trends was a Large.

Since I hadn’t built my screens and had no idea how many my app would need, I created a spreadsheet of everything to be done in the app. My final count was 72 screens which would take Eric about 14 weeks to build. If I’ve forgotten any screens, which I surely have, it will take longer.

Here’s a sample of just the screens needed to be built before the user logs into the app.

Login Screens

Next Steps:

I have a list of what information and elements Eric wants to see in the Style Guide so I’ll be working on that. I will also continue to build out the wireframes.


As I watched my fellow students present their wireframes I started to understand why a redline would be necessary. So I’ve started the process of redlining my designs.

Artboard 1Artboard 1 copy

Ideal State Wireframes Meet Feasibility and Constraints


In our product management course we are building off our banking app wireframes we developed in quarter 3. As of yet, we have been encouraged to explore with very few limitations outside of what our instructor wanted our core functionalities to be. This quarter we are learning the beginning steps of bringing the product to market by putting our designs under the developing lens and estimating what should and should not be built for an MVP.

For assignment 1 we were asked to visualize our features, the screens in those features, controls and components of those screens, and a breakdown of what the user goes through. Below are my flows redlined as they were before reworking the app based on the developer’s feedback. During assignment 2 I will be redesigning these flows to better suit an MVP, while keeping the north star in mind. You will see a legend for the pages (feature flows in magenta, controls in red, and breakdown in black text).


Screen Shot 2019-03-18 at 6.12.46 PM

Screen Shot 2019-03-18 at 6.12.58 PM

Screen Shot 2019-03-18 at 6.13.05 PM Screen Shot 2019-03-18 at 6.13.12 PM Screen Shot 2019-03-18 at 6.13.18 PM

Screen Shot 2019-03-18 at 6.13.32 PM Screen Shot 2019-03-18 at 6.13.38 PM

Screen Shot 2019-03-18 at 6.13.45 PM Screen Shot 2019-03-18 at 6.13.52 PM Screen Shot 2019-03-18 at 6.13.59 PM

Screen Shot 2019-03-18 at 6.14.05 PM Screen Shot 2019-03-18 at 6.14.13 PM

Screen Shot 2019-03-18 at 6.14.19 PM Screen Shot 2019-03-18 at 6.14.32 PM Screen Shot 2019-03-18 at 6.14.40 PM Screen Shot 2019-03-18 at 6.14.47 PM Screen Shot 2019-03-18 at 6.14.54 PM Screen Shot 2019-03-18 at 6.14.25 PM Screen Shot 2019-03-18 at 6.15.02 PM

Screen Shot 2019-03-18 at 6.15.26 PM Screen Shot 2019-03-18 at 6.15.19 PM



Sizing with a developer is meticulous but it is essential in pulling back the reigns on my product and really grounding it in reality. After meeting with a developer I got a rough idea of how long the app would take to develop based on his interpretation of the screens and components I shared. Not many of the estimates were very large for any given screen I estimated in total the coding wouldn’t take more than a couple weeks. I will be taking my critiques from the dev and thin slicing my hero flows into more concise and cleaner MVP flows.

In summary the front-end development would take

256 man hours

32 days

6.4 weeks

Below is a detailed spreadsheet of estimates.


The developer also gave my really good recommendations for redesigns based on his knowledge of HIG and I will be implementing them into the next iteration of apps that I will be sharing out after assignment 2.


To Build an App: Partnering with a Developer

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

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

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



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

Cost of application build assuming the bank already exists 

90.5 Days

724 Hours


Estimating fantasy to fruition


For the past two months, our cohort has been working on designing a banking app that integrates traditional banking functionality with financial forecasting features. In our Product Management course, we are learning fundamental methods to take a product from wireframe to market. The first step along this journey? Meet up with a developer to enjoy a dose of reality!

When design meets development

Last week, I met with my assigned developer to estimate how long it would take to turn my hypothetical banking app into a functioning reality. Together we walked through eight flows depicting various user actions (Appendix A), mulled over controls and features (Appendix B), and then the developer estimated how many days it would take for him to build out the app as designed (Appendix C).

Key Takeaways

I learned a lot during our hour-long session… definitely too much to describe in detail whilst still maintaining the focus of our faithful AC4D blog readers! Below I will instead highlight a few primary takeaways from the perspective of a designer’s first meeting with a developer, in case this advice proves helpful for anyone out there in the process of designing your own app:

Be consistent.

Whenever possible, reuse elements as you design. This both helps to maintain a consistent look and feel for the user, and it coincidentally also drastically lowers time the required for a developer to build out your app.

Plan ahead.

Do you want your app to be available in both iOS and Android? Go ahead and double that estimation that the developer gave you! Development takes time and money, so be sure you have enough of each to make your plans a reality.

Stay flexible.

When you meet with a developer, be clear about what user goals you are designing for and remain open-minded about the details. The developer may suggest a more efficient way (see below) of designing to meet your goals!

Meeting with developer
The developer suggested that I look into integrating Zelle® technology into my banking app in lieu of developing my own payments functionality. He showed me his own banking app (with Zelle®) to show me just how easy payments could be!

Moving forward

The next step in this process will be to take everything that we have learned and develop a product roadmap that integrates our most desired features and functionalities for this app based on our conversation and estimations from the developer. Stay tuned!

Appendix A: Flow Animations

For your viewing pleasure, below please find animations of each flow that I designed. The red dots represent where a user would click to advance to the next screen once the requisite information has been entered.

Flow 1: Log in as a returning user Flow 2: View transaction summary (GIF) flow3 flow4 flow5 flow6 flow7 flow8

Appendix B: Controls and Features

In the eight flows linked below, highlighted controls are red and highlighted features are blue. You may click any flow image to display a zoomed-in version of the flow.

Flow 1: Controls & Features
Flow 1: Controls & Features (click to view detail)
Flow 2: Controls & Features (click to view detail)
Flow 2: Controls & Features (click to view detail)
Flow 3: Controls & Features
Flow 3: Controls & Features (click to view detail)
Flow 4: Controls & Features
Flow 4: Controls & Features (click to view detail)
Flow 5: Controls & Features
Flow 5: Controls & Features (click to view detail)
Flow 6: Controls & Features
Flow 6: Controls & Features (click to view detail)
Flow 7: Controls & Features
Flow 7: Controls & Features (click to view detail)
Flow 8: Controls & Features
Flow 8: Controls & Features (click to view detail)

Appendix C: Estimation Session

Click to view the estimations calculated after meeting with a developer. This shared Google spreadsheet shows an estimate of how many days it would take the developer to build out each flow based on my individual wireframes. Also included are a few notes from our discussion. Feel free to comment with any questions!

Meet the developers!

First off, a big thank you to all the developers for offering their time to us.

Over the past 2 weeks I have revised and notated my banking app wireframes in preparation for meeting with a developer, Caleb Thomson, to discuss sizing. Sizing is the process of pricing the cost to build the visual and functional interface of the app. Caleb quoted pricing as number of days with a half day minimum. In preparation for the meeting I laid out each flow on canvases to notate features and controls. I classified controls as elements (buttons, sliders, dropdown menus) that you interact with and features as attributes of each screen. The documents are the key to the meeting of the mind of the developer and designer. To me, using the document as a source for discussion was similar to being an architectural designer meeting with a builder. The same frustrations exist between what the designer dreams and what is a possibility for the builder.

In the end, I combined the features and controls onto one page which made it easy to discuss my the goals on each screen and have questions ready to gain insight into the time necessary for a simplified process of meeting the same user goal. One of my personal objectives was to learn as much as possible about the time it takes for functions in order to implement that knowledge in any future app design so I included the more complex features and then was sure to ask how much it would cost to reach the same goal in a simpler fashion.Artboard

One of the most valuable things I learned about while understanding the time it takes to program functions was about information flow. The diagram below shows how information travels back and forth from the app through the cloud to the API (Application Program Information). Information from the bank server flows back and forth through the API to desktop computers and apps. I learned the features that took the most time were those that required displaying information that would not typically be “packaged” by the bank server or on the desktop site. The strongest example of this was showing recurring charges.

Through my questions I learned that diagrams like bars and pie charts take up weeks! In my flows I created 2 different bar graphs with similar information, but since they were slightly different sizes each could take 1-2 weeks.

My first flow shows the login process for a user to check their balance. I was really surprise that something that seemed pretty straight forward was estimated to be 2-3  weeks. Caleb informed me that I had more detail than necessary and at this phase simply a placeholder box indicating what would be completed on each screen to avoid distraction any place where spacing was not perfect.

1--LOGIN Features Copy

My next flow was an insta balance feature for the user to conveniently view their balance if they did not need further detail. This would take about 5 days, not including sign up screens to activate the insta-balance.

2--Insta B Features Copy

The second flow shows the process to reach transactions and details of the transactions. Screen 2.2B contains a bar chart the tI referenced earlier that takes weeks!

2b--Balance Features Copy

During user testing of the deposit check flow, I found that some users were weary about depositing with photos so I added a feature to show the account number and bank routing number of the photographed check. I learned that this was possible because of magnetic ink in the checks, however it would be weeks to code. Additionally, I was surprised that adding directions to the top of the camera was time consuming. Having the camera recognize the edges of the check and automatically photograph the check would take up to a month.

4--Deposit Features Copy DEposit 3

In the move money section, I built out the pay a friend feature and variations of frequency and when the transfer would occur. I was surprised that there was not much cost difference between the different sequences.

I learned that having a pop-up “toast” confirmation would take one week. If I had a static screen it would be 1-2 days, and then the following screen would be 1/2 day.

5-- Pay A Friend Features5--Pay A Friend Features Copy

5. Pay A Friend 1x Features CopyOne of the financial budgeting features I built was the ability to see your different budget “buckets” visually in a chart, scroll down and see what portion of your budget you have used each month, and then the detailed transactions in that category. Again, there graphics are really time consuming and the pie chart was estimated at 2-3 weeks. One funny takeaway was that when I was constructing the wireframes in sketch, I wasn’t able to make this visual so I downloaded a static image of a pie chart and placed a white circle inside it so it became a ring instead of a pie. Caleb said he would write it the same way!

8. Budget-Safe Features Copy

The second budgeting feature I built was to see recurring payments and be able to see how eliminating the ‘subscription’ would impact your financial goals for saving and paying down debt. Caleb thought this was a great feature but defining the recurring charges would be a challenge because that may not be identified in the bank server so would be very time consuming.

10--WHAT IF FEATURESView the sizing estimate here

Thank you again to Caleb for his time. I am looking forward to my next steps of reducing the features to be more cost effective.

Wireframe Sizing Evaluation

In our Product Management course with Scott Magee, we’ve been revising our banking app wireframes that we designed in our Q3 Designing Digital Interfaces course, in order to learn how a product goes from the wireframe stage to market. An important step in that process is identifying capabilities and controls within the app, then meeting with a developer to determine roughly how long it will take to develop the app based on those features.

At the beginning of this process, I took an inventory of screens and flows, and knew that there was a lot of functionality that was incomplete. Within the time frame of the assignment, I knew there would be a tradeoff between completeness and complexity. My goal was to have a complete set of flows, no matter how minimal in total scope, so I wound up having to reduce and simplify the functionality that I had begun to build out in Q3, including most of the financial modeling that had gone into the app. Although the current app only allows the user to do a limited number of actions – transfer funds, deposit checks, view balances, add accounts, view transaction history – those represent the core functionality of a banking app. There is very little that I wasn’t able to completely build out within the scope that I aimed for, and I feel satisfied with the current status. I have 12 main flows, including login alternatives and pre-login actions.

In an exercise to understand wireframing edge cases and errors, I decided to take a small portion of the app – login options – and include every error state and screen that I could predict, which is reflected in my flows. I quickly realized how time-consuming it is to design these, but also how important it is to consider how and when a user might cause an error, and what information they need to be given to proceed.


Flow 1 - Login Standard A

Flow 1 - Login Standard B

Flow 2 - Login Passcode A

Flow 2 - Login Passcode B

Flow 2 - Login Passcode C

Flow 3 - Login Fingerprint A

Flow 3 - Login Fingerprint B

Flow 3 - Login Fingerprint C

Flow 4 - Logout

Flow 5 - Call Us

Flow 6 - Locations A

Flow 6 - Locations B

Flow 7 - Enroll A

Flow 7 - Enroll B

Flow 7 - Enroll C

Flow 8 - Check Balance

Flow 9 - Dep Chk A

Flow 9 - Dep Chk B

Flow 9 - Dep Chk C

Flow 10 - View Activity A

Flow 10 - View Activity B

Flow 10 - View Activity C

Flow 11 - Int Xfer A

Flow 11 - Int Xfer B

Flow 11 - Int Xfer C

Flow 12 - Add Xtnl Acct A

Flow 12 - Add Xtnl Acct B

Flow 12 - Add Xtnl Acct C

Flow 12 - Add Xtnl Acct D


I had the honor and pleasure of meeting with developer and entrepreneur Mark Philip to size my app. As designers and students, we spend a great deal of time working on our designs, but meeting with a developer helped connect the work that I do to the bigger picture – how a product actually gets made. This meeting was a huge revelation to me in terms of the teamwork it takes to bring a product to life.

meeting with Mark Philip to estimate development time
meeting with Mark Philip to estimate development time

The meeting as a whole was a huge learning experience for me. However, I do have some key takeaways to remember for next time.

  • Having paper printouts of my screens was an enormous benefit. We could mark them up and have something tangible to reference later.
  • Mark worked with me to suggest some functionality that was missing, or to edit some elements of the screens as I had designed them. The conversation felt extremely collaborative, and I was grateful to have his experience and expertise influence revisions to my screens. I made the revisions we discussed together, which removed some extraneous screens and made the user experience better.
  • Mark suggested that it’s helpful to a developer to be given some sort of site map or architecture concept map, to aid in understanding how all the sections of the product connect. I’ll make sure to create and provide this going forward.


Sizing Spreadsheet

Mark gave me a summary in days, broken up by sections of the app – not necessarily complete flows, but pieces for development as he would approach it. The total came to 80 days, and Mark said that overall he would estimate 3 months for the scope of my current app. With 2 developers working full-time, it would take approximately 1.5 months to do the front-end development for my app, assuming that things went according to schedule. In thinking about the tradeoff of complexity vs. completeness, I’m very satisfied with how long this will take. My users won’t have a robust app, but they will be able to undertake the basic functions of a banking app with a shorter wait for roll-out. As I add functionality into the app, new versions can be released sequentially.

View a full estimation table here, with additional notes and info for each section of the app.

View a pdf of all documented flows here, including the sizing summary table.

Scoping a Banking App MVP

In our product management class we are picking up where our designing digital interfaces class left off. We’ve been tasked with taking our banking app wireframes that we made in Q3 and presenting them to a developer in a productive meeting to get a better understanding of time estimates if we were to actually move forward with building this mobile application.

I started by reviewing my existing wireframes and making updates for cohesion between the first set and second set I’d built in the previous class. Then I went through and began removing portions that alluded to screens that I would not be building or including in my MVP deliverable. This left me with 9 flows.

To help me organize all these screens, many of them being used in multiple flows, I wrote brief user stories for each of them. This cleared my head from all the screens swimming aimlessly up there and helped me focus on moving forward.

Next I exported all the screens into powerpoint and began labeling each screen in the flow order both numerically and with a descriptive title. I then went through and added all these labels for each screen to the estimate discussion spreadsheet. Then I went through and redlined all the features on each screen, and copied the screen and re-redlined the controls.

I met with Caleb, my assigned developer last Friday at Friends and Allies. We began by going through each of my flows with me explaining the clicks between each screen and what was being shown – basically following the user stories. Next we went through and discussed each screen and the time estimate he thought would be appropriate. He said he usually does his estimates in days so I worked with that and modified days to hours later. I was interesting because each new simple screen was estimated to take about 4 hours, but the estimates for the complicated screens that had unknowns in backend development quickly grew to be potentially 3 months of work.

These large ranges all hinged on how much research they would take, and at the end he said they still may not be possible. Basically they were just a big unknown. The big unknowns in development were related to the flagging transactions as recurring and anomalous algorithm, and the ability to link to a recurring payment entity’s site for cancellation.

Flagged anomalous transactions with information message.
Flagged anomalous transactions with information message.
Redirect link to cancel recurring monthly subscription transactions from the app.
Redirect link to cancel recurring monthly subscription transactions from the app.

The lower estimate for building this banking app MVP is about 13 weeks, and the upper estimate is 22+ weeks.

A few other helpful things I learned were:

  • Any kind of chart will usually take at least 2 weeks of development time.
  • Medium fidelity wireframes were his preference for scoping meetings (like this one), with more robust high fidelity wireframes being made for build out.
  • Many developers will increase their estimates to account for things that may come up unexpectedly sometimes doubling the actual time something may take.
Monthly trends chart will come in at around 2 weeks of development time.
Monthly trends chart will come in at around 2 weeks of development time.

Click below to view all my materials.

Redline Features

Redline Controls

Estimate Discussion Spreadsheet


Built For Use

For the past couple of weeks, we have worked to solidify the wireframes of our redesigned banking applications. For me, this involved going back through each of my flows and considering all the “unhappy paths.” Often, we refer to the path we want the user to take as a “happy path.” But, what happens when the user tries to do something else other than the one option you have given them? Or what if user error has caused them to get off the initial path? How do they get back? When I say that I have been considering the “unhappy paths” for the past two weeks, I mean to say that I have been considering all the paths that a user may take beyond the one I have chosen for them and then building out a flow that represents that.

To add, I have spent time refining, organizing, and adding annotations to my flows so that they may be presentable to a developer. Oddly enough, as a designer, I have spent a lot of time considering the user of the ultimate app in creating my wireframes. The exercise of making them readable to a developer asked me to consider another user, in the developer, for the first time and to consider how to make our wireframes most readable for the ones who will have the ability to make them into anything more than .png files.

I met with a developer (and former AC4D alum) this week to discuss my wireframes, consider gaps in my considerations, and get an estimate of the amount of time (and money) it will take to create my app. Below I am sharing some of the various flows I created:

Check Balance w:Annotations

Deposit Check

Transfer Money (Part 1)

Transfer Money (Part 2)

Transfer to Non-Wells Fargo

Set Alerts

Pay A Friend

Automatic Payments

In order to make our work as readable as possible for a developer, it is important to break down the various complex components of screens to show what they entail. Below you can see some of the components I included the “break down” I gave to my developer.


As I met with my developer, I learned about the estimated amount of time each screen would take to build. I learned that some elements would take significantly longer than others because of small customized elements I chose to include. I also was able to learn about gaps in the comprehension of my flow. He was able to break down the various screens by time estimate in a spreadsheet.

Screen Shot 2019-03-18 at 4.59.15 PM

My meeting with my developer was very constructive. My biggest learning is that I am possibly being “too detailed” in the wireframes that I am developing. That my intention is communicated more than I assumed. As I continue to build out my wireframes and annotations, I will work on being more strategic in my time and noticing what I can assume someone would know as standard from the Apple Human Interface Guidelines or other such guidelines.

I have estimated that it will take 198 days to build my app but imagine as I work to build out my last couple of flows that number will expand by a bit.

From Human Connections to System Change – Why I Design

Theory of Interaction Design and Social Entrepreneurship

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

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

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

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

Human Connections

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

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

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

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

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

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

Humans on the Internet

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

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

What this means for designers 

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

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

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





Chaos Theory
Dahlia Lithwick

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

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

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

Rethinking Business Plan Competitions
Michael Gordon, Daniela Papi-Thornton

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

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

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

Our Misguided Focus on Brand and User Experience
Jon Kolko

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

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

The High Line’s Next Balancing Act
Laura Bliss

Reflections on Gratitude
Richard Anderson

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

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

Yet Another Dilemma
Richard Anderson