Power: archetype diagram

Our second assignment for Theory in Q4 was about power. We had 5 reading (listed at the bottom of this post) that talked about power dynamics relating to work, culture, and our roles within.  Our assignment was to create an artifact to illustrate our thinking on the topic.

I started by abstracting ideas from the readings based on different roles: those holding on to power, those empowering others, those giving up their power. For each of the readings, I wrote my take-away for each role.

20160404_004153 copy

If you try to hold onto your own power

  • work goes slower, is inefficient
  • you fall into routine and become irrelevant
  • you’re putting shit in the world that only serves your personal gain
  • you work in an echo chamber and have to convince everyone you’re right
  • you can kill a culture

If you empower others

  • work is more efficient
  • you have to continue innovating and not fall into routine
  • your work is more meaningful in people’s lives (but also harder)
  • creative abrasion (more people, more ideas) leads to stronger ideas
  • respect people by giving them more opportunity or visibility because you’re there

If you give into the demands of those in power

  • work is boring and stifling
  • you’re part of the capitalist routine. can’t be innovative.
  • you’re just using something the way it was designed
  • someone else will make all the decisions
  • you let your culture die

Creative abrasion from Design Thinking and How It Will Change Management Education
Dunne, Martin was pretty inspiring to me in this project. The idea is that hearing more opinions, even challenging ones, can make arguments stronger and can lead to better performance. Diversity, in other words. It’s easy to fall in line with people who are like you: who think like you, look like you. It’s easy in another way to parrot people around us to fit in. It’s pretty vulnerable to dissent to those around you, or admit that you might be wrong.  If we’re open to it, positive change can come from considering opinions that oppose your beliefs.

People who are “different–” like, say.. women– haven’t always had the opportunity or the agency to voice their beliefs publicly and be taken seriously. The internet has opened up lines of communication, creating safe spaces for those seen as minorities in our society to talk freely about their lives. It’s wonderful that people have those spaces to speak, but these voices are getting very loud in closed off rooms. The echo chamber of social media keeps us all in bubbles, where we think real change is happening because all the people around us are talking at the same change, but the larger conversation is much slower to adapt.

In comes Bubblr: a [fictional] tool to break out of your social media bubble by finding people that you’re connected to in some way (industry, location, etc) but that are ideologically different.


I looked at archetypes of people I see as having an incentive to use social media actively and why. Then, I created a diagram to represent how they would disseminate information differently with Bubblr. For example, an activist might use Bubblr to strengthen her narrative and find allies who might just have been turned off by the language of her message before. A marketer might use Bubblr to find new markets. While “marketing” can have a predatory connotation, people can really benefit from products and services. If a marketer is listening back to what people are saying, they may be able to make a impact on people’s lives in a  more direct and meaningful way.

The real impact in this model is with the Passerby:Screen Shot 2016-04-05 at 6.14.59 AM

These are average social media users who are being engaged with by active Bubblr users who are commenting, following, or liking what they’re saying. Just having that interaction will cause people to look at their new followers profiles, and maybe think about what they have to say.

I am aware that this is a pretty sunny take on what can happen when people with opposing ideologies come together. Conflicts can have pretty dramatic consequences. They can also teach us a lot. If we’re just carrying on our path, being agreeable, we might be squandering our potential for change. We shouldn’t let what is working for others be the default, because it reinforces their power and undermines our own.



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

Innovation and Entrepreneurship: Schumpeter Revisited
John Hagedoorn

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

Jon Kolko

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


The Emperor Has a Supportive Set of Undergarments

Sophie and I have been working on Openly since our pivot from Quarter 3.

We have our story:

Screen Shot 2016-04-05 at 4.59.50 AM

We all have an ideal relationship in our heads, the seed of which starts in childhood, where we’re all told fairy tales of finding Prince Charming or some princess who chills with animals all day.

Screen Shot 2016-04-05 at 4.59.26 AM

There are a ton of apps out there that claim they can find us a perfect match, but no one is perfect. Real relationships don’t have a happily ever after. There are all sorts of disagreements that we’ve got to work on. Openly is an app to create stronger relationships through communication.

Screen Shot 2016-04-05 at 5.03.57 AM

But it feels a little bit like we’re “happily ever after”-ing our own app.

We don’t have complete set of wireframes.

We’re building them in conjunction with a business plan, and it feels unstable. We can only predict so far what might be a plausible business model for this app. We’re realizing that we have to get comfortable with the ambiguity here, and just put our thoughts forward. We’ve looked into partnerships, subscription models, app-store purchases… We’ve just got to pick the one that makes the most sense and play it out.

Our focus right now has to be on developing a really great product.  This week we are completing our wireframes: building a version of every screen built out so that we can get it in front of people to user test. I know that being able to see people interact with our product will make us a lot more secure in the stories that we’re telling. This emperor is ready to put on some pants.

Q3 The Elephant in The Room

This quarter, our team took what we learned in research and decided what problem we wanted to tackle. We saw over and over again, that our research participants struggled to address problems in their lives. They avoid talking about it, trying to suppress and control their emotions until they couldn’t anymore.

Screen Shot 2016-02-28 at 2.22.15 PM

Screen Shot 2016-02-28 at 2.21.58 PMI know a lot of us struggle to understand the best way to handle disagreements, especially with the people we’re closest to. This type of problem solving isn’t taught in school. We found some people who seek out counseling to learn how to have more productive relationships, but most avoided talking about negative feelings, maybe opening up an incognito browser and searching for “yelled at my sister, how do i fix it?” When people avoid confrontation because they fear losing control, they’re losing more by not addressing their frustrations. They’re losing time with the people they love. They’re losing the chance to build the life they want, and they’re losing their temper trying so hard to control their emotions.

Screen Shot 2016-02-28 at 2.22.34 PM

We created Elephant in the Room, an app that seeks to turn uncomfortable conversations into a chance to build deeper relationships.

Our program guides self-reflection, which helps users address the problems in their lives with more confidence.


We don’t seek to “solve” all personal conflict because… we don’t know what “solved” is. One person’s “solved” is another person’s “unacceptable.” Instead, we want to foster an environment of responsibility and understanding in relationships. We have been working to create something that’s playful, where the user feels like they’re making progress, and understanding the process without have to learn a bunch of “conflict resolution” jargon.  

Screen Shot 2016-02-28 at 2.23.02 PM

The app works by using a series of questions to prompt self-reflection about how you’re feeling and how the other person might be feeling. These reflections build on one another to create a guided practice that reframes what the user has entered in the self-reflection sections, and has them read back what they see onscreen to practice articulating their feelings. It gives users a plan for starting the conversation they’ve been avoiding. This moment was always stuck out during user testing, as if people’s feelings were being validated by the app.

Screen Shot 2016-02-28 at 2.23.20 PM

We know that not everyone will search to find an app to address their elephants. But, we know that people do seek help. Many of our participants have been to therapy. We know that people use tools to help them articulate what they’re feeling. One woman that we tested with used a “conflict wheel’ she got from church and was heartbroken to find she had lost it while in an argument with her mom. Next quarter, we plan to talk to counselors, therapists, and people who teach conflict resolution to get feedback and really focus on where this app would fit in the landscape.

Screen Shot 2016-02-28 at 2.11.36 PM
We also want to break down all the functions and find ways to test them individually. We hope to understand what’s really working and streamline the experience. We look forward to sharing what we find.


Design Brief

chase roadmapparts-01


We were asked to create a Design Strategy Feature Brief for our wireframes. This document outlines the app we created, focusing on the value. Summarizing this project in this way made me a little nervous at first. I am now used to the process of working from research>insights>design>prototype, but since we didn’t research before starting these wireframes, we’d essentially be working backward and making up what would otherwise be the foundation of a design.

I recognize in myself a habit of getting caught in details when I don’t feel confident about the whole. I’ve been working on freeing myself from the need to qualify or justify what I’m saying (beyond being relatively consistent and logical). Note to self: It’s okay to be wrong. It’s okay not to know. Use the knowledge you do have to build from, and don’t get brought down by what you don’t know. 

As hard as it is to work backward to build insights from a thing, it gave me an endpoint. It allowed me to really pin down what I know about this bank app, which is that this thing exists as a set of wireframes: Screen Shot 2016-02-24 at 5.58.10 PM

I created it. I know why I made the decisions that I did when creating this thing. (Granted, some of them were based on the amount of time I had, but I still decided to make one thing over another for a reason.) For instance, why did I create alerts? Why did I create it in this way? Screen Shot 2016-02-24 at 5.59.46 PM

 Monthly bank statements are a good ritual for some, but others of us prefer to know when a problem occurs. Either because we want to deal with the problem right away, or because statements feel like work. Let me decide what I’d otherwise be scanning my statement for: small charges under a dollar, larger charges over $100, my paycheck or deposits over a certain amount, let me know when my bank account is under whatever amount makes sense for my budget. All of that offers transparency over a thing that is very much mine, as the account holder. This is my money, this is my ability to live the way I want to live, this is some part of my future. Too often banks force their account holders to be reactive about their finances. I don’t want to feel like the bank is controlling my money, controlling what I see of it and when, I want to feel in control.

As I went through the app, I noticed that the theme of autonomy and security ran through all of my decision making. I used those ideas to create my value statement:

Screen Shot 2016-02-24 at 6.03.29 PM

I integrated my old roadmap with my value statement to create a new roadmap and insights.


I used my insights to create a scenario that shows how a young nanny named Mia would use the app in her daily life.

Screen Shot 2016-02-24 at 6.04.18 PMScreen Shot 2016-02-24 at 6.04.28 PM

Screen Shot 2016-02-24 at 6.04.46 PM

I then returned to my wireframes to highlight the features of each capability.

Screen Shot 2016-02-24 at 6.05.21 PM

Download a PDF of my Design Strategy Feature Brief


This week’s assignment in the land of banking apps was to create a product roadmap. Roadmaps guide the development of a product’s components; they tell the product team when they should be building which part of a product, which means the product manager should think through why one component comes before another.

Here is my roadmap:Timeline-01

I broke up development into three releases. You may notice that the total amount of time for this banking app to be built is 36 days. I talked to two developers, who gave me comparable estimates for each component. Though that seems extremely quick for a banking app to be built, the screens I presented them with focused on an ideal state.

(Note: If I was actually building a banking app that would be accountable for keeping millions of customer’s finances safe, I would be heading back to the drawing board at this point. But this is hypothetical, so your money is safe!)


Below are the wireframes of the first release in it’s entirety:


The second phase focuses on payments:


At a glance, it may look as though the focus of this section is the “Alerts” feature, since it’s taking up more time. If you look below, at the breakdown of the “Payment” components, you’ll notice that most of this feature has already been built in the “Transfer” section. The logic left to build here focuses on the contact list, and sending money outside of the users’ account or bank.


In building these wireframes, I wanted to use as many native iOS UI features as possible, and try to only create new or different controls or components when absolutely necessary. My intent was to cut down on unnecessary changes that could result in confusion on the user’s end or redundancies in the code.

The final release is focused on creating a camera overlay for depositing checks:


The camera overlay was the single most time-consuming component on the roadmap. I was surprised by this, since I have seen this kind of feature fairly often.


I debated with myself for a while on whether to have a third release, or to have two releases, with a longer period for the second release. Ultimately, I decided on three releases. The overall time to build the app would not have changed much. I decided that having shorter deadlines with fewer components might be more motivating for the developers, and would allow us to get features out to our users sooner.



We’ve been working on making wireframes for a banking app since the beginning of Q2. To test our wireframes last quarter, we went out into the community to do the Think Aloud Protocol. This method of user testing has us present people we’ve just met with a prototype of our wireframes, and talk out loud while they complete a task. They simply tell us what they’re doing as they’re doing it, and we use what we learn to gain insight into the problems with the prototype.

Over the last few weeks, we’ve been using new methods: Cognitive Walkthrough and Heuristic Evaluation. Both methods rely on designers or experts looking at a design–in this case the banking app wireframes–to find instances where the design does not match an expectation of usability.

Cognitive Walkthrough focuses on learnability: how will a first time user learn the app? To determine this, I looked at a flow (a series of screens that represent a task from beginning to end) with a few classmates. The method is simple, you ask a series of questions and note any issues:

  1. Will the user try to achieve the right effect?
  2. Will the user notice that the correct action is available?
  3. Will the user associate the correct action with the effect that user is trying to achieve?
  4. If the correct action is performed, will the user see that progress is being made towards their goal?

This was a lot of words to remember. I focused on:

  1. Intent (Is it clear what the intent of this flow or screen is?)
  2. Visibility (Do I see the option I need?)
  3. Association (Do I associate the thing I need to do with the options available?)
  4. Feedback (Can I tell what’s happening? Where am I?)

Heuristic Evaluation was the second method we learned. This time, my classmates and I looked at individual screens to see how they compared to a series of heuristics (accepted techniques):

  1. Visibility of system status
  2. Match between system and the real world
  3. User control and freedom
  4. Consistency and standards
  5. Error prevention
  6. Recognition rather than recall
  7. Flexibility and efficiency of use
  8. Aesthetic and minimalist design
  9. Help users recognize, diagnose and recover from errors
  10. Help and documentation

Distilling these down, I recognized that these were techniques to make sure experienced users could understand and predict how the app worked. Do the users have control? Are the screens and actions consistent? Is the system efficient and allowing for the user to work efficiently?

Through the Heuristic Evaluation, I came to the realization that each individual heuristic is not equally important on each screen. For my budgeting flow, I was trying to fit to standards, visibility, and minimal language at the expense of recognition, and documentation. What does this thing do?

budget-08 budget-07


My last iteration relied on a curious user who wanted to click around and see what this feature did. That could be a pretty risky thing to do in a banking app. I for one, would like to understand the ramifications of my button-clicking before I click. If I set this saving goal, am I locked out of this money? Where does it go?

I’m early in the process of reworking my budgeting feature to give users more actionable information. That means this feature will have more instruction available than other features on the app, but most other features on the app rely on one-time user actions. Depositing a check, for example, only happens when you a get to deposit. It’s easier for a user to work through or start over if they’re working on something short. There’s nothing to monitor or keep up with once the check has cleared. Budgeting is a long-term interaction that requires users to actively keep up with their budgeting goals.

You may notice how different this Accounts screen looks from the one above. For one thing, it says “Accounts,” for another, it abandoned the Hamburger or side menu in favor of a tab bar at the bottom. I never had a problem during Think Aloud testing with anyone using the menu. What I realized when going through these new methods was that part of reason I was not having an issue is that I was using the navigation bar at the top in a way that is entirely inconsistent with the way it actually works in apps. The hamburger menu (those three lines in the top left corner) is not always visible. It gets replaced by a back button when a user moves into a flow. So, it was easier to use because it was always visible. What’s easier to use than an always visible hamburger? Always visible actions. The new tab bar is easier because it shows users the all of the actions they can take within the app. I became very aware of the inconsistencies in the app, and of how that was effecting the association the user would have with an action. In the screens below, it’s hard to see what the correct action is. On the right, we’ve got two different types of buttons that essentially do the same thing. If I want to create an alert about my balance, my eye might be drawn to “Balance on Checking…” rather than clicking on that small dark box that will actually take you to the correct screen.

New draft, based on new findings from the evaluation:

In reflecting on my experience using all three evaluation methods, I keep coming back to a mantra of writer and humorist John Hodgman: “Specificity is the soul of narrative.” I found that watching potential users test the app was great at letting me know that there was something weird about… something on a page. User testing let me outline what wasn’t working, but it was shadowy, imprecise, and in need of fair amounts of interpretation on my end. I had to come back to the wireframes and decide what to change and why. Cognitive Walkthrough and Heuristic Evaluation both garnered far more actionable feedback for me. They gave me specific problems, and told me why they were problems. I was able to see why people were getting frustrated with any particular screen, and have more of an internal map available for making and backing up design decisions.

One part of both Cognitive Walkthrough and Heuristic Evaluation felt weak to me: rating the severity and frequency of problems. I felt like I was guessing each time, and noticed my guesses getting less severe the more screens I looked at. In the future, I would like to substantiate the severity and frequency of problems with user testing. I think a large part of the shadowy feedback I was finding from users could be reinterpreted through the lens of “importance.” How irritating or limiting is this issue, and how often does it happen?

I’m excited to use both together. Learning these new methods, I feel like I have a ruler where before I had a stick. These new methods can give me a baseline of predictability and usability that can strengthen my work and my understanding of it, and Think Aloud testing can push my ideas into something more natural.

Evaluation PDF

System with problem areas highlighted

Communicating ideas

Where we left off last week, Sarah, Sophie and I had narrowed down the concepts we generated over break into a few storyboards and we had refined our design principles. This week, we continued generating concepts, as we each thought about what we wanted to work toward with this project. We know that we are working toward helping communication. Our research with second generation Asian Americans showed us some communication issues appearing over and over again:

-Communicating across language barriers and cultural expectations

-A desire to appear in control of their emotions, that keeps others at a distance



This week, we looked at a board game that prompts players to tell everyone what they would do in a given scenario. 20160116_090456Here, Molly is told that she’s stuck in the middle of New Mexico with a broken down car and a dying cell phone. She comes up with three different things that she would do in that situation, and her family talks out what they think she would do. 20160116_090504This gets families to talk about expectations and behavior without the pressure of a real life situation.


We had two ideas relating to a Family History Kit, that lets people investigate their family’s stories with prompts to ask family members about their experience. 20160116_090520One iteration shows Nathan sending a Mad-Lib style letter to his grandfather asking for a story about a favorite memory. 20160116_090528Nathan gets a letter back about his grandfather’s first job making watches. 20160116_090535Nathan sends a letter to his great aunt next to ask her about school.


20160116_090646In the other iteration, Christine asks her grandmother to tell her about where she’s from. They investigate maps together to guide questions about what life was like for Christine’s grandma growing up.


20160116_090700Our fourth scenario shows a dim-sum dinner with questions printed on a doily under the plates. For each dish someone receives, they get a new question that they are prompted to answer and discuss with the other people at the table.

We struggled this week with when and where to add to ideas and think about possibilities, or to scale back and think about essential functions. We’re continuing to ask ourselves how we can push these ideas into something any one of the people we interviewed might benefit from.

Wireframes: Final week



This was our last week to work on the banking app that we’ve been designing in our Rapid Ideation class this quarter. I worked toward cleaning up the flow for a user to check their budget and spending habits:


Budget [Recovered]-01 Budget [Recovered]-02 Budget [Recovered]-03

The user sees budgeting tools  on the main account screen, and tools specific to checking or savings accounts on their respective screens. Users are able to add budget goals:

Budget [Recovered]-04 Budget [Recovered]-05

and to visualize their monthly spending habits:

Budget [Recovered]-07


You might notice, if you try to follow the blue dots, that there are some steps missing. Leaving this flow unfinished is making me uneasy. That’s been the most difficult thing for me throughout this process: I’m not great at deciding to be finished. I want everything to be considered and I want everything to make sense. I’ve forced myself over the last couple of weeks to choose one thing to focus on furthering. If that one thing causes an avalanche elsewhere, I’ve tried to briefly give elsewhere some kind of support beam and come back to add structure when possible. It hasn’t always been possible. I know that’s a problem that plagues mobile apps, one that I would rather not contribute to. The next time I do something like this, I would build differently. I know my need to plan, but holing myself away to stare at diagrams is not the only way to plan. Next time, I would start building quick, broken, and diverse iterations for testing to see what kind of feedback would given for different types of navigation and structure. User testing has been a great tool to learn. It’s kind of amazing that people have such an intuitive sense of technology that they can figure out how to use these scribbles I put on paper. This budgeting addition has been really interesting. I don’t think it’s a thing that’s integrated into many (any?) banking apps. Giving people something unexpected has unlocked something in their brains and prompted some great ideas: “Can this tell me what I’m wasting money on?” “What’s this? Will it automatically save money for me?” I think I need to get out of my head faster and start making, so that I can dive in to making sense of something that is more than a theory.


That being said, these wireframes have come a long way toward clarity in just a few weeks.20151218_122957

Wireframes: Visualizing Spending Habits

Last week we were asked to add new functions to our app:

  1. Provide a snapshot of users finances and their trends.
  2. Allow users to analyze any transaction to see if it fits with their spending habits.
  3. Provide a modeling system for users to visualize how changes in spending impact their accounts.


I started by listing out what I believe people want to know about their money:

  • Where it’s going!
  • How much you will have at X time if your habits continue? If they change?
  • How to budget/save. Am I missing something? Do other people know something I don’t?
  • How long will it take to reach a spending goal


I spent a lot of time thinking (and doodling) about two questions:

  • How do I visualize financial trends and habits?
  • Where does any of this fit into the existing app?


I’m most familiar with this type of modeling through Mint. I use Mint, but I’ve always been a little confused by their use of donut charts. It’s like someone took a bar graph and looped it back on itself, like some kind of financial ouroboros. The circle is closed–which would imply something finite–but we all know that finances are always moving in one direction. Mint itself uses bar graphs for any comparison (spending habits in certain time frames, for instance). The only thing I could think that the donut graphs were valuable for was showing spending in certain categories relative to others. I started thinking about different ways that devices show usage. My phone, for instance, shows me [that I really need to clean out] my storage with a bar that has colors that correspond to types of files on the phone.Screen Shot 2015-12-15 at 2.14.02 AM

The more/larger the files of that type, the larger the bar. I could see this format being an effective comparison tool, especially if the bars were in order of largest to smallest. I played with this format, by orienting it vertically, and adding connectors that would show how the finances changed over the time period a user was looking at.


In my wireframe, I’m playing with how these comparisons are controlled and how they look. Some considerations I’m thinking about are: how large the smallest category has to be, if this is a fixed space or if it is built out in relation to that smallest category, if the “average” comparison is the default.


I’m also playing with all of the access points to these functions: How do people get there? I want these functions to be as integrated as possible into the existing framework. Below, you can see the changes I made to Accounts and Savings Account screens.


Budget Tools are now their own category on the main menu. Parts of the functionality are available on the accounts pages, with links back to the Budget Tools from the Payments screens as well.
I’m excited to continue testing and pushing the the new functions and visualizations over the next couple of days to be clearer and better fit the needs of the existing app.

Budget-01  Budget-02 Budget-03 Budget-04


Taking a step back to clear out the brush

I spent this week working on cleaning up and completing my wireframes. We were given a prompt last week to add some functions to the banking app we’re mocking up, and I wanted to spend time clearing out what’s unnecessary in the app as it is. That allowed me to spend time thinking about where in the app the new functions would make the most sense. I cleaned up most of my screens and highlighted dead ends by making the button leading to them red. An example are these screens with the option to edit Settings and Alerts:

Screen Shot 2015-12-10 at 4.45.37 PM

I have not built the Settings screen, nor the Edit Alerts screen yet, so I have highlighted both options. In my search through the app, I have been cleaning up existing flows, and making a master list of all the more major things I need to do. It’s nice to be able to take a step back and see what is missing. I feel like my forward momentum will be that much stronger in the final week because I’ve spent time clearing the brush away.

I feel like I have a lot of brush still to clear. I’ve learned a lot about building wireframes that I wish I knew going in (but I suppose, I will know next time!) I see now how helpful it is to make parts of the wireframes look like they would on an iphone (rounded corners, follow ios conventions)
I have been thinking a lot about where the newly assigned flows will fit into the framework of the app. We have to add features that “provide a snapshot of [users] finances and trends,” allow users to analyze any transaction to see how it fits into previous spending, and allow users to model how their accounts may be impacted over time by changes in their recurring payments. I see them available from account pages, with perhaps alerts available for specific patterns or payments.