Theory of Power in Design

Designers have power.
Good designers design to empower.
Good designers design positive disruptions.

With power comes responsibility.
Responsible designers are ethical.
Responsible designers remain engaged.

Power can be broken down into means of gaining power and forms of enforcing power. Organized money, people, and materials/represenations are means of power. (1) Forms of power include force, bargaining, and persuasion (2).

We began our readings focused on power with a historical analysis of the affect of French Colonization on Morrocan culture through redefining physical spaces in Assia Lamzah’s “Urban Design and Architecture in the service of Colonialism in Morocco. The ability of physical spaces to control a user is often overlooked as it is more nuanced than the digital interactions we discussed. While processing the Lamzah’s reading, in addition to additional papers she authored, I was compelled to apply this thinking to our own country and explore means of power in our own country.
402 Pres 2 power.005 Money: Check. The map illustrates GDP of countries around the world. The USA is in the top tier.
People: Check. Did you know the Department of Defense is the largest employer in the world?
Material Representation: Check. The closest millions of people around the world will get to the USA is one of our embassies; the vast majority look like prisons with armed gaurds, razor wire, and physical blockades. These embassies enforce an idea of hard-edge US power by playing on the emotions of individuals in the same vein as the Brian Cugelman discusses through examples of guilt of opting out of digital communications and services.

Good design exists in this realm: Look at the new American embassy in London. Instead of concrete blockades, there is water (known as a moat in earlier times). Security is accomplished through greenspace that the public can enjoy, creating an alluring public space.

402 Pres 2 power embassy.001

We were posed with the question: Are designers activists? When considering activism, protests are the first thing that comes to mind for many of us. Protests can be successful for inspiring change, but does change need to come through force? Is that how we want to affect change?  I believe good design creates an alternative to forceful activism. 402 Pres 2 power.010

In 1977, the Disability Rights protest broke records broke records and changed laws.  The ADA (Americans with Disabilities Act) passed; a huge victory! When  looking at this from a design perspective I see a shortcoming. The ADA defines otherness and often times design  accommodations simply emphasize this. The bigger design challenge is to create Universal Design.

Let’s look at OXO Good Grips line of kitchenwares. The line began when a businessman named Sam Farber watched his wife struggling with a vegetable peeler and set out to design a tool that was easy to use regardless of physical strength or dexterity. Today the line has grown far beyond a vegetable peeler and is a commercial success across all user types. When tools evolve its is an opportunity for users to become aware of challenges they may not otherwise have exposure or ability to empathize with.

402 Pres 2 power.016

I’ve discussed power through the lens of physical space, physical products, now lets take a look at behavior. In most bathrooms we arrive to the sink to wash our hands and are greeted with a number of designs to alert us to conserve water. I agree, we need to conserve water. We have a number  of different faucet designs that physically stop overuse of water. And then there are stickers that make us aware of the challenges others endure to obtain water: “would you use less water if you had to carry it….”

402 Pres 2 power.020

I visited the Denver Museum of Art last year and had a memorable hand washing experienceThinking about these designs relative to power made me zoom out and look at the larger task at hand. Sinks exist in bathrooms as a means to clean our hands. In the bathroom at the museum I stepped up to the sinks and music began playing, specifically “row, row, your boat” which may parents may know the time it takes to sing the song is the time it supposedly takes for hands to become appropriately clean (side note: these sinks were not excessively wasting water). Great design builds positive behaviors.

Designers make meaningful change in the world,  just as activism does. With the tools and techniques we’ve learned over the past 8 months at AC4D have empowered us to create change. Theory class is an essential component of our curriculum because with great power comes great responsibility.

402 Pres 2 power.022

402 Pres 2 power.023

Power means: Gecan, Michael. Going Public: An Organizer’s Guide to Citizen Action. New York: Anchor Books, 2004.

Power forms: Boulding, Kenneth E. Three Faces of Power. Thousand Oaks, CA: Sage, 1989.


Ally Bank: Mobile App Redesign Strategic Roadmap

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

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

Assignment 3_Design Strategy Feature Brief .001

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

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

Assignment 3_Design Strategy Feature Brief .004

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

Assignment 3_Design Strategy Feature Brief .005

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

Assignment 3_Design Strategy Feature Brief .010

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

Assignment 3_Design Strategy Feature Brief .016

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

Assignment 3_Design Strategy Feature Brief .018


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

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

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



Reflections on Building a Feature Brief

The Back Story

Over the last week and a half, my AC4D classmates and I learned about a communication tool called a feature brief. It is precisely what it sounds like, a living feature brief explanation of what the design is, use to share the design you put together with anyone and everyone involved in building a product. The intent of a feature brief is breadth, a high-level walkthrough of a product’s features, and why.

What is interesting is that there is an element of still storytelling and persuasion involved, to communicated the value my design could have given the insight I’ve found from user research. I found this to be the most challenging part of the assignment. However, as this is a student project, and a fast pace one at that, I did not have nor did I made the time to consider ‘what is the value of this app I am making?’, ‘why might someone find this valuable?’. So in the process of going back through I realized that the type of testing that was done in the past (user testing), was not robust enough for me to initially speak confidently about the features of this iOS Banking App I redesigned for UFCU. I found myself going back and forth through my past notes from research, past presentations on this project, and repeatedly asking myself ‘Why did I do this again?’

The effort was not fruitless, but it was something that took much combing through my documents and data to write something that I would feel confident and sincere about.

Why a Feature Brief

A product feature brief is most useful as a live document, that is curated for all partied involved in building a product, that is not familiar with the design of a particular product (i.e., legal, developers, marketing, sales, business, other design teams, etc.). I communicated what the thing is, why was it made, what it hopes to provide for the user and the progress of the project. By creating an actual document to share, you literally put into the hands of other an artifact that they can comment on, critique, provide feedback, or make design edits requests. It is a powerful tool for communications and co-creation. It also invites colleagues to become vested by contributing to the design.

Building a Feature Brief

The Slide Deck. I started with place holder slides in a presentation building tool (Keynote). It was easy enough to create the outline of a feature brief: overview, insights references for design decisions, a roadmap, features & their capabilities.

I started with the cut and dry content the roadmap and features & capabilities. The features &capabilities worked out to be the bulk of the slide deck. After all, this is a feature brief. While creating the features & capabilities slides, I would use two guiding ideas to determine how much detail to provide.

  1. Is this a core feature that enhances the user’s experience?
  2. Present a 50/50 ratio of ‘What’ the thing is, and ‘Why’ was it made for a person to use.

I completed as much as I can, and found that they ‘Why’ portion was left blank. To get to ‘why’ I designed the features as I did, I went back through 3 months worth of research, variations on builds, rewatching user interviews & testing recording, and hand-written user testing notes. Here are some of the more useful content that helped me with the Overview, and insight sections and recalling why I made the design decisions I did.

User goals found during user interview and testing.

Screen Shot 2019-04-08 at 6.48.11 PM

Research Result (Key Takeaways)

Screen Shot 2019-04-08 at 6.48.20 PMScreen Shot 2019-04-08 at 6.51.16 PM

Some design recommendations that contributed to design decisions.

Screen Shot 2019-04-08 at 6.48.30 PM Screen Shot 2019-04-08 at 6.48.39 PM Screen Shot 2019-04-08 at 6.48.46 PM



I want to share with you a PDF of all the re-research and feature brief build out.

University Federal Credit Union’s iOS Banking App Feature Brief.

Final Thoughts

Personally, when it comes to making anything, I often find myself that I often need to know WHY I am doing the thing I am doing. A huge reason why I’ve quit my job and when back to school to become an interaction designer was because I need to know the reason behind my efforts. Without a concrete product in hand, and people using it and providing real-time feedback it was so easy for me to become paralyzed every time I sat down and tried to put words to these features.

Key Takeaways.

1. Not having everything, is not the same as not having anything. Don’t be so quick to poorly judge the quality of all the work you have done so far when you can’t find all the answers you need immediately. I need to remember that I did have a reason in doing what I did so far, and need to go through all the foundational work I have done so far to remember the value I was trying to create for users.

2. Keep sharing reflections after every design stage. Presentations that include key takeaway, insights, and results are SUPER helpful to be able to keep track of all you did and why.

3. Adding slide numbers is the first thing you need to do when building a slide deck. After creating a clean feature brief that I was proud to share, and getting it printed, I found that forgot to add slide numbers for my audience to follow along! It was a bit painful to see considering how much attention to detail I paid to all other aspects of the brief. I’d imagine it would be what J. K. Rowling had published her first Harry Potter novel and found that they misspelled her name to be JK Rolling. All that effort and messing up on a small detail can affect the way your audience experiences what you made.

What I would do differently.

  • Include in my user testing, more robust interview questions to understand what makes a user tick, what they find valuable in the interaction I am designing. I would do this without any prototypes for them to play with so that I can learn about them, without the influence.
  • Maintain my research results, key takeaways after each phase of the process, user insights, and results from the process. It is a great way to track the work that has been done and why.
  • Work on connecting the features more to the insights. Try adding user research results to help sell the design idea.
  • Frame the brief in a way that it is easy to remember what the app does. (i.e. what is the goal? what is the problem to solve?)
  • Treat the roadmap less like a plan of action, and more of a rough estimation of the order of priorities.

dev school v2.

Good management is 360°—for the first half of the quarter, we tackled managing internal processes: How do we take a product (and a team) from concept to ship-ready artifact, on deadline? This week, we tackled the external-facing aspects of management: Showing, and selling, what we built to others.

A feature brief shares some things in common with a pitch deck: A successful feature brief will have a good value proposition, a clear mission, and viable ways to achieve it. Like a pitch deck, you’ll be showing people that there are users for this product; that you know something about what they need; and that the thing you’ve just built resolves this need.

But unlike a pitch deck, which is usually honed to a very particular audience, a feature brief is designed to translate to anyone, anywhere—so it needs a bit more technicality and “show me hows.” A good feature brief will share the high-level value of what your product is, and how it works. It should be equally compelling, understandable, and believable to the higher-ups in your own company and to a stranger on the street.

This week, we presented our feature briefs as printed and bound products. See my whole brief here.



Feature Briefing

This week we created feature briefs for our banking app. A feature brief is a document used by product managers to communicate their vision to internal stakeholders. The brief includes points from user research, the product’s value proposition, the product’s roadmap, and, the product’s capabilities.

Since our previous assignments provided the bulk of the brief’s features, most of the heavy lifting was already complete. However, creating a document that is appropriate for such a wide audience is no small task. With the audience in mind (as is always a good starting point when putting together documents meant for communication), I focused on the higher-level details that I believed would be relevant for teams other than design.

I started by editing and making higher fidelity digital artifacts. Once all the digital files were complete, I compiled everything using Keynote.

    1. Value Proposition –
  • We will provide a seamless mobile banking experience so that our customers don’t have to worry about accessing their financial accounts and can focus on living their life.

2. Insights –

  • Customers expect accuracy and convenience when they open their banking app.

  • Features that don’t add value to the customers’ banking experience hurt the bank’s relationship with those customers.

3. Roadmap –


The roadmap above was made in Adobe Illustrator. With the help of feedback from a mentor, I decided to present the information in 2 ways — as a Gant chart, and a stylized roadmap that shows individual elements to be completed by each of the 2 developers we have for this product.

4. Capabilities –

2 Credit Card Home Color

Above is an example of a higher-fidelity wireframe for the Credit Card Homescreen. From here, a customer can pay off their credit balance, set up recurring payments, view his/her transactions, open the budget tracker function, and access a help & support menu.

Ultimately, I want the audience to get the feeling that this product is well thought out and deserving of the resources needed to make it a reality.


Briefing Teams on Product Development

This week, in our Product Management course, we were tasked with creating a Feature Brief of our banking application. Essentially, a Feature Brief is meant to serve as a presentation of the product development process and plan for all teams involved. It is meant to coalesce various teams from marketing to design to development to legal around the plan for how a product will come into existence.

Part of this involves telling the story of why it will come into existence to ensure teams are onboard and on the same page about why we are creating this product.

As such, my Feature Brief was broken in to 3 parts:

  1. Insights – this section provided insights gathered from research which helped inform why my application is needed
  2. Roadmap – this section explains the plan for how  my application will come into existence at a high level, in a way that is applicable to most teams but not extremely directive to any
  3. Capabilities – this section outlines some of the core functionality of my application so that all teams can begin imagining app in its physical form and considering the mode by which they will be contributing to its development

I decided to develop my feature brief in Google Slides and then convert it to a PDF for presentation. For presentation in class, I printed and bound my Feature Brief. In all, it is 32 pages and you can view it here.

There were 4 steps involved in the creation of my brief.

Step 1: Find Out What Users Want

After working on my mobile application for nearly 3 months now, I have done two rounds of user interviews with 6 users each time. And, yet, as I set out to create this brief, I realized my interviews had been very specific to the flows I had been assigned. I was looking for specific feedback on features and screens within my application and had not been as interested in the usage of my application at large.

As a start, I decided to go back and listen to the recordings of the interviews I had held over the past couple of months. I found that often in the beginning of the interviews and a couple times throughout my participants revealed nuggets of their opinion about banking, banking specifically with Wells Fargo, and what a banking app “should do” (i.e. what features are most important). After pulling out these quotes and theming them, I was able to develop 4 core insights that help bolster my argument for creating an application and creating it in the way that I had:

  • There is a mistrust amongst the general public around banking with Wells Fargo that persists into the relationship that Wells Fargo account holders have with their bank
  • In their day-to-day interactions with their bank, Wells Fargo account holders are looking for unprovoked transparency to give them reassurance about their banking experience
  • Account holders want to know how much money is in their account, where it came from, and where it went
  • Account holders want to be able to easily move money, between accounts and into accounts (deposits)

If I had the foresight that I do now and time, I would certainly have conducted user testing in a different sequence and garnered different input from my users. At the beginning, I would have conducted interviews and contextual inquiry specifically focused on users experience at Wells Fargo, users experience banking in general, and what functionality was most desired in a banking app. Ideally then, I would be able to develop the flows which were most pertinent to users.

In this instance, we were assigned flows to develop. I imagine this is something that happens quite frequently in companies. If I had more time, at the point that I was assigned the flows, I would have conducted research to understand their value to a user before creating them to understand where they should fit into my concept map and how the information architecture should be developed. I would THEN conduct user testing on specific flows, screens, interactions, etc.

Step 2: Illustrating a Generalized Roadmap

For this assignment, I was assuming that Wells Fargo did not currently have a banking application (though they do). After identifying the insights that I did above, I explained the value of this solution to a user as a value proposition which read:

“This project will create a mobile application that allows account holders to have interaction with their bank at any time and in any place with ease.

It will supply them with the most necessary information they expect to get from their bank and allow them to complete the most essential tasks they would hope to complete on a desktop or during an average bank visit from the convenience of their mobile phone.”

The next step was outlining how the application would be developed. I did this by creating a generalized roadmap, which could be applied to multiple teams, of the application development.

After creating a roadmap for the developers who will be building my application a few weeks ago, I was able to work off of that to build my more generalized roadmap.


Drawing it out a few times first, I worked to create something that was complex enough to explain all that would go into the development of my app but simple enough to be applied across teams.

Step 3: Showing Off Capabilities

The next step was to illustrate some of the core capabilities of my app so that various teams could begin to imagine what the app will look like.

To do this, I highlighted various screens and called out some of the reasons I chose the functionality that I did which were aligned with the insights I used to create my app in the first place.

Screen Shot 2019-04-09 at 8.18.06 AM

This process was a tough one as I worked to balance the fidelity of the screens I was sharing with the amount of screens I was showing and content about each screen that I was sharing. Knowing that most likely other teams will want to see high fidelity screens, it was an interesting exercise in learning where to place time and value and how to tell the story of where you are at in the design process without being finished.

If I were to create my Feature Brief over again, I would have made some of the earlier screens I shared high fidelity and then told a story in my Feature Brief about why the others were still wireframes, addressing the timeline by which I hoped to have all the designs and UI complete.

Step 4: Making It A Physical Thing

After outlining some of the core capabilities of my app, my Feature Brief was complete and the intention was to present it to our class, as if they were members of teams being briefed on this app at Wells Fargo. For this, I converted my Google Slides presentation in to PDF format and printed it on a color printer.

After printing the first copy, I needed to tweak the positioning of some text boxes and color to allow for things to appear clearly and accurately on paper (even if they appeared clearly and accurately in their digital format). This took printing a couple copies before everything was presented as it should be.

A number of my classmates opted to have their Feature Briefs printed and bound professionally. I decided I did not want to do that because I wanted my brief to be a living document that people felt comfortable writing on and wanted to give it a less complete and polished feel so others would be more inclined to give feedback. Since this was my first Feature Brief, I knew there would be errors and missteps in my narrative.

That being said, I wanted my document to have the feel of something somewhat formal, as if I were actually presenting it. I decided to bind my pages with something called a screw post. A quick Google search revealed that they sold them at a number of stores in town and it was just a matter of going to one to get them. Unfortunately, the first store I visited was sold out. The second had enough to bind two packets, but not the 5 that Scott had asked. Walmart told me they did not sell them, even though I had seen differently online. I even found that there is something similar made called a sex bolt and awkwardly had to asked a customer service rep named Charles if they may have any of those, if they did not carry screw posts.

In the end, I spent my entire afternoon visiting four stores and ended up with enough screw posts for two bound packets. This was a big learning for me. Small details like how you choose to print out something for a physical presentation can be a big part of peoples perception of your content. Allocating enough time for the process of printing and creating your physical documents is really important. It may be worth it in the end to pay a company to print and bind something for you to save that time cobbling resources together.


Aspiration Design Brief: The Journey to User Success

This blog post update represents the culmination of our work in Designing Digital Interfaces and Product Management. For those of you who are new to the AC4D blog, this journey began when I selected a bank and redesigned its banking app to better serve users. I conducted user testing to improve usability and integrated financial modeling into my app design. Most recently, I met with a developer to estimate costs and created a road map to bring my design to fruition.

The design strategy feature brief pulls all of these pieces together. It is a concise overview that summarizes my product vision and articulates why the components that I have designed are valuable to the users. These documents are generally used with stakeholders to ensure that everyone is on the same page when moving forward with a design vision. Below I will walk you through the main pieces of my Aspiration design brief which can be read in its entirety here.

Aspiration is an online financial firm based in California which offers socially responsible banking products and services. This brief describes the journey to design the most intuitive, accessible, and fulfilling mobile experience for Aspiration users via the new Aspiration App. Following this roadmap will increase the wallet share of Aspiration by offering a fully functional app to complement existing online banking services.

The Aspiration app product design is grounded in these three behavioral insights:

IDSE401_Aspiration Design Brief_Page_04_smIDSE401_Aspiration Design Brief_Page_05_smIDSE401_Aspiration Design Brief_Page_06_sm

Based on these research insights, I crafted the below value promise for Aspiration users:

The Aspiration Promise

After aligning stakeholders through a shared value promise, I offered a roadmap by which we could achieve our vision together. At a high level, the roadmap overviews three main releases of the Aspiration App, with each new release delivering additional functionality and features.

IDSE401_Aspiration Design Brief_Page_08_sm

Click here to view the Aspiration Design Brief in its entirety.

Design Strategy Feature Brief for Balance Bank

After nearly 4 months of research, prototyping, user testing, and development sizing my mobile banking app is ready for a name and a few mock-ups. With the strategy brief we are turning our vision and product inside out, considering our stakeholders to be outside of the product team, with little knowledge about the details of what the team is building (Note for new blog readers: This is a conceptual client and team, we are creating these projects independently as students). The document is a simple report of vision. This is the first time I am being asked to be persuasive about my work so far. My goal is to convince the audience that the path forward looks like this and to help participate in the evolution of the product with the first, and future, releases.

The brief itself takes a similar structure to a pitch, perhaps a little less narrative and more structured and formulaic. I present behavioral insights from research, a value proposition based on what we heard in testing, a project roadmap that depicts how the team will achieve benchmark releases, and mock-ups of what the screens will look like.

Since I am delivering the brief to a hypothetical bank that is adding a mobile banking app to their digital experience, it is time for a name and a brand. I went with Balance, a brand that could strike a chord with users that want a desirable and user-centered banking life.


Behavioral Insights

Throughout user testing we conducted very technical click-throughs with participants. Luckily occasionally things would go off script or we would have a more insightful discussion about their relationship with finance and banking in their lives. I went back through some of the introductions of my interviews and found some quotes that, when synthesized, cobbled together latent fears and hopes that bank customers shared. 03_Insight 1 04_Insight 2 05_Insight 3

I interpreted that participants were telling me that they all acknowledge that banking can live in our hands while we pass through the world, but that the relationship they foster—or don’t—with their apps, by habit can be compelling or compulsive.

06_UVP Copy


If you look back to last week in the AC4D blogs you will see a plethora of reflection and documentation of product roadmaps. We created those versions with out team in mind. We wanted everyone to understand their role and how best to fit into the agile team for this app release. I cleaned these roadmaps up for the brief.

08_Roadmap Written Copy

Product Mock-ups

Because our course has been heavily wireframe focused it didn’t leave me much time over the last week to turn my 100+ screens into beautiful colorful mock-ups. I don’t think it is common for a strategy brief to refer to detailed design process. But I felt the need to show a couple flows of wireframes to communicated all of the capabilities of the features I would be demonstrating. In this case I did include a page that primes the audience to understand wireframes and their iterative value with the higher-fidelity mock-ups.

Mockup Copy


Describing the essential purpose of each capability with a screen and a brief description was difficult for me. I am not sure if I was successful at communicating the value of the design decisions I made. But for the sake of absorbability I had to cut down all of my detailed work into single pages.

18_Sign in screen Copy 20_accounts view screen copy 22_Transfer within screens Copy 24_deposit screens copy 26_Zelle Screen Copy 28_Menu Copy


Glimpse of The Future

A sign in and a deposit feature and a transfer feature and a menu and a payment feature all have to exist before you can chase down the parts of your vision that differentiate Balance Mobile from other banking apps. That’s why the closing page of the document primes the audience for what is to come, and that is a financial modeling feature aimed to build compelling human centered tools for financial well-being.

29_future copy


This has been one of the very few times I’ve put significant time into a printing project. I dedicated a certain amount to each page looking quality, I always find that they print differently than I expect.

This process was a good way to reflect on the effort and tools I learned along the way to creating the brief and the project itself. It took a moment for me to believe I could create something cohesive out of the fast-paced making of the last 4 months.

Thanks for reading along!

I will leave a link to the full PDF here.



PUNC Bank: Strategy Feature Brief

To unite multiple stakeholders and teams on a vision of our PUNC Mobile Money banking app, I’ve created a strategy feature brief. After months of designing the application, testing with users, meeting with a developer, and creating a product roadmap, now it is time to compile all of the pieces into a compelling brief illustrating the value we will deliver and how we will do it. You can find the full strategy brief here.

Three main behavioral insights guided our design:

  1. We live in a fast-paced, mobile world. People expect their banking experience to keep up.
  2. Banking is a necessity for our customers, not a leisure activity.
  3. While customers need convenience for small banking tasks, they fear making hasty decisions for high impact tasks.

People want convenience and access to do basic banking activities, such as depositing checks and paying friends. However, when it comes to dealing with investments or changing retirement plans and other high-impact tasks, people desire more friction to achieve these goals so to have time to consider the repercussions.

“If I’m going to mess with my nest egg, I want to be sitting down with my laptop thinking about it. I don’t want to be on a bus, just moving stuff like that around.” -Braden

Additionally, our users wanted clear, jargon free language. Our customers felt tricked or confused when complex banking jargon was presented and often they would avoid tasks that included this. Users also avoided tasks that required knowing information that was not common knowledge or easily accessible. For instance, if they needed to know a friend’s bank or account number or routing number to transfer money, they reacted negatively and verbalized that they would find an alternative route. At PUNC Bank, we are committed to making banking approachable.

Feature Brief - Banking App

Those behavioral insights not only drive our value promise, but our designs and our roadmap to delivery as well. As seen below, our high level roadmap makes sure that users will be able first access the functions they need to monitor their accounts, then to complete small impact tasks, then features that help them develop financial understanding and healthy habits.


In addition to the high level strategic roadmap, I also included a more detailed strategic roadmap, depicting the breakdown of each phase into the flows by developer and showing our weekly schedule. This helps everyone understand the order of delivery to our customers. It is followed by the feature overview or capability breakdown, which helps illustrate what each of these features actually looks like.

detailed roadmap

The feature overview followed the same three major sections as seen above: Monitor Accounts, Small Impact Tasks, and Healthy Habits. Each major segment consisted of at least one or two key screens, with a description, and short breakdown of functionality as shown in the examples below. This will allow all team members to get a quick glance at what will be in the application, how it will operate, and what value that will be giving our customers. To see all of the features, please check out the full brief here.

accounts view

pay a friend

spending budget

The strategy feature brief is for anyone to pick up and understand what we are doing with the PUNC Mobile Money app and why. It illustrates the high level strategic roadmap depicting clumps of functionality as well as a detailed roadmap showing the breakdown of flows between two developers and over a specific timeline. The feature overview shows exactly how we will be delivering our value promise through a look at key screens throughout the app. All of these designs ultimately hinge on our behavioral insights derived from the users themselves, which makes sure that as a team at PUNC Bank we are always serving our users.

Failure is hard, sharing it is good

Since our last update…

  • We met and discussed the feedback from our presentation last week and further defined our success metrics.
  • We posted a personal and current story of failure to Instagram stories and over half of our followers viewed it to the end and we got several positive responses.
  • From that story we gained a few new insights, primarily that knowing that failure is a part of success does not lessen the pain of a perceived failure. Only in sharing that story with others does the pain lessen.
  • Lastly, we sent out our first newsletter introducing ourselves and our mission and promoting our next dinner. And within hours we had 2 more people sign up!

Lessons Learned:

  • From our presentation feedback we learned that our stories from the field don’t connect with the ATX Fail Club offerings as well as we thought they did. That is a narrative we’ll have to work on over the next 3 weeks.
  • Our high-risk assumptions and ways to test those assumptions are too generic and we need to look closer at defining the values our participants will be getting out of this particular solution.

Our Next Big Questions:

Can we get sponsors to cover 75% of the costs of the dinner? And believe in the mission enough to want to sustain it?

What other channels can we create to help people share their failures in the moment vs. waiting for a dinner?

Now we’ve got to…

  • Focus on ticket sales/promotion on the next dinner as it’s 2 weeks away
  • Continue recruiting sponsors
  • Identify potential magic moments, and create a method for integrating them into our pilot for testing
  • Look into what other parts of the Failureverse can we pilot now, alongside the dinner

One way you can help right now is…