A New Perspective: Understanding the Developer Approach

Introduction

Over the last two months, I’ve been working to create wireframes for a mobile banking app. Focused first on basic flows crucial to the core of a banking app and then adding on more in-depth features including budgeting tools. While creating these, I’ve put the designs out into the world of users and received feedback, which was then implemented to make the design better for our users.

Moving into the Product Management phase, however, meant a slight shift in design focus. Instead of being solely focused on designs that were great for the users, I now I had to make sure these designs were within our budget for development. To do this, I was paired with a developer to understand product sizing and evaluation. Sure, I know how long it would take me to mock up something in Sketch or XD, but I had no idea how long something would take to be coded and launched.

The Value of Meeting with a Developer

Meeting with developers is a crucial part of getting any digital design launched and the better communication you have with the developer the smoother the launching will go. I scheduled a meeting with Mark Phillip and began to prepare my wireframes for the meeting.

Meeting Preparation

Prior to meeting with Mark, I went back to my wireframes and made sure that I had updated my flows based on the last round of user feedback. Additionally, I decided to try out redlining my screens. As seen below, I first went through and redlined all of my features (as seen in Fig 1-2 below). I boxed them in red and wrote a brief explanation about what they were and how they functioned. After that, I went back through all the frames and outlined all of the controls and components and described how each of those functioned (see Fig 3-4). Lastly, I pulled all of the controls and key components out of the context of the wireframes and described their behavior individually (see Fig 5-6).

Fig 1. Redlining Features
Fig 1. Redlining Features – Home Screen

 

Fig 1 Relining Features
Fig 2. Relining Features – Account Balances

 

One thing that I would’ve done differently here, is talked to my developer prior to our meeting and asked for clarification around what exactly would help him best in the meeting to grasp the wireframes. If I had done that, I would’ve learned that he did not need to see the controls and components redlined (like in Fig 3-4), which would’ve saved me a lot of time. But he did like to see the components and controls taken out of the context of the wireframe and annotated (as seen in Fig 5-6).

Fig 3. Redlining Controls - Home Screen
Fig 3. Redlining Controls – Home Screen

 

Fig 4. Redlining Controls - Account Balances
Fig 4. Redlining Controls – Account Balances

 

Fig 5. Component and Control Breakdown
Fig 5. Component and Control Breakdown

 

Fig 6. Component and Control Breakdown pt2
Fig 6. Component and Control Breakdown pt2

Lastly, I ended up printing all of my redlined wireframes out and bringing them to the meeting. It was a lot of paper, but being able to make notes, redraw, and scratch things out right on the design quickly helped out meeting go smoothly.

To see the full redlined wireframes click on the links below:

Features

Controls

Controls Breakdown

During the Meeting

Mark was friendly and warm and understood well what were trying to accomplish in our meeting. We went through the wireframes by flow and discussed them screen by screen using the redlining Features section I had prepared.

As we went through, it was clear that he quickly grasped what the flows were and how the features and controls functioned. He asked questions when he needed it and the discussion illustrated a couple areas where I could add screens or move things around for clarity of flow.

During the meeting, he gave me an overall estimate for each flow and then I would prod him with questions regarding particular features or what he was thinking. I asked a lot of questions like “How did you get to the estimation? Could you break the timeline down for me?” and “What feature do you think would take the longest? Or how could we save some time or make this flow leaner?” He took all my questions in stride and offered explanations for which features he thought would take him the longest to build and we brainstormed some alternatives.

For example, one of my flows included a long form to manually add a payee for bill payment. I had designed it so that when a user finished page one they would then go on to page two, but Mark pointed out that would be extra time and that a scrolling form would shorter the development time.

Fig 7. Pay Bills Flow includes form for manually adding new payee. It includes two separate pages, but could just be a scrollable form.
Fig 7. Pay Bills Flow includes form for manually adding new payee. It includes two separate pages, but could just be a scrollable form.

 

At the end of the meeting, I inquired about what he normally likes to see in these types of meetings. He told me that a basic concept map of the architecture of the app would be helpful to understand how the pieces fit together and give him and overview so he can better understand where he is in the app as we go through wireframes.

Overall the meeting gave me a more holistic understanding of all the ways a project can be viewed. The majority of the meeting was me trying to understand how the developer is going to attack a problem and the developer trying to understand why we chose to design things the way we did. This understanding of the two sides is a crucial piece to implementing a cohesive product within budget that works for users.

After the Meeting

Upon returning from the meeting with the developer, I documented my learnings. I created and excel sheet breakdown of all the estimations that Mark gave me. I made sure to include notes on the features that would take the longest and why, so I can prioritize later about what should be included in our v1 of the app.

Walking away from the meeting, I have a new understanding of how developers approach a problem or a build and I have better grasp on how I can communicate and how I can prepare to get the most out of those interactions. My main takeaway from Mark was that the more that I, as a designer, can illustrate and articulate how something functions and why we chose that function, the easier it is going to be for the developer to understand the scope of work and give an accurate estimate. As Mark put it, “If I’m confused or scared by something or I’m not sure how it works, I’m going to give you a less accurate estimate because I want to make sure I have enough time to figure it out.”

The Estimation Results

Developer estimation for each flow
Fig 8. Developer estimation for each flow.

Detailed estimation can be found here.

To Consider Moving Forward

Several items within my app are time consuming for the developers and should be carefully considered moving forward. For instance, I had included a Recurring Payment option in my Bill Pay flow. It’s the ability to automatically pay a particular bill at recurring times in the future, basically scheduling them out at particular intervals. This was problematic for the developer because of the amount of variables included, like daily, weekly, monthly payment options.

Fig 9. Pay Bill with recurring payment feature offered. A potentially costly addition.
Fig 9. Pay Bill with recurring payment feature offered. A potentially costly addition.

 

Another feature to change in my wireframes is the numeric keypad. I need to a little digging to find a standard Andriod numeric keypad for the wireframes. From working with the developer, I learned that many standard features are much faster for them to include because the developer that copy the code for standard features instead of building a new keypad from scratch. This should be a relatively easy fix on my end that will allow the developer to work much quicker down the line.

Fig 10. Nonstandard Numeric Keypad will take much longer for developer to build instead of just including a standard Android keypad.
Fig 10. Nonstandard Numeric Keypad will take much longer for developer to build instead of just including a standard Android keypad.

Lastly, including all of the interstitial states that I had included for my users were completely unnecessary for the developer to see. Next time, I would only include enough so they understand the function and not every single screen for interstitial states.

Fig 11. Interstitial states were not necessary to show in developer meeting.
Fig 11. Interstitial states were not necessary to show in developer meeting.

 

Communication is key to these meetings. That includes preparing with redlining features, printing wireframes, or chatting with your developer prior to meeting to understand what would be best for them. It includes asking questions and having answers to developer’s questions during the meeting. And it includes documenting communications after the meeting and following up with the developer as the project progresses.

How to Finish Strong.

As we approach the final stretch of the AC4D intensive design program, here are our team’s reflections on how to finish strong.

5 Things to Keep Doing

  • Constant creation and iteration of low fidelity visuals: concept maps, product roadmap, etc. to make high fidelity versions.
  • Always be willing to get feedback and show your work even if it’s not finished.
  • Balance subjectivity and objectivity to develop insights.
  • Improve skills in visual storytelling.
  • Balance client relationships. Get paid. 

5 Things to Start Doing

  • Learn the fundamentals of product management and agile.
  • Learn how to piece together a product for high fidelity.
  • Pitch a vision that has tangible results.
  • Play to my strengths and personality.
  • Practice describing my niche as a designer verbally and written: “I’m a designer who utilizes social and emotional learning to design …”

5 Things to Stop Doing

  • stop- getting caught up in my weaknesses and spend my time toiling in them.
  • stop- stressing over self-created deadlines.
  • stop- Making an artifact digital without first making paper versions
  • stop- Attempting to learn every Q4 403 concept fully.
  • stop- shying away from asking stakeholders for compensation.

Where we want to be in 6 weeks

  • I want to be able to improve my ability to create coherent and engaging visuals that represent our product.
  • I want to be able to identify myself as one type of designer and explain it succinctly. And I want to have a badass portfolio in hand. I want to build a product that is adopted by an organization.
  • I want to increase my ability to de-risking an idea.
  • I want clarity on my perspective as a designer and what skill sets I bring to the table.
  • I want to prototype our product with at least two organization.
  • I want to be able to reflect on having balanced an academic experience, for myself, with creating a valuable deliverable to the community. [Sometimes I feel that those processes are at adds. Sometimes I sacrifice focusing on assignments and specifics to be able to push out a deliverable for a deadline for our capstone project. After graduation, I want to have learned the tool kit AND used it. Doing 1 and not the other doesn’t suffice. ]
  • I want our capstone project to be in the hands of the users, advisors. [As students, it feels odd asking for all of this attention from our local partners for something they didn’t exactly ask for in the first place, a group of designers getting really deep into their work.]

Student Reflections Three Quarters In.

Thoughts and Experiences from the Team

For the last seven months, classmates and I have been learning and using several tools to research the topic of college persistence among working students. Early on in the research process, we found several tools and methodologies foundational to help up with research and make sense of the data that we saw. Among them were a contextual inquiry/interviews, ethnographic research, concept maps, compelling storytelling, service slices, dissecting a system, talk aloud method, and semantic zooms. From this data, we developed several crucial insight of which we would use to inspire design ideas.
In a couple of brainstorming session, we used reframing methods and tools including a 2×2 diagram to decide on which design ideas we would like to build out. In building out these design solutions, we used techniques including storyboarding, mapping a user journey, service blueprint, lean canvases, theory of change canvases, and wireframing.
In the process of research, building prototypes, and testing out the ideas we have learned so much and gained some insights we’d like to share. In all this sharing of ideas and experiences, a foundational skill is to listen. But there is a difference between listening to respond and listening to understand. Most of us listen to respond, but by listening to understand we are better able to incorporate the needs, we heard into our design. Additionally, as we are building and testing out design ideas, we’ve found value in failing fast and early then iterating as a way to make sure we are developing the right solution for the audience.

FundEDU

We exist to create a world where working students have the option to prioritize school over work, because working students face a daily decision between financing living expenses, meeting academic requirements all while experiencing cognitive overload.

To do that, we need to answer the question:

  • Why do donors find giving to a financially burdened student valuable?
  • What drives people to donate?
  • What is the thinking that makes people donate one-time vs consistently (on a subscription model)?
  • How would students spend the money?
  • What would students spend that money on?
  • How do we measure and track the impact of a donation?
  • What would make a donor stop giving?
  • Who donors are more likely to give to?
  • Would students be willing to ask their social network for financial support?

So this week we will:

  • Conduct interviews with people who have donated to students, or in general
  • Refine our service blueprint for the ideal state.

In the Near Future

Our team project is called FundEDU, a platform to connect working students that are strained financially with donors. This platform attempts to help student persist in school by helping cognitively fatigued working students be able to focus on school.

For the future of FundEDU we hope by the end of April we would have worked rigorously to get FundEDU to a place where it could be pitched to the investor. After AC4D, our personal goals is to join the world of design as interaction designers at an agency and have the opportunity to sharpen the research, sense-making and creation skills we have learned.

Paving Our Path

To get closer to our goals for FundEDU we intend to work on the following between now and the end of April.

  • Find users and keep solution flexible; change it to fit user needs.
  • Use tools and methodologies learned to outline the user flow, components of the business and how it relates, create a prototype that can be taken to users and tested, reach out to the public to look for users.
  • Validate/learn, validate/learn, validate/learn.

Individually, we are focusing our energy to continue growing in the following areas and ability:

  • Form an opinion and insert it
  • Continuous learning about design and topics
  • Take responsibility for designs
  • Focus on the user’s experience — empathize
  • Keep larger context in mind as we create things for individuals to use
  • Keep asking ourselves why something should exist in the world

Reflections and Solidifying of Concepts

The capstone team of Sara Miller and Kelsey Greathouse spent the past week better defining our concept and business plan as well as reflecting on the past 3 quarters and how we may use our learnings from those quarters in this final quarter. Our concept is LaunchPad, an ongoing event and summer workshop series that supports teachers in making a transition out of teaching and into a new field.

Learnings and Reflections From the Past Three Quarters

In Quarter 1,

we learned…

  • How to synthesize disparate information
  • The application of design theory to design work
  • How to formulate and articulate a unique viewpoint
  • The importance of narrative to communicating a concept
  • To have courage to put ideas into the world and get feedback

…in the process, gaining the tools of…

  • Presentation
  • Sketch
  • Illustration
  • Recruiting
  • Contextual inquiry
  • User interviews
  • Transcription
  • Storyboarding
  • Theming

In Quarter 2,

We learned…

  • The value of working creatively with a team (melding ideas with people around you)
  • Systems thinking
  • Creative recruiting strategies
  • How to present project updates to a large audience
  • About and executed on the process of service design

…in the process, gaining the tools of…

  • Managing a client
  • Co-creation with a client
  • Storyboarding as a tool to communicate a design concept
  • Sketch
  • Product exploded view creation

In Quarter 3,

We learned…

  • The application of insights from research to a broader audience
  • Validation of demand by putting imperfect things into the world

…in the process, gaining the tools of…

  • Concept zooms, showing how a concept works in a larger ecosystem and when zoomed in
  • Rapid design concept creation, framing a problem
  • Pitching
  • Wireframing
  • Usertesting
  • Lo and high fidelity prototyping
  • Theory of Change
  • Lean Canvas
  • Forecasting
  • Business model creation
  • Market research
  • Landing pages

 

Vision for One Week After Graduation

After listing our learnings and laying out the tools in our toolbelt, our team was able to clarify where we want to be one week after the program, knowing our timeframe and our goals. In short, we hope to be able to clearly communicate our business concept and our plan for its development to any investor, partner, or user. But, not only do we want people to understand our concept, we want it to provoke and wow them.

 

We hope to do this by creating a narrative explaining our work on this project, a service blueprint, a business plan, a provocative demo, a tested MVP, an outreach campaign with measured results, and at least 2 confirmationations of investment or partnership. We hope to run a pilot of our product before the end of the school year. We are currently imagining that pilot to be an informative event for teachers on the first steps towards leaving the field.

 

In the next week, we will be creating artifacts that help tell our story, begin creating a landing page, and start getting the word out there about the event we will be creating as an MVP.

Our Concept and Pitch

As we mentioned before, our concept is LaunchPad. LaunchPad is a event and workshop series that supports the transition of teachers from transition into a new profession. As such, we created a short “elevator pitch” for our concept and where we are at in the development currently.

 

We exist to create a world where, people do not feel stuck in and feel empowered to pursue paths outside of their current career. In order to make that vision a reality, we’re creating a product that helps teachers transition out of teaching. To do that, we’re working to answer the question of what is the best solution to help them do that and what are the components of that solution. This week we’re going to ideate several formats that our solutions could take, define what components each format would have, compare each of those, validate, if needed, and choose a format.  

 

design from what you know.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

Blogging with Beers 🍻: Mapping our Learnings

It’s been quite the trip, but we’ve picked up a lot of tools and insights along the way. We’ve learned about human-centered design research and synthesis. We’ve also practiced sharing our insights with others through tools like concept models, zooms, and service blueprints. Last quarter, we explored methods of ideation like reframing and insight combination to come up with over a hundred novel design ideas to combat impostorism in women.

Jen, Vicky and I have a few insights and learnings to share with our many loyal AC4D blog readers:

    • Be yourself and do what you want. [Present findings that you find interesting and others will too. Don’t be afraid to insert your personality into presentations!]
    • Always maintain a bias toward action. [When in doubt, creating is better than not creating!]
    • Less is more. [#aintnobodygottimeforthat]

We’ve created a glorious vision for where we will surely be one week post-graduation. Please join us as we bask in the reality of it all:

joanna-szumska-661142-unsplash

We will each be fresh off our one-week minimum vacation to a tropical beach, and returning bright-eyed to a new role at a company we like with a team we’re excited to work with doing work we’ll be proud of. We’re excited about taking what we’ve learned and implementing change for the better at work and in all aspects of our lives.

To do this we will need to create a compelling portfolio and earmark time each week to set aside to work towards this goal. Building in time for critique and review will be beneficial and a great reason to reach out and learn from alumni, mentors, and the design community at large.

In addition to doing these things, we will also be expanding on the concept that came out of our research on impostorism in women. We are doing this because…

We exist to create a world where women aren’t stymied by failure.

In order to make this vision a reality, we are reframing failure by designing an event series for women to come together and celebrate stories of failure. To do that, right now we’re answering the question of whether or not women are open to celebrating failure. So, this week we’re doing “think aloud” user testing to better understand reactions to our concept and messaging.

Join us: www.atxfailclub.com 🍻

4 Types of Fallacies in Social Impact Design

“Design is a conversation. Interaction design is the design of behavior, positioned as dialogue between a person and an artifact….Ultimately, it serves to affect behavioral change in participants.” “Conversation is only a metaphor for interaction, but it’s a useful one.” -Jon Kolko, “Our Misguided Focus on Brand and User Experience”

With conversations, we can change someone’s decision, opinion or behavior; a design can have the same influences (Kolko). The most insidious conversations or design are those that change behavior of participants but are based in an illogical, false or unsound premise; also called a fallacy. A fallacy occurs when the ideas of their argument might be arranged in a logical manner, but something they said isn’t quite right. The content is wrong. In the same way, a design solution is built with an intent that seems right, but the outcome (the content) is wrong. If the design solution does not produce positive behavioral change, then it is a fallacy (What’s a fallacy? See bottom of page).

Here is a list of some common design fallacies that I have seen in Social Impact Designs

  1. Tech-chauvinism: When a design assumes that technology fixes everything. Example: Uber for Shelters.
  2. Empty Promise: When momentum for an idea builds but doesn’t amount to traction or impact. Example: Business plans competitions
  3. Slactivism: When a design idea mistakes consumerism for impact. Example: Product(RED)
  4. Thwarted Intention: When an idea is designed for the community instead of with the community. The final design is used in a different way than originally intended. Example: Highline Park, NY

Why it’s useful to identify fallacies?

Understanding the nuance of these patterns seen in social impact design, will then allow you to quickly identify the pattern, poke holes in the concept and then create an informed opinion. Also, it can be used to critique one’s own designs.

How do designers prevent fallacies?

Ultimately, we can’t. We are fallible humans. One thing we can do is course correct. The most important way to keep a social impact design accountable is to create metrics, measure impact, identify short-comings and iterate. “You can’t manage what you can’t measure.”


 

What is a fallacy? Here is a quick rhetoric lesson.  A logical fallacy is an error in reasoning common enough to warrant a fancy name. Knowing how to spot and identify fallacies is a priceless skill. It can save you time, money, and personal dignity.  One common fallacy is called:

“Slippery Slope”: when an argument starts with a seemingly benign premise or starting point and working through a number of small steps to an improbable extreme.

Example: The unsound argument of a teenager to their parent.  “But, you have to let me go to the party! If I don’t go to the party, I’ll be a loser with no friends. Next thing you know I’ll end up alone and jobless living in your basement when I’m 30!” This parent should not be swayed by this emotional appeal because it is not a valid argument.

 


 

 

 

Responsibility in Design

 

Evaluation of outcome, not product

We’ve been discussing a variety of topics in our theory course, Theory of Interaction Design + Social Entrepreneurship, taught by Richard Anderson, related to the value of social impact, the role of design in “saving the world,” the factors that drive the desire to do good, and the role of good intentions in designing products, services, and systems for social change. Throughout the texts we’ve discusses, what resonates most strongly with me is the collective responsibility of design + social innovation, and what practices we should adhere to in order to predict, shape, and address the outcomes of our products and designs.

IDSE402_theory_assignment 1 - good bad.001

We tend to think of products (or designs, initiatives, inventions, etc.) as good or bad. But products themselves are merely instruments that have no intrinsic value. It’s the application of the products and the outcomes of their implementation and use that matter, and which are open for evaluation. Those outcomes always involve tradeoffs – someone (or something) benefits, and someone (or something) suffers.

A specific theme that I keep coming back to is the idea of intention vs. outcome –  not within the dichotomy of good vs. bad, but the idea that small creations or designs have the potential for massive social change, while some very big ideas never catch on. Combined with this notion is the thought that things that cause huge shifts in culture often have both positive and negative outcomes for society (depending on your own moral compass). Many authors of culture-shifting designs have looked back on their creations with regret. As I enter the design profession, I want to consider both the impact of the things that I’m helping to create, as well as to ensure those things don’t cause more harm than good.

To help me make sense of this idea, I started to create a list of specific products, inventions, and initiatives both from our course readings and from recent history and to map the relationship between their intended scope of innovation and their actual effect on global change. For the purposes of this exercise I mapped the following 11 creations which you can see in the 2 x 2 matrix below:

IDSE402_theory_assignment 1-chart with numbers

  1. Nuclear power – as an electricity-generating source, nuclear power is up for debate in terms of good vs. bad, but the advancements in science that led to nuclear power also led to the atomic bomb, which undeniably had radically destructive effects. For the purposes of this mapping exercise, nuclear power was intended to create change, and did so in many ways.
  2.  Automatic weapons – An obvious upgrade from single-shot guns, automatic weapons have been widely adopted, causing huge cultural change. Unlike single-shot weapons, which have uses other than warfare (such as hunting), automatic weapons, in my opinion, have only caused extreme harm for humanity.
  3. The World Wide Web – When Tim Berners-Lee proposed the information management system that would become the World Wide Web, he couldn’t have predicted the radical change it would bring to the world, ushering in the Information Age. Are we swimming in the freedom of unlimited information at our fingertips or drowning in a sea of noise?
  4. Plastic – This low-cost innovation to traditional materials has so radically permeated human lives, that it exists in everything from toothbrushes to spacecraft. Perhaps the hardest dichotomy for me to reconcile, plastics are responsible for all manner of medical, technological, and structural advancements, and yet due to their non-biodegradable qualities, have simultaneously caused much of the massive environmental destruction of our planet (which I doubt we will be able to recover from).
  5. K-cups – Inventor John Sylan was trying to solve a common office problem of stale coffee at the communal coffeepot with these encapsulated individual servings, and had no intention of contributing so drastically to the environmental nightmare caused by their inability to be recycled.
  6. Cameras in mobile phones – Added as a feature to cell phones in the mid-2000s, these mobile cameras democratized photography. Coupled with widespread use of the internet, cameras on phones have made everyone a photographer, in turn causing effects that range from the rise of social media (and its impact on culture) to the near elimination of photojournalism as a profession.
  7. Apps to solve homelessness – Always an epic fail. “There’s an app for that” doesn’t apply to solving wicked problems.
  8. The San Francisco SPCA Knightscope security robot – This robot was used in 2017 to police the premises of the SF SPCA, with a debated intention to remove nearby homeless people. Not long in use, it was an expensive and hostile band-aid solution to a systemic problem.
  9. #metoo – Tarana Burke, a social activist, began using the phrase “me too” in 2006 to draw attention to sexual harrasment and sexual assult. But it was in 2017, when the hashtag was used and promoted on Twitter by Alyssa Milano in the wake of the Harvey Weinstein sexual harassment allegations, that it drew awareness to widespread (and often not talked about) experiences of sexual harassment and assault. This is a compelling example to me of something that started extremely small, but catalyzed an entire movement aimed to change social norms and behaviors.
  10. Product Red – a licensed brand as part of a business model that raises money from the purchase of consumer goods to fund efforts to eliminate AIDS in certain African countries. Although the company claims to have raised millions of dollars and to have impacted more than 140 million lives, it’s difficult to determine how much widespread change this consumer activism has affected.
  11. The keytar – Is it a keyboard? Is it a guitar? It’s…a keyboard with a neck strap. And it didn’t end up being the great music industry disruptor that Edgar Winter might have wished for.

edgar winters

Designer responsibilities

To ensure that we create more beneficial impact than negative impact, it’s important to keep in mind 3 guiding principles of responsibility:

IDSE402_theory_assignment 1-responsibilities.001

As designers, we should speculate on potential future outcomes of our design projects. The most important questions we can ask ourselves are who will benefit from this design? and who will suffer because of it? When we actually take the time to map out the potential future state(s) of the ecosystem affected by our design, we can start to identify and keep in mind areas where problems or negative effects will occur, and then weigh those effects against our own moral compass to make sure we want to take responsibility for putting those designs into the world.

We also need to involve as many people who will be affected by our designs in the design process. This means not only researching within the community that will be using or affected by our designs, but also keeping community members involved in the creation and testing process. It’s important to understand not just the infrastructure around our proposed design, but also the behaviors and belief systems of the individuals that will be impacted.

Lastly, once our designs are out in the world, we need to evaluate how those designs are affecting the communities within which they exist. Did the design have the intended consequences? Who is benefitting from the design? Who is at a disadvantage because of it? It’s vital to both address negative consequences in the living design and work towards improvement in that specific instance, as well as use any feedback to inform future design decisions in other projects.

Whether a designer works on something as seemingly banal as a camera feature in a cell phone, or as intentionally impactful as bringing clean water systems to rural India, there is potential for great cultural shifts, and with that comes great responsibility. By keeping future, current, and past states of our design in constant consideration and involving affected community members as much as possible, we can practice responsible design and stand behind what we put out in the world.

Water Planning with the Best Intentions

The last couple weeks in our theory class we’ve been reading articles chosen to fit the theme of “With the Best Intentions”. Many of these had examples of design projects that were created with the intention of “doing good”, but may actually have had questionable outcomes. This theme was especially engaging for me, because of my work experience in government. I commonly associate my work and intentions to align with “doing good”, and take a lot of pride in my work. For this reason, I found myself reflecting on how the author’s viewpoints might relate to my experiences and the work I do, as well as my future work as a designer.

The story I used to frame my learnings in my presentation was a brief overview of water planning in Texas. Click here to read a quick one pager on how the state does water planning then come back here to see how my takeaways from this process could be applied to not falling into the “but it was with good intentions” trap for future designers.

Require diverse stakeholder engagement.

Involving many different perspectives (sometimes conflicting) doesn’t always lead to a clear picture or easy solution, but it often provides a wealth of insights and a more meaningful picture than approaching a problem with a narrower lens. This is especially important when dealing with wicked problems, or working in the public sector because a designer may not be a part of the community they are designing for, or personally affected by the problem. Not only can this create blindspots in the design that lead to the benefit of one group over another, but also a solution that could be more heavily influenced by the market instead of lasting change for good. By involving stakeholders from a variety of backgrounds a project can benefit from the knowledge brought by all parties to collaborate and try something new that none may have been able to come up with on their own. Lastly, relying on a wide range of stakeholders will help normalize a solution and make it more accessible and dignified for all users.

Empower the community to get involved in identifying and solving their needs.

The readings this week showed that involving the community you are designing for is not always enough if you’re not asking the right questions. Sometimes, it’s not enough even if you are asking the right questions if they are not able to answer them well. I think this is often why we jump to technology as an answer, because it is so good at giving us information quickly when that isn’t always the case with people. We as designers need to take the time to work with communities to provide the tools and resources necessary to help them identify what needs may exist, and participate in the process of developing solutions.

Create long term goals with iterative tasks.

We also read and discussed the importance of focusing on designing solutions for the root cause of problems versus the symptoms. Some examples showed that immediate, localized, or small impacts don’t always solve the problem, but may just lessen a symptom of the problem. With wicked problems it can be difficult to know the root cause of a problem because everything is so intertwined and connected. Therefore, an approach that incorporates a long term goal and outlook with shorter term iterative tasks provides the best chance of success and the ability to “design with”. This is because it allows for ongoing adjustments based on learnings and developments as well as steady forward progress.

Have good intentions, do your best, and feel good about it.

This is more of my own personal takeaway from the readings. I can see why these articles are good for us to think about as designers, but I was perturbed by many of them. Particularly irksome were the readings that highlighted how “doing good” has become a huge selling point and private industry has been capitalizing on it to profit. I don’t in general believe that private industry can responsibly solve wicked problems because they are driven by profit as opposed to government or non-profit organizations. Despite good intentions, thinking of consumers is different than thinking of people. However, I think it’s very important for designers and everyone to approach problems and the world with good intentions, do their best, and not let the idea of “selfish altruism” get in their way. Yes, I get validation from “doing good”, but it also inspires me and drives me to continue working and striving to have a positive impact which I refuse to find fault in – especially if I am conscious to keep the above takeaways and other learnings in mind.

Why We Need Help Helping

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

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

This friendly Brit can help us understand these limits.

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

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

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

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

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

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

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

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

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