If you are a design nerd in Austin, I hope you made it over to the Design for Civic Good event hosted by Impact Hub last night. This Austin Design Week event was toe-curlingly lovely for those of us who want to use design and technology to improve public services and civic life in general. Speakers from the city of Austin and Austin Tech Alliance delivered a nice mix of broad overviews and deep dives into accessibility, design thinking’s place in Austin’s government, the top ten civic design organizations around the world (shout out to my favorite, UK Digital Service), and moving fast to create an app to better inform Austin voters in advance of our most recent midterm election.
Drawing many joyous whoops from the crowd, they laid out a convincing argument for the importance and feasibility of incorporating the design process into government at every level, from form design all the way up to remaking the rules of elections.
If you missed the event, there are consolation prizes: the designers at the City of Austin do some great blogging, and the Austin Tech Alliance news feed isn’t too shabby either. They’re worth checking out.
Alumni Kaley Coffield and Eric Boggs and current students Kay Wyman and Aaron Steinman rocked the socks off the lovely crowd of folks who came down for the AC4D Studio Tour we held as a part of Austin Design Week.
One of the core values at AC4D is designing in public. Those of you who frequent this blog will be familiar with how serious we are about that, but it’s not every day we get to protect time for whoever might be interested to walk through the student war rooms and see tacked up slips of paper with preliminary insights, concept models riddled with scribbles, and exploded diagrams of coffee makers.
Aside from checking out the physical space, our guests got to hear from the AC4D folk listed above about the design process and AC4D projects past and present.
AC4D alum and audience plant Alex Wykoff asked if the panelists knew where to find the “secret sauce” of design, the font of creativity and talent whence springs all good ideas, which gave the panelists a wonderful opportunity to undercut that narrative. AC4D teaches its students (and anyone who cares to pop by) that design is a process, a collection of philosophies and techniques that everyone can learn and apply. As one visitor told me, that’s part of the fun of getting to see student work: when you interact with a shipped, well-designed product created by an experienced designer, you only perceive the delight provoked by their masterful execution. (Or perhaps you notice nothing at all; their design has so seamlessly shaped your actions that you barely note its passing influence.) But that’s just the shiny output from the tangled, rich, wonderful design process. Looking at the beautiful smartphones we have now, it’s easy to forget that the first iterations of phones were cruddy sketches by Alexander Graham Bell.
A night out at a concert is pretty fun, but once in a while there’s a pleasure in listening to scrappy musicians test out licks and lyrics, too.
My favorite quote from AC4D’s Design for Impact Bootcamp this past weekend came from one of our attendees. They had already gotten fast and furious lessons in design research, insight creation, and ideation.
They had gone out and interviewed their fellow Austinites about their relationships with public transportation, synthesized that data, and created a wall of post-its with ideas for addressing the problems revealed through their research: that people never know when Austin busses are actually going to come, that people dread the awkwardness of interacting with their rideshare drivers, that people worry about being bowled over by the electric scooters littering Austin’s streets.
The attendees had so many wonderful, creative ideas for how to improve public transportation in Austin, but in the share-out, one man said about his team, “We had to start over and look back at our research. We realized partway through that we had been designing solutions for ourselves.”
That reflection alone demonstrated the tremendous value of even the quickest introduction to design thinking: it shows just how easy it is to fall into the habit of designing for yourself, to forget that you are not the user, but it also shows how learning and practicing the design process can inoculate you against that tendency.
Hats off to everyone who came to the Design for Impact Bootcamp. They put themselves in the vulnerable position of learning something new, and they rocked it.
If you missed the Bootcamp this time around, come out for our next one!
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.