The goal of a product strategy and feature brief is to explain a product’s roadmap and the reasoning behind its creation so as to create alignment around the purpose and priority level of specific features. This is the document a product manager uses to convince her team, peers, and bosses that she has made the right decisions about which features should be shipped and when.
Insights and Value Promise
To create a product strategy and feature brief for my Velocity Credit Union (VCU) app, my first step was to elaborate on the reasoning behind my product roadmap. In other words, I did further research to ground the logic behind the order in which I chose to develop the VCU app features. The object of this exercise was not to complete the normal, extremely rigorous ethnographic research I would have preferred to have done to form insights, but rather to find secondary research that could help me form a cogent stance about which features should be prioritized.
What I found in doing secondary research was that credit unions everywhere are struggling to attract younger members. Younger members (people between the ages of 18 and 40) are extremely important to the health of any credit union because they are the ones most likely to be taking out loans to buy houses or cars, and credit unions make the majority of their money from the interest on the loans they give out. Consequently, I focused in on the behavior of millennials and how the VCU app could appeal to their needs. I then wrote then formed the following insights:
Those insights led to the Velocity Credit Union value promise: We promise to minimize our clients’ anxiety and frustration surrounding banking so that they are free to pursue their long-term financial goals.
This value promise addresses the expectations, emotions, and aspirations of the VCU members.
Having laid out that guiding principle, I then proceeded to create a high level strategic roadmap for building out the features of the VCU app.
The intent and goal of each release are different and driven by the insights listed above.
For the MVP of our product, the intent is to enable clients to never have to go to a physical VCU location to complete a common transaction, thus supporting their standard banking expectations.
For the v2 features (Automation), the intent is to enable clients to schedule transactions in advance and create repeated transactions. This will allow users to have a “set it and forget it” banking mentality, satisfying their desire to not have to be reminded about repetitive financial chores.
The goal of the v3 (Convenience) release of the VCU app is to support users to minimize the information they need to remember or find in order to complete their banking tasks. The goal of this release corresponds to the third insight listed above: millennials often do not keep track of the contact information of the individuals and businesses with whom they transact, and so often feel frustrated and lost when expected to recall or find details about them.
Finally, the goal of v4 (Safe to Spend) of the VCU app is to support users’ long-term financial health by enabling clients to live free from worry about overdrawing their accounts and build good savings habits. This release is designed specifically to address the concerns raised in the fourth insight listed above: Many low-income millennials fear over-drafting on their accounts to the point of preferring to deal completely in cash.
The final step in creating a product strategy and feature brief is to provide a more detailed explanation of each feature that explains the value it will deliver to customers and how it reflects the value promise for the product as a whole. Here are a few examples:
These more specific feature breakdowns conclude the product strategy and feature brief. You can view the brief in its entirety here.
Having reached the end of the brief, anyone reading it should now know exactly which features the product manager is proposing to build, why those features are critical to the value promise of the product as a whole, and why the features should be built on the schedule that the product manager has proposed. For the VCU app, this means that each feature has been justified and prioritized based on the behavioral insights listed above about the millennial users VCU is trying to attract. With that grounding, I, as product manager, would have a strong set of arguments with which to approach any higher-up to convince them to give funding and time to the features I have identified as being most important.
Reporters, satirists, and observers of all kinds have been commenting for years about the tendency to insert tech into situations for which we already have perfectly decent, cheap, analog solutions. From the Vessyl cup, which told you what liquid was inside it, to the $1,500 June Oven that figures out what food is placed inside it and (maybe, sometimes) cooks that food to perfection, technologists and businesses are putting a lot of effort into figuring out how recent advances in technology could improve every task we encounter in our lives.
And why wouldn’t they? Contrary to some thinkers out there, I don’t have a big problem with new products that seem like ridiculous, impractical, “smart” non-improvements of older products. New technologies almost never appear in highly usable forms right from the get-go. At Home, by Bill Bryson, shares a few particularly delightful examples of this historical tendency. For instance, Alice Vanderbilt (of those Vanderbilt’s) came dressed as an electric light to a costume ball in 1883 to celebrate that she had just had electricity installed at her Fifth Avenue home.
But she later had it all ripped out of the walls because it was suspected to have started a fire. Problems with early electricity were not isolated things: Franklin Pope, an inventor and former partner of Thomas Edison, accidentally electrocuted himself while working on the wiring of his own home in 1895. Nevertheless, the vast majority of people on earth today choose to live, work, and play in electrified environments, and there are a lot of compelling arguments for why this has genuinely improved their quality of life.
All of this is not to say that the Vessyl cup, June Oven, or (more sinisterly) the Alexa that is listening to all your conversations right now are not problematic. They are. But they’re also an inevitable byproduct of evolutions in technology or even stepping stones on the way to better applications of current technology. Just because they are not yet more useful or secure than older products doesn’t mean that future iterations one day won’t be.
As an aside, I think it’s dangerous to assume that everyone buying these “smart products” is a dupe suckered in by the siren song of ever more efficient tech. Early adopters are early adopters in part because they tend to fall in love with the idealized possibilities of new tech, and they want to be part of the change. Through their purchasing power, personal influence, and (now) data, they help to shape the future even if they do not invent new products. In other words, they’re valuing something else over efficiency or usability.
Thus endeth the aside.
My optimism aside, tech doesn’t get better by magic, and human history has shown us often enough that dystopian scenarios are very possible. As designers, we do have an obligation to try to craft a better world out of the mess of possibilities afforded us today by the burgeoning expansion of tech capabilities. So, how can we make that better world, and not just a useless Internet of Things piece of crap?
Certainly one starting point is recognizing the limitations created by existing cultural norms. Everyone from sci-fi writer Bruce Sterling to scholars such as Steve Rathje, Byron Good, and Deborah Gordon has pointed out that the realities of how current systems are constructed necessarily limit the lenses with which we view the world. Whether it’s medical reimbursement structures disincentivizing doctors from listening to patients, or current tastes among the reading public limiting what gets written, we all reside within structures that shape our every thought and decision. And so inequitable power structures recreate themselves again and again. All well and good. Given that, how does innovation happen anyway?
There are so many strategies out there. While I confess that Ray Kurzweil’s (and many other’s) idea of just changing humans themselves by replacing our current brains with some superior iteration (whether biological or not) holds a certain charm to me, that is a bit out of reach to this humble designer (at least this decade). That said, humans have been innovating forever using more mundane strategies. You can be inspired by the way things were done in the past, or the way they’re done in other cultures. You can imagine a Bizarro version of reality and then design something to fit that world. You can do any number of provocation strategies to deliberately force your mind to think differently about problems.
I tested out one of these strategies with my fellow AC4D classmates tonight: Worst Possible Idea.
Austin has famously bad traffic, and despite numerous efforts to fix this problem over the years, it is just getting worse. No one has had any particularly successful ideas about solving Austin’s traffic problem, so I thought I would ask my classmates to come up with some terrible ones. I presented my classmates with the following prompt:
And here are some of the ideas they came up with:
Roads drawn much more creatively (Maria Zub)
Though these ideas may not be the best ones out there, or even physically possible, they are innovative in that they break out of the current mold limiting what we often imagine as fixes to our traffic problems. And if we were to continue developing interventions to address the traffic situation in Austin, parts of these ideas, or the opposites of these ideas, or completely new ideas sparked by these weird ones could fall into that magical category of solutions that are both feasible and useful. Dystopian pieces of garbage on sticky notes or (to return to the beginning of this essay) in our homes can lead to more utopian futures. You just can’t stop at the first, second, or hundredth iteration of an idea. Radical innovation is not a thunderbolt, a scream of “Eureka!” from a full bathtub. It’s a process that takes years.
I don’t know how exactly the world will become a better, more equitable place. But I have an atheistic faith that it will, and that technology will be part of that transformation.
This week in Product Management, we took on the task of creating minimum viable product (MVP) versions of our banking apps and then creating a product roadmap planning how all the features for the full release of our banking apps would be built out.
The Purpose of the Thin-Slice Flow or MVP
First, a word on why we would even bother creating an MVP. MVPs are the leanest versions of your product that can still deliver value to users. Product managers are wise to have staged rollouts of versions of their products (from minimum viable product all the way to full release) for a few reasons. It enables them to begin to deliver value to users sooner. It decreases risks as the team has earlier opportunities to adjust their plans in response to user feedback and behavior. Finally, it can enable them to potentially start earning money months or years before the full vision of their product is built.
Creating My MVP
With all that in mind, I set out to figure out what the minimum viable product for my Velocity Credit Union app would be. The standard process for doing this is as follows:
Start with your idealized, fully built-out flows. In this case, I am using my Pay a Bill to a Saved Payee Flow as an example.
2. Eliminate (by literally x-ing them out) as many features as you can while still leaving something functional that delivers value to your user.
3. Create new visuals of your remaining flows with the eliminated features taken out.
My rationale for the pruning I did for my MVP was that I should retain only the most basic features one would expect to find on a banking app that would allow you to never actually have to go to the physical bank, such as checking your balance, depositing a check, paying a bill, transferring money, changing your password and contact information, and choosing how you would like to receive fraud alerts. These relatively few features cover most people’s most common banking needs. They do not include Person to Person transfers because I figured that most people will probably already have Venmo anyway. They also do not include options for planning ahead such as setting up recurring transfers or my Safe to Spend flows. Those sorts of financial-planning functions I left to later versions as you’ll see in my product roadmap below.
How to Build a Product Roadmap
Product roadmaps exist to create alignment around which features should be built when and by whom so that the whole product team knows the schedule for what is being worked on and when different versions will roll out. Though it is meant to be a living document (especially past the near future of the next 3 months), it helps everyone to have an idea of where the product is headed and what their priorities and daily tasks should be.
To create a product roadmap, I first took all my features and described them in greater detail so that someone other than myself could figure out the capabilities of each feature and the value they deliver to the customer.
Then, I placed all the features on cards sized according to how long my developers have estimated the features will take and arranged the cards in the order they should be created (according to the dictates of the company’s priorities and what made sense from a functional standpoint).
Next, I assigned each feature to be built to the resources that will create them (in this case, developers). For this part of the process, I prioritized releasing versions as quickly as possible, which meant that I made sure that the same developer was put in charge of creating similar features (such as two versions of calendars) since they would be better able to piggyback off of their own work than if the calendars were assigned to two separate developers.
Finally, I indicated when the key release milestones would occur.
Here is the roadmap as a whole:
As I stated above, my rationale for my MVP was to include all the most basic banking features, but omit most of the features that would allow someone to plan ahead or use Person to Person payments. Refer back to “Creating My MVP” for a longer explanation of my choices for this version.
For my version 2, I wanted to include more “set it and forget it” functionality. For instance, I included the features that allow for scheduling transactions in advance, recurring transactions, and setting alerts. These features deliver more value to the consumer by enabling them to not worry about their financial situation unless they receive an alert (they’ve created) telling them otherwise.
Version 3 of the VCU app allows for more convenience. Rather than switching out of their banking app and into Venmo, users would be able to use P to P to make financial transactions with friends while retaining transparency about how those transactions are affecting their balances. Version 3 also allows for smart searches among contacts and common bill payees and Touch ID sign-in.
Version 4: Full Release
Version 4 builds on the “set it and forget it” features first introduced in version 2 by adding the Safe to Spend and Ways to Save features. These features actively warn users about possible financial problems even if users have not taken the time to set up alerts. They also help the user create long-term spending and saving goals that increase the user’s odds of achieving better financial security. In other words, in the full release, users don’t have to look out for their own finances; the Velocity Credit Union app does it for them.
This exercise was interesting given all my conversations with product managers in the past few weeks. They all told me that past 3 months, one’s product roadmap starts to reflect reality less and less, and that past 6 months it amounts to essentially a wishlist. Applied to my own work, that would mean that only my MVP would fit within that window of a relatively predictable future. This is better than the alternative of my MVP straying into the murky, unpredictable future, but demonstrates to me how long (at least for a banking app) it takes to produce even the most basic functions. Thinking about the other project I am planning now, the KeyUp mobile app, this exercise has emphasized to me the need to pare down my expectations for what we will be able to create as an MVP. Reining in my completionist tendencies has never been my strong suit, but seeing the actual calendar for how long all these features would take certainly helps.
This week we were hard at work making beautiful design artifacts that communicate the vision of KeyUp to future friends and partners.
Service Blueprint process
A service blueprint is a visualization of the entire service first from the user perspective and then, all of the services that need to happen to support the user journey. Below, you can see the first draft of KeyUp’s blueprint.
As we’ve continued to develop KeyUp, the service has gotten more detailed. Below, you can see a draft of a second version of the blueprint. To create this, we started with color-coded sticky notes that symbolize the three main KeyUp users: a user who does not login, a user who logs in and doesn’t take the quiz, and a user who logs in and takes the quiz.
Finally, we digitized the second version of the blueprint. You can see our updated version below.
Customer Journey Map
Another asset we created this week was a customer journey map depicting the way people currently become enrolled in apprenticeships and certificate and associate’s degree programs. First we literally listed out all the steps involved. Then, we went back through our interview notes to find quotes from our participants that evoked the primary thoughts and questions associated with each stage. We also listed the primary emotions associated with each stage.
Most customer journey maps include steps, quotations, and emotions, but we thought ours needed another layer: an explanation of the most common reasons people give up at the various stages. The service we are creating now, KeyUp, is a direct response to what we heard from all the participants we have spoken with for months now: that it is incredibly difficult to transition out of a dead-end job into a training program that will enable you to get a better career. At every stage, young people face challenges, be it lack of knowledge about alternatives to their current situation, or a lack of resources to actually be able to afford school. To tell the story for why KeyUp is necessary, we needed to explain all the obstacles that KeyUp is designed to help people bypass.
As with most of our work, our first draft was done with sharpie and paper (see below), but we digitized a more polished version (also see below).
We spent some time going over our KeyUp hero flow in order to come up with the ideal journey of a KeyUp user, and represent how the system’s points of interaction look like as the user is going through them. To do this, we revisited the ways in which we’ll bring value to our users:
We connect young adults with training programs
We connect young adults with career opportunities
We make it easier for young adults to navigate the overwhelming waters of finding a suiting job on their own
We empower young adults to make educated decisions about the career path they want to pursue
We then developed the screens from the KeyUp app that represent these key value points, and translated them into a narrative. The story’s source of inspiration was the different statements or mindsets that some of the young adults that we talked to were in as it relates to information they look for when they are trying to find a job, as well as their employment situation at the time. You can see a draft view of the storyboard below:
The way storyboards in user experience design or interaction design differ from other types of storyboards is that we use this to clarify gaps in the flow of the journey, as well as cohesiveness around the User Interface design itself. This is why we try to provide the biggest amount of detail possible in the most succinct way, this becomes helpful when needing to identify key screens to show stakeholders as well. You can see a higher fidelity of the storyboard that we created below:
In the coming week, we will be continuing to build out more KeyUp flows. Check back next week to see them!
The above is the most common ending to my design theory choose-your-own-adventure book, “The Bathroom of the Future.” If there is one thing our latest readings for Theory of Interaction Design emphasized this past week, it is that the path of the ethical designer is not a clear or easy one, especially if you work within a larger institution. To illustrate a few of the moral dilemmas that may arise working in the design world, in my story readers start off with the fairly innocuous brief to create “the bathroom of the future.” From there, multiple futures spin off based on the reader’s choices, some ending in firings, some ending in slightly better worlds, and others leading to global disaster.
If you care to read the story relatively spoiler-free, check it out now. The essay below is an unapologetic spoiler fest.
Fireable Offences and Ethical Stands
Only two of the storylines in “The Bathroom of the Future” end in the reader’s firing. The first is a no-brainer. After being handed the brief, the reader gets the choice to either conduct research with real users or just futz about googling a bit before coming up with her own design. If the reader chooses not to conduct co-design sessions with real users, she gets fired for her lack of rigor and hubris. This storyline is meant to reflect the best practices we have learned at AC4D as well as the exhortations from several of the authors we investigated these past couple weeks. George Aye, and Richard Anderson (among many others) all evangelize about the virtues of design research (and co-design activities in particular) as a check on the outsized power of designers. As in all good morality plays, violating this tenet of design ethics leads to woe for the reader/protagonist. (Also like morality plays, this storyline does not reflect reality. In my own conversations with other designers working in a variety of different companies, I’ve learned that quite a few design teams do not ever actually conduct design research. In fact, many are forbidden to do research with real users because their bosses do not want to pay for those hours. It seems odd that something that is so drilled into AC4D students as a best practice is still a contentious subject in the larger world.)
The reader’s other opportunity to be fired and her opportunities to quit arise when the business she is working for begins to take a stance that the reader perceives to be unethical. Be it creating mirrors that tell their owners that they are ugly in order to sell beauty products or medicine cabinets that share data with prescription drug companies so that those companies can upsell name-brand medications, the bathroom of the future the reader creates could be a nightmare.
For instance, if the reader goes down the path of recommending the client build an interactive “beautification mirror,” there are so many negative possibilities. The mirror that suggests a new beauty product you could buy could also trigger the beauty company to send a sample to your door. Though this could be perceived as a convenient service, it is a reminder that convenience is not the highest good. In the short-term, the “beautification mirror” is taking advantage of people’s desire to be perceived as desirable and reinforcing their insecurities. In the long run, those convenient-seeming samples will just end up in landfills. The designers of the mirror, the sample packets, and all the systems in between are culpable for creating artifacts that are not sustainable over their whole life cycles (For more on a designer’s obligation to keep an eye on the downstream effects of her creativity, check out Richard Buchanan’s writing on Design Ethics).
The mirror could be pernicious in more subtle ways as well. What if, like so many apps today, the mirror automatically adjusted your appearance every time you looked in it to make you appear more conventionally attractive? What if the mirror let you easily share these more attractive pictures of yourself on social media? What if the whole process were gamified so that the people who shared the most were rewarded? For the mirror manufacturers, this would be a wonderful form of viral marketing, but for their users and society at large, this has all sorts of negative repercussions. Jiayang Fan of The New Yorker wrote a wonderful feature piece about this called, “China’s Selfie Obsession.” Though the article focuses on the effects selfie beautification apps have had in China (including a significant uptick in elective cosmetic surgery and young people spending hours of their day using apps to photoshop themselves and their friends before posting selfies to social media), those phenomena are certainly not limited to China. People all around the world contribute to social media and manage their appearances on social media in part out of a fear of missing out (FOMO) on the social benefits of participating in the selfie culture. And that is a deliberate result of decisions by design teams at Facebook, Meitu, and other tech giants. Fan’s article, along with essays by Lis Hubert and Nicholas Carr, among others, are compelling pieces of evidence that (some) designers are the new drug pushers, even if they use people’s existing neurocircuitry rather than pills to drive growth.
So, Is Manipulation Always Bad?
No! The other main storyline in “The Bathroom of the Future” focuses on the possibilities of a smart medicine cabinet. Could such a device be used to get users to buy more expensive prescription drugs? Yes. Could it violate people’s privacy by revealing to third parties what drugs individuals are taking? Sure. But a smart medicine cabinet could also help people to take their medications correctly and even incentivize their doing so by offering rewards for being med compliant. It could detect possible overdoses or signal a trusted doctor to check in if someone were to up their intake of anti-anxiety meds. It could be another line of defense (in addition to doctors and pharmacists) against negative drug interactions. In any number of ways, such a medicine cabinet could be useful. So how could a designer steer her company towards those more positive uses of a smart medicine cabinet?
Roger Martin would argue (and I would agree) that part of a designer’s job is designing one’s own efforts to convince one’s stakeholders to go along with your (hopefully benevolent) ideas about what products should be like. This means crafting your story to appeal to the specific groups of stakeholders you need to be advocates for your vision. In other (less euphemistic) words, you need to manipulate them, but toward positive ends. To paraphrase Jon Kolko, all design is manipulation at some level. If you’re going to try to design to benefit the vulnerable, you have an obligation to be really good at driving people toward a shared vision of a better world, i.e. manipulating for social good. Activism, for designers, does not always have to look like marches in the streets. It can be a really great deck, or a well-facilitated co-design session that builds understanding between different stakeholders. It can be educating up-and-comers in a social justice niche about past and ongoing efforts in that space.
Both Digression and Not
This subject of manipulation for public good always reminds me of the movie Selma, in which we get an inside view of the fight for voting rights. In one scene, MLK asks a young John Lewis (who has been organizing in Selma for a while) if the local Selma sheriff is a bully who will come off terribly in the press like Bull Connor did in Birmingham. MLK goes on to explain why the particular power structure of the local law enforcement agencies in Selma means that the police will only be able to block (and begin to attack) demonstrators in one particular location, which will make it easy for the press to cover what happens. This scene illustrates how activists in the civil rights movement, like activists in many movements, very deliberately designed their engagements with their antagonists in order to maximize their chances of achieving their goals (in this case, to sway the public and elected officials to support the the Voting Rights Act of 1965). All of which is to say that manipulation is strategy is design. There’s nothing inherently wrong with strategic thinking, be you a designer, activist, or both. What matters is the end goals and your ability to bring about those goals without creating negative externalities.
There are only a few endings to “The Bathroom of the Future” that are not dystopian or personal setbacks. They all involve compromise.
Many of the texts we’ve looked at in the past few weeks have presented design decisions as black and white: do the project or quit your job, work for whoever is paying you or for the subaltern. In my admittedly brief life experience, choices almost never present themselves so starkly. The best you can do is think ahead as far as possible about the outcomes of your work and let your thoughts be driven by research and work with all the people who will be affected by your efforts. After that, it comes down to your judgment, and it is your responsibility to try to bring about the future that you think is the least unjust. No one gets to start anew, tabula rasa, and build a utopia. So, instead, work within and without existing power structures. You might be so lucky, as in a few of the endings of “The Bathroom of the Future,” to create something that helps more than it hurts.
This week, the team here at KeyUp made a lot of progress on building out our system.
KeyUp is a digital service that connects young adults to training programs and services that can enable them to move into middle-skill careers that do not require 4-year degrees. For this first week of wireframing, we first built our hero screens, including the Browse Careers screen, the Career Profile screen, the Appointment Scheduler screen, and the Quiz question screen. Then we strung them all together (and added a few more screens) to make flows, or example paths users might take (see below). These included the Career and Training Program Browsing flows, the Interests Quiz flow, and the Make and Appointment flow. It came out to 41 screens in all.
We created a usability testing protocol and adapted to the key flows that we’ve developed wireframes for. We crafted the following tasks for our users to accomplish:
Find a career that will make you the most money.
Find a training program that will get you to a career in the shortest time.
Schedule an appointment to get into a dental assistant program.
What are pros and cons of being a dental assistant?
We aimed to conduct testings with at least four people for this first week. Here is some of the feedback that we’ve received so far:
In order to help develop brand identity, we had thought to let users save the careers and training programs they were interested in in their “Keychains.” However, users found this confusing and expressed that they just wished that the Keychain was called “Favorites”.
Looking at the default career cards that first appeared when people clicked to the Browse Careers screen, users became confused because all the careers at the top of the list are in the health industry. As a result, we decided to change the default careers that first appear on the browse screen to alternate between the tech, skilled trade, and healthcare industries, so that it doesn’t look like the app is just pushing careers in the health industry.
Our language on the pages that was supposed to indicate that there are scholarships and other forms of aid out there to complete middle-skill training programs was not clear enough. For instance, users did not interpret our heading of “Need Support to Finish?” as referring to possible scholarship money. In response, we plan to change our language to “It seems like you qualify for financial support.”
IMPACT HUB ACCELERATOR
Last week we submitted Keyup to the Impact Hub’s Workforce Development Accelerator program with the intention of acquiring mentorship in the development of the product. Once again, we confirmed that Keyup’s concept is needed in Austin’s workforce community: we got accepted to the accelerator! After a few days or asking ourselves if we’re really ready to do something like this, and speaking to AC4D mentors, we finally decided that the team is ready to move forward with the application process.
One Big Lesson We’ve Learned
We learned that in the start-up world, people often do not actually talk to their prospective customers. We were surprised in our conversation with the Impact Hub Workforce Accelerator admissions committee to hear that most of the applicants hadn’t done research with their users. We were one of only a few groups that had actually spoken to our users and tested our co-designed solution with them. It was gratifying to hear that what we’ve been learning at AC4D is valued even among people with business backgrounds.
One Big Question We’re Still Asking
We have heard from several organizations that work with young adults to find them training, jobs and supporting services to build their careers, that the benefits that Keyup will bring to the community are considerable. After all, our vision is to help young adults craft their career paths by taking into account their circumstances and lifestyles. But even though we’ve heard from other young adults that they would find value in a service like Keyup, we are still asking ourselves if we’ll receive the same reaction from them as we’re getting from our stakeholders.
Testing our wireframes with at least eight young adults, showing them to our peers, and iterating based on the feedback we receive from them. We will also be building out more of our flows.
One Way You Can Help
Let us know if you or anyone you know would be up for a short (10 minute) usability testing session with us. All that would entail would be clicking through the screens we’ve made and telling us about your impressions as you go.
This invitation goes double if you (or someone you know) happens to be someone without a college degree who is looking to switch careers, but all are welcome!
For our first Product Management class assignment, our task was to markup the flows we made in Q2 of our banking apps and then facilitate a conversation with a developer to create an estimate for how long it would take to create the banking app based on the number and difficulty-level of its features.
Here’s an example of a marked-up flow:
The idea is to provide enough detail about each flow, feature, control, and component that the developer could build the app without the designer sitting there the whole time to answer questions about which button goes where, etc.
The designer then shows the markup to the developer so that the developer can request any additional details the designer may have forgotten. The developer can also suggest better, more efficient ways to accomplish the same goals the designer wants to accomplish and provide cost-benefit analysis around how to build a feature or if a feature should be built at all. Though the estimates the developer arrives at for how long it would take to build out the app’s various features will inevitably be wrong, it gives all parties involved a starting place for planning how the rest of the product’s development should proceed.
I’ll get to the feature breakdown and sizing summary below, but first I’ll write a bit about what I learned by going through this process.
Forcing Mechanism for Iteration
First, marking up the Velocity Credit Union redesign wireframes forced me to refine them even further from where they were at the end of Q2 because it helped to counteract the urge to blindly copy-paste components from similar screens without thinking deeply about what they would mean in this new context. For instance, in my Bill Pay to a New Payee flow, users have the option to search and select from a list of payees that are big companies whose information is pre-loaded into the Payee API. My first iteration of that wireframe featured a chevron (the little arrow point) next to the company name (in this case “Sprint”), but that didn’t really make sense. Users shouldn’t be able to change Sprint’s contact and banking information, so why would that business name be clickable?
Chap Ambrose, the designer-developer who was kind enough to give me an walk me through the estimate process with my app, was able to point out ways in which I needed to be much more specific in labeling pieces of my flows. For instance, my original markup for my home screen, I had just said to change the greeting message to good morning, good afternoon, or good night depending on the time of day without actually specifying when those switches should happen.
I also hadn’t really thought about possible edge cases, such as what should happen to a list of saved bill payees if it the person tried to save 300 bill payees. Should they all load at once? Should the app load the first 10 payees in a scrollable list and then have a “See More” button?
Legal and Security Issues
Chap also pointed out that especially for a banking app, legal and security issues would come into play in the design in ways I hadn’t considered. For instance, he said that he would have to build time into his estimate of my “Wrong Password” flow to figure out whether he would be allowed to implement my original design suggestion of giving the user the explicit feedback that the password was incorrect. He would also need to know how many times a user could try to sign in before they would get locked out, and what would happen if someone tried to log in from out of the country.
My original version of my “forgot password” flow – possibly not feasible from a security or legality standpoint.
Along those same lines, Chap brought up another factor I had not considered: sandboxing issues. Sandboxing is a security mechanism that limits the environments in which specific pieces of code can execute in order to try to limit the reach of malicious software. For instance, Chap reminded me that I would need to explicitly ask users for permission to use their camera in my Mobile Check Deposit feature, which makes sense because as a user you don’t want just any app to be able to access your camera whenever.
Apple’s Human Interface Guidelines also dictate that you can only have a modal pop up asking your permission to access the app once, so as a designer, I needed to account for what would happen if someone denied the VCU app permission to use the camera the first time around, but then later wanted to use the mobile deposit feature. Namely, I would need to wireframe some kind of tutorial letting the user know how to go into their device’s settings to manually change the permissions for the VCU app. This “Denied Camera Access Tutorial” was the only feature in my app that Chap was not able to give me a sizing estimate about since I had not wireframed that process at all.
All Things Are Possible, But Not Necessarily Feasible
One of my biggest concerns going into this process was that my “Ways to Save” feature, which was the most imaginative set of wireframes I created in Q2, might not actually be possible to build out because it involved analyzing people’s spending patterns and then making concrete suggestions based on those spending patterns about how they could spend less. Chap reassured me, however, that the Ways to Save feature wouldn’t be a problem, but due to that feature and a few others surrounding tracking transactions and account balances, I should make the VCU app into a hybrid rather than a native app. This would mean the app would be using APIs (such as pre-existing code building blocks that would have been made for Velocity Credit Union’s internal or web-based banking software) to actually make some of the features of my app functional. For instance, the account summary buttons in my app would be quicker to build if the text in them were populated by a pre-existing Data Account Balance API.
APIs would especially be helpful for the more complicated features that someone must have already built out for other apps, such as Touch ID. Chap thought that it would be faster to just find or buy a Touch ID API than to build one from scratch. The downside to using APIs, though, is that you cannot always tell going in how reliable they are. APIs could be poorly coded, or the programmer in charge of one of the VCU’s APIs might be really hard to work with. For this reason, Chap added extra time padding around any features he thought he would use an API for.
The Actual Estimate
As to the actual estimate, Chap thought that it would take 2 developers approximately 9 months to build out all the features I showed him in my flows. This estimate did not include the “denied access to camera tutorial” for people who did not give the app permission to use the camera the first time they tried to use mobile deposit since I had not created those wireframes at the time of our meeting.
Chap arrived at that estimate by assigning point values to each feature based on whether he had built similar features before, whether he thought an API would be available, and if the features included custom controls, among other factors. One point corresponded to about one day of work for a single developer. Chap then multiplied those initial point value guesses by 1.5 because he likes to pad out his estimate just in case. Then, since this would be an enterprise software product for a bank that would presumably involve many legal and security issues, he multiplied that second total by 2. The detailed breakdown is available here.
In all, he thought the app would take about 195 working days for one person to do (about a year), or about 9 months for two developers. At a rate of $1,200/day, which is what Chap said he would charge for this kind of work, that would put the cost of creating this app somewhere in the neighborhood of $175,000.
For our next project, we’ll be looking at how we could pare down our apps in order shave down that cost estimate. Check back then to see how my redesign of the Velocity Credit Union app has evolved.
In Joyojeet Pal’s article, “The Fallacy of Good: Marginalized Populations as Design Motivation,” he states that we should “pay attention to what we do as a practice – designing usable products – instead of setting our goals at the transformative value we imagine offering to the user.” In other words, stay in your lane, fatuous interaction design saviors! He describes numerous “design for good” efforts as superficial, short-term experiments that serve primarily as professional development exercises for the designers, not helpful or even impactful interventions in underprivileged communities.
Numerous others within and without design have argued that many altruistic design efforts prove fruitless for a variety of reasons: because designers are not incentivized to build a deep understanding of the problems they are addressing, because the design challenge timelines are too brief to create meaningful change, because sometimes you don’t know what happened. You just circle back to an old stomping ground and realize that you can’t tell whether no one acted on your design ideas or if they were attempted but then withered away without the iterative process to improve and sustain them.
As a design student aspiring to create positive social impact, examples like PlayPump International and the High Line park in New York City engender both deep anxiety and optimism. Anxiety because all those projects had at least some unintended, negative impacts on the populations they were supposed to be benefiting, but hope because they show the power of design. We are not limited to creating better, more usable products because even the idea of trying to limit oneself to “just” improving usability is problematic. To paraphrase Jon Kolko of the Modernist design studio, our jobs as designers are to create artifacts and affect behavior, and cultures are defined by their people’s artifacts and the behaviors. Thus, Kolko argues, “Every design decision… contributes to the behavior of the masses, and helps define the culture or our society.” Our decisions are going to be transforming (in ways large and small) the lives and cultures of people everywhere, so we might as well concentrate on making those effects as positive as possible.
So moving right past “should we try to create change,” the questions becomes, “how do we go about creating positive change?” I have a couple arguments to make here which are by no means exhaustive of the possibilities, but which have been occupying me in the last few weeks. The first is universal and procedural: that designers must cultivate a deep understanding of the problem spaces they are working in through qualitative and secondary research. The second is that both long-term, structural change (e.g. shifting government regulations) and short-term harm-reducing interventions (e.g. corporate-sponsored charity and giving underprivileged people access to bourgeois services) are valid as targets of designers’ efforts.
Design Research Evangelism
An antidote to the problems highlighted above with superficial design-for-good solutions is rich, deep research. This means having open-ended conversations with all the stakeholders involved in one’s chosen problem area. Robert Hammond (one of the people behind the redesign of the High Line into a park) for instance, reflected that he wished he had asked residents living in Chelsea near the High Line at the start of the project, “What can we do for you?” rather than asking them more binary questions about what colors of paint they would prefer in their park. Then the mix of people walking on the High Line today would look less white and more like the population of Chelsea today, which is 30% people of color. Indeed, once High Line leaders did start asking, a resident suggested holding Latin dance parties there. The ¡Arriba! dance parties have been successful and well-attended by both local residents of color and people from outside the neighborhood.
In addition to embedded, qualitative research, using a tool like the Impact Gap Canvas can give you a good grasp of solutions past and present that have been tried in a given problem space so that you do not end up recreating old failures of exacerbating past traumas. Without doing this thoughtful and time-intensive legwork, designers trying to achieve social good are like drunken party-goers struggling to play pin the tail on the donkey. They might get lucky and hit the mark, but they’re much more likely to poke a hole in the wall or passersby.
What Should the Target Be?
In this blog especially, I am preaching to the choir in talking up design research, but understanding a problem doesn’t necessarily clear the fog about what one should do about it. For that, we ideate and plot our solutions on an impact-feasibility canvas. Here’s one I created to mapping the methods I’ll be talking about today.
Social Change Methods: Impact vs. Effort Required to Implement
At the top, right corner, the heavyweight of creating positive social impact is changing government programs and regulations. As Aneel Karnani argues in “Fortune at the Bottom of the Pyramid: A Mirage,” the best way to stop companies from selling harmful products to the poor is to impose and enforce government regulations prohibiting or making it harder to access those products. The best way to ensure that everyone has access to high-quality health care is to force the government to provide that access.
That said, changing laws, especially the ones that undergird fundamental systems in our societies, is incredibly difficult and often takes years if not generations. Many hard-working people find their ambitions and optimism ground to dust trying to bring about change in government. Given that reality, designers are right to sometimes make the choice to tackle harm-reducing, smaller scale projects that do not effectively challenge the broader systems that create mass inequities. The willingness to battle bureaucracy and inertia is a finite resource in all of us.
Consuming as Charity
So, let’s take a look at some less impactful but possibly still useful methods for creating change. First: publicized corporate charity efforts that encourage customers to buy certain products because a percentage of the sale will go to some charitable cause. Setting aside the obvious insincerity of many businesses’ philanthropic campaigns, the question is, can they do good? Should I, as a designer, lend my skills to those projects? Problematic though it is to reinforce the ideal of consumerism with all the human and ecological tolls it wreaks, I would lend a hand to some of them. Buffalo Exchange, for instance, a second-hand clothing store with a branch in Austin, gives its customers who bring their own bags to the checkout counter a token worth five cents. The customer can then choose which of three local charities they’d like to donate to and slide their token into the appropriate charity’s box. The three charities currently on offer in the Austin Buffalo Exchange are a local environmental group, a domestic abuse shelter, and a pet shelter. Does Buffalo Exchange benefit from being viewed as a socially conscious company? Undoubtedly. But they are also encouraging their customers to reduce plastic waste by bringing in reusable bags, educating customers about local charities (by asking them to choose which charity they would like to donate to rather than just pre-picking one), and to top it off, they have given over $728,000 to local charities since the program began in 1994. Will the Tokens for Bags program uproot capitalism? No, but it does good in its own way, at a small scale. That seems worthwhile.
“Bourgeois” Social Services
Next, let’s turn to the recent trend of creating high quality services for people experiencing homelessness. Since the early days or public workhouses, souplines, and other services for vulnerable populations, there has been a tendency to design products, services, and facilities meant to help underprivileged people to be, frankly, crappy experiences. This has partly, to be sure, been out of efforts to keep costs low to be able to help the most people possible, but it has also been the result of deliberate efforts to disincentivize people from getting too comfortable with charity. And the clients of these services realize this and often opt out of participating in them because they do not want to be treated poorly.
Lately, though, the news has featured more and more efforts to provide disadvantaged people with the same quality of service that the wealthy expect. One example would be a restaurant in Spain called Robin Hood that charges patrons for breakfast and lunch and then serves fancy, high-quality dinners to people experiencing homelessness. Another would be the Jon and Jill Kerr Conway Residence in Washington, D.C., an apartment building that opened in 2017 to 60 homeless veterans and 64 low-income adults. This beautiful building has a gym, on-site social services, free wifi, the works. And this is just one of a few of these projects popping up around the country. The idea behind these projects is that there is an unquantifiable but essential value to dignity and beauty that will be effective in helping a few underprivileged individuals in the long run. In fact, the idea is that those programs that help just a few individuals will be more effective in the long run at alleviating suffering than programs with lower quality interactions with many more clients.
These programs are too new for there to be any conclusive evidence about their relative effectiveness, but I am curious to find out what will happen. They do not try to change the way in which modern capitalist culture causes people to build their identities around the products and services they consume and interact with. They do not address the threat overconsumption poses to the environment. But they do attempt to change the lives of individuals experiencing homelessness as well as the perceptions of their neighbors. Indeed, the architect of one of these lovely new apartment complexes for the formerly homeless, Theresa Hwang, said, “Especially as we get closer to downtown, people are always like, ‘I don’t want you to build a complex that’s going to have all these homeless people in it, I don’t want to live next door to homeless people… Architecture really helps sometimes by showing it’s not a ‘homeless project,’ it’s not a shelter. It’s an apartment building.” So perhaps these projects that emphasize beauty and dignity will bring about their own level of systemic change, if only to undermine the NIMBY movement.
As For Me…
Examining these cases of attempts at designing for good has only reinforced the nebulous and situational nature of my task as I choose where I should work after I leave AC4D. Government, large corporations, non-profits – they all have the capacity to help and hurt. There’s no escape from ambiguity, responsibility, and the exercise of personal judgment. How exhausting, and how divine.
This week we focused on the ideation process for our Civic Engagement project. For a quick recap, our team (Adam, Mary Hannah, and Mariangela) focused on understanding how young adults without college educations go about engaging with their community and the government.
We started by applying an insight combination technique which consisted of combining our original insights with design patterns (a design pattern describes a current trend in other contexts, e.g. artificial intelligence).
Some of the design patterns that we used were the following:
Cards Against Humanity
Insights that we used:
Young adults need a mentor to negotiate the complexities of growing up.
For young adults, the old ways of connecting with government are remote but nothing has arisen to replace them
Political art provides an accessible starting point for young folk to develop points of view because it wears its bias on its sleeve and organizes facts into a narrative form.
The service industry depends on a workforce that does not attain post-secondary education so that they can continue to pay them a minimum wage.
The combination of the above design patterns and insights allowed us to come up with over 200 ideas.
So how might we encourage young adults to take the very first step to become civically engaged?
The following are three ideas that the team downselected to after the ideation session:
Future me is the result of the need for young Austinites to have a mentor that can help them navigate political and professional landscapes. This mentorship would not only allow young adults to get training and find better job opportunities, but also become integrated into a community formed by individuals in similar circumstances. Research shows that having a higher income and more education leads to a greater likelihood to vote, so Future Me would move young adults further along that path to a professionally and financially secure future.
Austin Youth Changemakers
Austin Youth Changemakers is the result of the recognition that Austin youth are inspired by self-expression and art. We hope to tap into this instinct, beautify construction spaces around Austin, and inspire Austinites to publically share their civic experiences by placing posters with examples of young adults who have created change. Some of the posters will also be educative about civic skills such as voting and contacting one’s elected officials.
Contact Your Rep Butler
Contact Your Rep Butler was designed to provide mentorship and training to enable Austinites to contact their elected officials. By exaggerating and having fun with the old-fashioned nature of calling someone on the phone, we hope to make calling your representative seem more accessible to young adults and other members of the public who would currently be reluctant to call an official.
As we grappled with developing novel, fun, and engaging ideas that tied to our research, we often found ourselves stuck. What would actually work? Once we committed to our ideas and fleshed out the details in storyboards and vignettes, we began to question what is actually possible. What would get someone out of their comfort zone? What are ways our designs can provoke behavior change? Our next steps are to iterate on our current ideas, get feedback from the AC4D community, and look for youth to co-design solutions with.
For this final week of Rapid Ideation and Creative Problem Solving, our professor Jon Kolko had a surprise for us. He asked us to incorporate features into our banking apps that would provide financial modeling services for users. Specifically, the app should be able to:
provide a snapshot of your finances and their trends.
allow you to analyze any specific transaction in any account to see if it is historically anomalous in the context of all of your spending
provide a drop-dead simple “what if” modeling system based on “playing with” your recurring payment amounts, so you can see how changes in monthly spending impact your account.
help you figure out what amount of money is she to spend at any given time.
In order to satisfy those requirements, my classmate Adam Chasen and I first decided that the value we wanted our app to deliver was to encourage people to save more, to help them to avoid overdrawing their accounts, and to help them recover when they do outspend their income in a given month.
With that goal in mind, Adam and I brainstormed different scenarios in which someone might find themselves when the above services might be useful. Some of our scenarios included someone getting a new, better paying job, someone facing a financial crisis due to a surprising large expenditure, such as needing to get your car repaired, and someone who has just had a kid and so needs to shrink their existing expenses in order to support their larger family.
From there, we began to make a rough service blueprint for our apps (shown below) by mapping out what data point could actually signal to our banking apps that these changes had taken place. For instance, the app would be able to detect a rise in income if someone’s regular direct deposit amount increased, especially if it increased over a period of two months.
Next, we decided how the app would respond in each scenario in order to catch our users at times when they would be more likely to be inclined to actually want to use our budgeting and saving features. For instance, we decided that the app should send a push notification if someone made a purchase that would cause their checking to be overdrawn later in the month when other bills came due. In that situation, the user needs to take action to avoid an overdraft fee. On the other hand, if someone’s income rises, the app can wait until someone logs in to send them a congratulatory pop-up message about it that also urges them to put some of their new earnings into their savings account.
From there, we continued to map out how actions would bounce back and forth between users and the apps depending on the actions that users’ took (or didn’t take)
Ultimately, I decided to develop four flows demonstrating my apps’ features: Not Safe to Spend, Ways to Save, Adjust Budget and Over Budget. These were the flows I made paper prototypes for and conducted usability testing on.
Usability Testing Results
The three biggest takeaways from usability testing were as follows:
Final Iterations (for now)
In the ultimate iterations of these flows, the biggest change was also the most obvious: I made digital versions of my screens. I also took into account my usability testing results in a few different ways. I made sure to depersonalize my language around the Ways to Save and Not Safe to Spend features so that my users would not feel attacked over their purchases. I made sure to always let people know what date it currently was so that they could judge how long they needed to make their budgets stretch. Finally, I rearranged the Ways to Save screen to make it more obvious for users that they should be clicking on the Ways to Save carousel first.
Here are the resulting flows:
If I were to continue this project, I would have made digital versions of the screens I designed that would have continued the Ways to Save flow. These screens showed the alerts the user would have received letting them know how much they had saved (if at all) by following their Ways to Save goals. These screens would have been delivered every week or every month depending on the user’s preference.
I also would have built out the flow that would have resulted if someone had pressed on “One-time bump in income” on screen 3.0 of the Adjust Budget flow.
In a more blue sky scenario, I would have loved to have created something that would let users make a specific savings goal (e.g. buy a new car) and then easily see how long it would take them to save up enough to accomplish that goal given their current saving habits and hypothetical savings habits.
What I Learned in Rapid Ideation and Creative Problem Solving
Since this is the last blog post of Rapid Ideation and Creative Problem Solving, it seems fitting to reflect on a few things I learned this quarter.
In this final iteration, I finally understood the value of developing and testing prototypes in low fidelity. Though my first versions of the screens above were quick sketches done with pencils, I was able to get valuable feedback from my participants about the language I was using and whether the layout I was using made sense. Since I was working in pencil, I was able to change my screens in front of my participants during the Q&A time following the think-aloud session, which enabled them to give me more feedback immediately.
I have a better understanding now of what my priorities should be as I’m designing user interfaces, namely that intelligibility needs to be prioritized over aesthetics. This means always making the path to completion obvious to users; they’re on that screen to accomplish a task, not explore (at least in the case of the Velocity Credit Union banking app).
As to the critiques, I am still working on organizing them in a way that is structured, targeted, and not frenetic, but I am better at saying what I need from the audience and setting up my materials in a way that enables them to give feedback. This will be a skill I’ll have to continue to develop as I continue to develop my vocabulary for talking about user interfaces and get critiqued by different groups of people.