Innovation and The Limits To Imagined Possibilities

In our Theory of Design & Social Entrepreneurship course, we’ve been considering what might limit our imagination and the scope of innovation, with the hope that we can move beyond those limits and seek further possibilities.

Understanding Innovation
Don Norman and Roberto Verganti discuss the difference between incremental innovation and radical innovation in their article, Incremental and Radical Innovation: Design Research Versus Technology and Meaning Change. They introduce the hill-climbing paradigm applied to incremental and radical innovation, which illustrates that human-centered design is capable of incremental innovation, as designers find the highest maximum point for a particular space (or ‘hill’).

norman - hill paradigm

Moving to an entirely different, and even higher ‘hill’ requires meaning or technology change. In Technology First, Needs Last: The Research-Product Gulf, Norman ascribes this type of radical innovation to inventors and technologists, stating, “They invent because they are inventors. They create for the same reason that people climb mountains: to demonstrate that they can do so.”

But Norman omits a key group of innovators that also push culture and society to reach that other, higher peak: Artists. Artists impact both incremental and radical innovation because they drive meaning change and challenge the way technology can be applied.

Art & Innovation
I received my MFA in Studio Art in 2008, and have been a professional artist for over a decade, so I’m in a position to examine both design and art with an intimate gaze. Artists and designers have a range of overlap, most notably in that they operate from a sense of curiosity and that they are makers of ‘things,’ although those things take many different forms. The key difference between the two groups, however, is that while designers seek solutions, artists experiment with ideas.

theory blog images.001

When it comes to innovation, this distinction is a fundamental differentiator.

In Design Thinking and How It Will Change Management Education: An Interview and Discussion, Roger Martin states, “A traditional manager would take the options that have been presented and analyze them based on deductive reasoning…whereas a designer uses abductive reasoning to say, ‘What is something completely new that would be lovely if it existed but doesn’t now?’” I would take this thought one step further and propose that then an artist might say, “This [material, idea, technology] is intriguing…I wonder what will happen if I play around with it for awhile?”

Artists aren’t bound by the constraints of a solution. As in Don Norman’s investigations, in which “every radical innovation he investigated was done without design research, without careful analysis of a person’s or even a society’s needs,” artists are primarily exploring ideas simply because they are driven to.

Garry Winogrand, the American 20th-century street photographer famously said, “I photograph to see what something will look like photographed.”

winogrand quote.001

To me, this exemplifies the artistic spirit: to do something for the curiosity of doing it. Unlike designers, artists have both the license and the luxury of making things to see what happens when they do. This pure drive of curiosity can often bring about more creative experimentation than making something to solve a particular problem, as designers are often tasked to do. The drawback to ‘art for art’s sake’ is that the creative innovations it reveals are often embedded in singular artifact, unsuitable for practical application in its artistic form. Design and technology can learn from artists and then take specific aspects of that work and apply them in appropriate, reasonable ways.

But this is not a novel idea. I attended graduate school at Concordia University in Montreal – a large, public Canadian university. At Concordia, a multi-school research institute called Hexagram is housed. Hexagram defines itself as an “international network dedicated to research-creation in media arts, design, technology, and digital culture.” From my own experience of Hexagram, the idea is that if you provide cutting-edge technology to artists (and other interdisciplinary researchers), they will find ways of pushing the boundaries of what that technology is capable of. Hexagram refers to their members as ‘research-creators,’ acknowledging that by removing the constraints of finding ‘solutions,’ their research-creators can be free to experiment for the sake of experimentation, and innovation is more likely to occur.

Danielle Feliciano, in her article What Artists Can Teach Creative Thinkers, states that “creativity thrives in the artistic community because it is appreciated there. Accidents, playfulness, and frivolity are encouraged because they lead to the unusual and the innovative.”

I wonder – are accidents, playfulness, and frivolity encouraged in design? Could they be?

theory blog images.002

Implications for Design
So what can designers do to access and adopt the experimental processes and innovative qualities of artists? Most of all, designers should let curiosity reign. Take a few moments to allow lateral thinking and wild playfulness enter the studio. Curiosity and experimentation are at the heart of any radical innovation.

On an individual level, designers should expose themselves to art and artistic practices, especially contemporary art – visit shows and read articles, for a start. Be aware of how artists are using technology in novel ways, and then consider adopting useful aspects of that work to more practical applications in design. More broadly, we should cultivate the tendency to encounter ideas and disciplines that we are unfamiliar with.

Rethinking Discipline Boundaries
What is it that limits what we can imagine? Overall, I believe it’s the division and insularity of disciplines. We need to get out of our own silos and rethink the boundaries on our fields of work and study. As Bruce Sterling says, “Rather than thinking outside the box…we surely need a new understanding of boxes.”

theory blog images.003

The art world is set up to serve those who are interested in art. It takes a concerted effort to go out of our way to encounter and experience it. Similarly, design, business, technology, and the social sciences all reside in distinct spheres. We each remain too closed-off within a particular field, a way of thinking, and and our own common patterns. We lack the integration that will allow us to innovate. We need to adjust our view of who we are and how we make efforts to intersect. There are overlaps in the way different professions work and what we wish to achieve, but the products of our efforts are limited by our individual channels. I propose a new model where we don’t think of art vs. design or design vs. technology, but of a collaborative, integrated, and intersectional model in which the norm is that we eagerly access and learn from each other.

theory blog images.004

Crafting a Compelling Product Presentation

My capstone teammates, Christina Davis and Catherine Woodiwiss, and I are developing a mentorship service that connects 18-25 year old college students with working professionals and provides them with a digital platform for supporting a sustained, in-person mentorship experience. We’ve spent this week creating a compelling presentation that illustrates the value of our end-to-end mentorship service through both narrative and key visual artifacts.

Over the past few weeks we’ve made several artifacts meant for internal sensemaking of our product – customer journeys and service blueprints, for example. While these helped us define the end-to-end solution that we’re providing, as visuals they’re large, complex, and detailed – not useful in delivering a succinct narrative presentation. One of our biggest challenges this week was to develop simple visuals that can speak to the complexity of our service but are intended to be quickly read and understood by an audience unfamiliar with our product.

To create our mentorship product presentation:

  • We created artifacts to communicate the vision of our mentorship service and visually articulate its value. These include high-level concept models that represent the overall user journey of the mentorship service and illustrate how all three types of users in this system – the mentee, the mentor, and the organization – benefit from our product.
  • We crafted high-fidelity screen mockups to illustrate key digital touchpoints in the service.
  • We produced a presentation deck to demonstrate our comprehensive solution and how it fits in with our research and theory of change.

We’ll be taking feedback from our mid-point presentation and refining the artifacts and deck we created to continually improve the articulation of our product’s value to a larger audience.

In the upcoming weeks, we’ll be focusing on piloting our service in order to test key areas with actual users.

To do this, we’ll:

  • recruit participants to test our product.
  • determine which elements of our service and digital platform are the highest priority to test.
  • iterate and refine the key touchpoints based on feedback from participants.

We’ll also be creating a pitch deck to present to student support organizations in order to validate market fit for our mentorship service. If you’re familiar with an organization that would be interested in piloting a mentorship program or if you’d be interested in being a participant in user testing our mentorship platform, please contact us – we’d love to speak with you!

Power in Design: A New Framework

We were introduced to Dahlia Lithwick’s muppet theory in our Theory of Interaction Design and Social Entrepreneurship course at AC4D a few weeks ago, as a framework for understanding ourselves and the true nature of others.  The theory is that either you’re essentially a chaos muppet (Animal, Cookie Monster, Grover) or you’re an order muppet (Scooter, Kermit, Sam Eagle). I’m firmly in the latter category. Although extremely reductive, this theoretical framework has proven both useful and downright fun. Every few days, you’ll hear someone in the studio say, “He’s doing that because he’s a chaos muppet.” Or – “We’re having trouble in our team because I’m a chaos muppet and she’s an order muppet.” This framework, which taps into a fictional, but pervasive cultural understanding, has given us a lens with which to clarify and classify ourselves and our behaviors.

More recently in our theory course, we’ve been discussing the roles of power and ethics in design. For example, Richard Anderson’s article Are Designers Becoming the New Activists? and Ann Thorpe’s Defining Design as Activism, have led us to both informal discussions and formal, structured debates about whether designers are (and should be) activists. The crux of these debates rests on the definition of what an activist is and does. How you understand and define activism informs how you think about design as activism.

Because power is complex and discussions of the connection between power and design require a lot of similar definition-setting, I think it might be useful to introduce another fictional, but well-known framework through which we can interpret the role of power and ethics in design – a construct, like the muppet universe, that is so woven into the fabric of our contemporary collective consciousness that I believe it will bring clarity to the discussion.

I want to examine the role of power and ethics through the framework of Star Wars. More specifically, I ask – ARE DESIGNERS JEDI?

jedi slide.001

I believe asking this question can be helpful for a discussion about the role of power and ethics in design. As I mentioned, the story is familiar to most of us thanks to its popularity, and with the continuation of the movie epic via new films over the past few years, it’s well-known to a range of age groups and continues to be relevant source.

Star Wars is an unambiguous morality tale. As George Lucas said in this interview with Charlie Rose in 2014, “It’s about good and evil, but heroes – what makes a hero…what’s the idea of sacrificing yourself for something larger?” These are questions that have come up in our theory discussions lately, if not in so many words. Because the Star Wars films so clearly lay out who and what is good vs. evil, I believe it can be useful as a lens through which to examine the role of power in design, and our individual power as designers. If, as film viewers, we can so clearly identify with the side of Good, then perhaps we can also bring clarity to our roles as designers. Jon Kolko says in his essay, Manipulation, “Many [design] practitioners seem to have no consistent set of values that they automatically fall to when doing their job.” Maybe this new Star Wars framework can help us define those values.

So, how are designers like Jedi? First and foremost, Jedi control the Force. And the Force is power. Some Jedi use that power for good. Some Jedi use that power for evil. In the Star Wars films, there’s a struggle between one and the other, but the sides are really clear. The Dark Side and the Empire (or the First Order, if you like) are extremely manipulative, and prey on the fears and desires of young Jedi to tempt them to join the side of evil and harm. The Dark Side and the Empire also seek to increase power for themselves, and to dominate the galaxy.

Sound familiar?

Who can we identify in our own galaxy that has the qualities of the Empire? Consider a few possibilities that come to mind –

the empire.001

In this framework, I would propose that Jedi designers working for the Empire are the ones who create and deploy the dark patterns that we encounter in our digital interactions. Someone has to be responsible for unleashing these manipulative tricks for the benefit of (our real-world versions of) the Empire, and the sheer deviousness of some of these dark patterns could only have come from deeply sinister minds.

rainert tweet

When Marc Rainert, Head of Product & Design at the New York Times,  references the Jedi in this tweet, he inherently emphasizes our cultural understanding of the Jedi as powerful wizards, and compares real-life evil designs to the fictional workings of Jedi working for the Dark Side. If we can use this framework to identify the Dark Side in our own world, then can we, as designers, choose to fight it?

The Jedi that work for Good seek to create (or restore) balance and harmony to the galaxy. In Design Ethics, Richard Buchanan writes,

“Designers whose ethical position is grounded on a natural foundation typically argue that the products of design should be good, in the sense that they affirm the proper place of human beings in the spiritual and natural order of the world…they argue that products should be appropriate and just, in the sense that they are appropriate for human nature and the physical and cultural environment within which people live, and that they support fair and equitable relationships among all human beings.”

This, to me, sounds like the same code of ethics that the (good) Jedi live by.

And aren’t the Jedi heroes? How does that fit into our understanding of the role of power in design? Marc Retting, in conversation with Richard Anderson, states, “In my classroom experiences, the biggest challenge for designers is to let go of their engrained sense of themselves as expert problem-solvers who will be the source of the good ideas and the shapers of the resulting forms. Design practice is full of hero mentality.” It seems, unsurprisingly, that designers often view themselves as heroes.

George Aye of Greater Good Studio says, “When designers work on complex social sector issues, they often enter situations with power inherently given to them (even if they don’t realize it). They’re seen as the ones with the newest knowledge, the ones with solutions, the innovators.” We see similar power bestowed upon the Jedi in the Star Wars films. In fact, this hero mentality is exploited by the Dark Side. The ego is appealed to, both from the forces of the Dark Side and from the side of good – even the Resistance believes that Luke Skywalker can save them all. It’s very easy to see how, as designers, we would start to believe that we have all the answers. In fact, Luke quit and got out of the Jedi business. In The Last Jedi we learn that he turned away from the hero worship because he doesn’t believe that the Force belongs to him alone. Luke has the following exchange with Rey, which I’ve amended to reflect the framework of designers as Jedi:

Luke: What do you know about [design]?

Rey: It’s a power that [designers] have that lets them control people and… make things.

Luke: That Force does not belong to [designers]. To say that if [designers] die, [design] dies, is vanity.

Designers, like the Jedi, are not heroes, although they are often thought of as having all the answers (both by others and themselves). Instead, the role of the designer is to teach others about the design process, and to set up systems for those we work with that empower them to take over the iterative design process when we leave. Like the Jedi, designers have a more robust, nuanced design Force than your average person, but it’s our responsibility not to keep that Force for ourselves. Teaching and giving others the power of design doesn’t diminish that Force within us. As George Aye said in his 2018 SXSW talk, “When given away, power generates power.”

Through using this fictional Star Wars framework, it’s easy to see ourselves, both as humans and as designers, working on the side of Good. With that clarity, along with an understanding of the Design Force as power to be wielded with responsibility, we can see how to use our power for Good and not for Evil.

I implore you, designers, don’t go to the Dark Side. Don’t take a job that reflects the qualities of the Empire. Take a stand for the Resistance, even when it seems hopeless. Deny the belief that you have all the solutions, and learn to give away your power by teaching others to use the Force that is design. And may the Force be with you.

may the force.001

Creating Product Roadmaps

For our last assignment in our Product Management course, we met with a developer who gave us estimates for the front-end development time to complete hero flows of our mobile banking apps. Using those time estimates, we have spent the past week creating product roadmaps for our banking app. We’ve created two different roadmaps for the same product, assuming we have two developers working 40-hour work weeks. One roadmap illustrates a full release of our thin-slice flows – the very minimum functionality that still offers value to the customer, while the second roadmap illustrates a release of the product constrained by 30-day release cycles.

PREPARING THIN-SLICE FLOWS

To prepare for creating my product roadmaps for the A+ FCU banking app that I redesigned, I started with the sizing estimates that the developer I spoke with had provided me. The flows I presented the developer were what I would consider hero flows – basic but complete flows for a banking app. Here’s the original estimation summary, broken out by functionality chunks as the developer indicated.

Sizing spreadsheet-hero flows

Fortunately, the hero flows I originally created are already basic and wouldn’t require a lot of time to develop. However, I felt that there were still a few features that I could cut to make for the thinnest-slice flows that my users would value. The highlighted areas in the table below indicate what I removed from the hero flows to define my thin-slice flows:

Sizing spreadsheet-thin slice

My thin-slice flows would take 60 days to develop, as opposed to 80 days for hero flows. With two developers working 20 work days a month, I should be able to develop these thin-slice flows in just over a calendar month.

Next, I prioritized the functions from most important to least important, to determine in which order to build the product and assign the different functions to the two developers on the roadmaps.

Thin-Slice Flow Functions
Enroll in online banking
Login standard
login fingerprint
logout
forgot password
Home (Accounts Overview)
Account details/activity
Locations
Call us
Deposit check
Transfer (internal)

Full Hero Flow Functions
Add account (internal + external)
Menu navigation drawer
Login passcode
Deposit check – dynamic limit


 

THIN-SLICE SCREEN ADJUSTMENTS

I went back to my wireframes and removed the functions and components that weren’t part of my thin-slice flows.

thin slice login.001
I removed the ability to set and use a passcode for logging in to the app, so I adjusted the login screens to reflect this. I kept a fingerprint login in addition to the standard login for Android users because it’s valuable to my users to have a quick way to log in.

thin slice nav.001
I also decided to take out the menu button and navigation drawer, because the functionality included in my thin-slice flows is available to users directly from the home screen. The navigation drawer was built as part of the hero flows to allow users an alternative way of accomplishing tasks, and it includes the ability to add an account, which is a function that was also removed from the thin-slice flows. The navigation drawer was also originally conceived as something that could be built out and expanded, as new functions are added to the app over time. Because the log out button was located in the menu drawer, I had to replace it on the home screen, underneath the welcome header.


BUILDING THE ROADMAPS

I decided to search for and use a product roadmap tool, to gain experience with a new purpose-built digital tool, and one that was hopefully easy to use. After some brief research I decided to try ProductPlan’s software, because I liked the visual layout and it appeared easy for a beginner to use.

First I made the full-release roadmap, which schedules the features of my thin-slice flows for the complete period of time it would take to develop them. I took my list of prioritized features, and calculated how to divide those features between the two developers, using the chunks of time (e.g. 8 days) that the developer had indicated. I decided that a single feature needed to remain with one developer if at all possible, because I don’t have enough knowledge to know if developers can ‘share’ working on the same thing. I set both roadmaps to being on April 1. See my full-release roadmap below:

A+ FCU Product Roadmap- Full Release Model

In my decision-making, it made sense to me for a single developer to own all the pre-login and login features, while the other worked on the highest priority banking functions – home, accounts, deposit check, and internal transfers. On the full-release roadmap, the thin-slice flows are complete on May 14, while the hero flows are complete on May 27. I included additional ‘future version’ functionality, such as the ability to set recurring transfers and viewing spending habits, beyond that date.

In my 30-day release cycle roadmap below, you can see that the first 30-day release, on April 26, includes enrolling in online banking, log in functions, the home screen (accounts overview), and the ability to view account activity and individual transaction details. The user can’t move any money around, but they are able to see what’s going in and coming out.

A+ FCU Product Roadmap - 30-Day Release Cycle Model

At the 60-day release, on May 24, all thin-slice flows have been completed, and hero flow functions are underway. On this 30-day release cycle roadmap, the thin-slice flows are complete on May 20, while the hero flows are complete on May 30. The majority of the 90-day release is dedicated to additional functionality (spending habits, recurring transfers).

ROADMAP COMPARISONS

Aside from the release timeline, and the slight difference in dates that the thin-slice and hero flows were complete across the two roadmaps,  in general they were fairly similar, with a few notable exceptions.

roadmap comparisons.001

In the full-release model, Developer 1 owns all the login, pre-login, and smaller pieces of functionality, while Developer 2 works on the larger pieces of functionality related to the banking functions – home+account overview, deposits, transfers. In the 30-day release cycle model, Developer 1 works on deposits because Developer 2 owns all the functions relating to transfers. Because transfers are functionally integrated with adding accounts, Developer 2 works on creating functionality for internal transfers, then builds out the transfer features by working on the ability to add both internal and external accounts.

roadmap comparisons.002
In the full-release model, to release the hero flows efficiently, the add account feature is broken up between the two developers – Developer 1 works on adding external accounts (which I estimated would take longer), while Developer 2 works on adding internal accounts (which I estimate would take a shorter window of time, since it doesn’t require going ‘outside’ the bank). Realistically, I don’t know if it’s possible to split up adding account features across developers, and if so, if this is the correct timing split. I would need to speak to a developer again for guidance.

In the 30-day release cycle model, Developer 2 owns all transfer functions, so s(he) works on the totality of adding accounts.

KEY TAKEAWAYS

  • ProductPlan’s Advantages + Limitations:

You can add details that pop up in the active roadmap (see below), which is very helpful. But you can’t organize the roadmap by the number of man days, only days on a calendar – by weeks (or months). It doesn’t factor in weekends for you. I had to painstakingly use Google Cal to coordinate the number of man days with a monthly calendar, assuming the work started on April 1.

roadmap-30day-accts callout

  • Starting Thin:

It helped me that I started with very basic functionality. I didn’t have to cut much to get to thin-slice flows, and the hero flow functionality is scheduled to finish chronologically not long after the thin-slice flows are released. I know that things always ‘have to get cut,’ but it made my job easier not to have to cut too much this first time.

  • Constraints of Feature Timeframes:

While it would be possible to fit development of features into a certain time frame if you’re only looking at the total number of man days for development, those ‘chunks’ don’t fit cleanly into that time frame. Creating the roadmap is a little like playing Tetris. You have to consider priority, release cycles, and which developer is best to delegate tasks to.

  • Needing Additional Info from Developers:

One change I had between roadmaps was to divide ‘add accounts’ from a total chunk of 12 days owned by a single developer into two sections (one 4-day and one 8-day) to be shared across 2 developers. Before I would feel comfortable actually doing that, I would need to speak to them to know if that was possible. I need more info to truly make an informed roadmap.

  • Working Ahead:

Because of the time frames of feature chunks, across both models one developer was always working ‘ahead’ to the next version, while the other was finishing the milestone (thin-slice, hero flow, etc). New versions were always beginning in overlap with the current release finishing up. I can see how this could propel a sense of continuous forward momentum.

Click here for a condensed pdf of this product roadmap process.

Click here for more detailed versions of both A+ FCU product roadmaps.

Wireframe Sizing Evaluation

In our Product Management course with Scott Magee, we’ve been revising our banking app wireframes that we designed in our Q3 Designing Digital Interfaces course, in order to learn how a product goes from the wireframe stage to market. An important step in that process is identifying capabilities and controls within the app, then meeting with a developer to determine roughly how long it will take to develop the app based on those features.

At the beginning of this process, I took an inventory of screens and flows, and knew that there was a lot of functionality that was incomplete. Within the time frame of the assignment, I knew there would be a tradeoff between completeness and complexity. My goal was to have a complete set of flows, no matter how minimal in total scope, so I wound up having to reduce and simplify the functionality that I had begun to build out in Q3, including most of the financial modeling that had gone into the app. Although the current app only allows the user to do a limited number of actions – transfer funds, deposit checks, view balances, add accounts, view transaction history – those represent the core functionality of a banking app. There is very little that I wasn’t able to completely build out within the scope that I aimed for, and I feel satisfied with the current status. I have 12 main flows, including login alternatives and pre-login actions.

In an exercise to understand wireframing edge cases and errors, I decided to take a small portion of the app – login options – and include every error state and screen that I could predict, which is reflected in my flows. I quickly realized how time-consuming it is to design these, but also how important it is to consider how and when a user might cause an error, and what information they need to be given to proceed.

FLOWS WITH CAPABILITY BREAKDOWN

Flow 1 - Login Standard A

Flow 1 - Login Standard B

Flow 2 - Login Passcode A

Flow 2 - Login Passcode B

Flow 2 - Login Passcode C

Flow 3 - Login Fingerprint A

Flow 3 - Login Fingerprint B

Flow 3 - Login Fingerprint C

Flow 4 - Logout

Flow 5 - Call Us

Flow 6 - Locations A

Flow 6 - Locations B

Flow 7 - Enroll A

Flow 7 - Enroll B

Flow 7 - Enroll C

Flow 8 - Check Balance

Flow 9 - Dep Chk A

Flow 9 - Dep Chk B

Flow 9 - Dep Chk C

Flow 10 - View Activity A

Flow 10 - View Activity B

Flow 10 - View Activity C

Flow 11 - Int Xfer A

Flow 11 - Int Xfer B

Flow 11 - Int Xfer C

Flow 12 - Add Xtnl Acct A

Flow 12 - Add Xtnl Acct B

Flow 12 - Add Xtnl Acct C

Flow 12 - Add Xtnl Acct D

MEETING WITH A DEVELOPER

I had the honor and pleasure of meeting with developer and entrepreneur Mark Philip to size my app. As designers and students, we spend a great deal of time working on our designs, but meeting with a developer helped connect the work that I do to the bigger picture – how a product actually gets made. This meeting was a huge revelation to me in terms of the teamwork it takes to bring a product to life.

meeting with Mark Philip to estimate development time
meeting with Mark Philip to estimate development time

The meeting as a whole was a huge learning experience for me. However, I do have some key takeaways to remember for next time.

  • Having paper printouts of my screens was an enormous benefit. We could mark them up and have something tangible to reference later.
  • Mark worked with me to suggest some functionality that was missing, or to edit some elements of the screens as I had designed them. The conversation felt extremely collaborative, and I was grateful to have his experience and expertise influence revisions to my screens. I made the revisions we discussed together, which removed some extraneous screens and made the user experience better.
  • Mark suggested that it’s helpful to a developer to be given some sort of site map or architecture concept map, to aid in understanding how all the sections of the product connect. I’ll make sure to create and provide this going forward.

SIZING ESTIMATE

Sizing Spreadsheet

Mark gave me a summary in days, broken up by sections of the app – not necessarily complete flows, but pieces for development as he would approach it. The total came to 80 days, and Mark said that overall he would estimate 3 months for the scope of my current app. With 2 developers working full-time, it would take approximately 1.5 months to do the front-end development for my app, assuming that things went according to schedule. In thinking about the tradeoff of complexity vs. completeness, I’m very satisfied with how long this will take. My users won’t have a robust app, but they will be able to undertake the basic functions of a banking app with a shorter wait for roll-out. As I add functionality into the app, new versions can be released sequentially.

View a full estimation table here, with additional notes and info for each section of the app.

View a pdf of all documented flows here, including the sizing summary table.

Responsibility in Design

 

Evaluation of outcome, not product

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

IDSE402_theory_assignment 1 - good bad.001

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

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

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

IDSE402_theory_assignment 1-chart with numbers

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

edgar winters

Designer responsibilities

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

IDSE402_theory_assignment 1-responsibilities.001

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

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

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

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

A+FCU Banking App + Financial Modeling Capabilities

OVERVIEW
In our Designing Digital Interfaces course, we’ve been working on integrating financial modeling tools into a mobile banking application of our own design. I’ve been working with my own redesign of the banking application for A+ Federal Credit Union, a local Austin credit union primarily serving education employees. Within the expected functions of a banking app, the financial modeling features that I’ve integrated include viewing a quick overview of financial status (income, spending, and upcoming bills) and a deeper view into spending habits. I’ve also added functionality that allows users to view what amount of money is safe to spend at any given time, including the ability to set a ‘reserve’ amount and add notifications for nearing and exceeding a ‘safe to spend’ amount.

Financial Overview Flow
Financial Overview Flow
Spending Habits Flow
Spending Habits Flow

PROCESS + GOALS
I created wireframes for 2 separate flows which I then tested with 4 participants in their homes. For background research, I asked participants what bank they use, what budgeting tools (digital or analog, if any) they use, and what their primary financial concerns are when thinking about their budgets and spending.

My participants, who ranged in age from 22 – 40, were asked to accomplish 3 tasks for each wireframe flow. My primary goals were to understand how users navigated through the different financial modeling tools, how easy it was for them to understand the categories and vocabulary assigned to the tools, and what functionality they felt was missing.

IDENTIFIED PROBLEMS + PROPOSED SOLUTIONS
I discovered a number of problems throughout the wireframes and flows I constructed, but the most prominent problem is in the structuring of the features within the system (information architecture and navigation) and the headings used to describe them in the menu, where most of the features are currently located. Users had differing interpretations of what information they expected to find within each category heading, but no single user was able to navigate quickly and easily to the correct place.

flow problem 1.001

To revise the screens, I intend to consolidate the ‘budget tools’ categories into one ‘finances’ bucket and nest that within ‘transactions.’

Another problem that I discovered is that the categories in the ‘total spending’ visual are not quickly interpretable. In its current form, a user would need to click on every slice of the visual to know what category it refers to.

flow problem 2.001

To revise this, I intend to add a clickable legend to the visual, both to make the visual tool easy to quickly access, but also to give users an alternative path to navigate to individual category transaction details.

PERSONAL TAKEAWAYS
Our original assignment in the course was to redesign a banking app. Through this exercise, I got my first real taste of wrapping my head around information architecture. It was difficult, but because my redesign focused on the app’s core functionality, it made sense to place links to key tasks on the home screen, where users would be most apt to need those functions.

When it came to integrating the financial modeling features, it was challenging for me to decide how much of those features to integrate where it would be highly visible to users, but not take up precious real estate needed for core functionality. On the other hand, I was wary of isolating and hiding all the financial modeling tools in nested menu areas where users weren’t apt to ever find or utilize them. To add to this, of the 4 test participants I spoke, most don’t use budgeting tools (1 participant uses mint.com rarely), although they all expressed the feeling that they should and would like to. That leads me to feel even more strongly that key pieces of budgeting features should be established on highly-accessed core areas, but link to more robust sections of financial modeling, to allow users to dive deeper as they see fit.

flow problem 3.001

Another key takeaway from my testing was how important context is when considering usage. I tested my apps in users’ homes, which gave me an appreciation for their lifestyles and needs. While I was working with Keara, a single mother of a toddler, her son was making his disapproval of us known, and known loudly. He was tugging at her, vigorously inspecting my camera equipment, trying desperately to tap the computer keyboard, and eating post-its. In the middle of the test, she turned to me and said,

“See, this is good for you to have someone who has a child hanging all over them trying to figure something else out. This is real life.”

Seeing firsthand how distracted, by necessity, Keara was has shown me how important it is for her to be able to find the information she needs from an app quickly to be able to accomplish her task and refocus her attention. If an app requires too much reading or interpretation, she’s not going to want or be able to use it.

NEXT STEPS
After this round of user testing, I’ve identified some key problems with the structure of the information architecture, which I will address first. After restructuring where the financial modeling features ‘live’ and how users can access all or parts of them, I will also revise the smaller, individual problem areas that are caused by poor or missing user interface elements. After my revisions, I plan to test with a new group of users for feedback and further iteration.

 

Capstone Project: Concept Definition

CONCEPT DEFINITION
This week, my team put our testing on hold and focused instead on concept definition. Reflecting on last week’s testing and feedback, it was clear to us that our concepts were anything but clear. We needed to define for ourselves exactly what our concepts are by setting a declarative point of view, before going forward to determine whether our point of view has value to our users.

To clarify and define our products, we started with a process of writing down all the things we believe have to be true about each concept in order to take them forward. We then wrote down all the questions we have about each concept, from large questions regarding user adoption – Will users take the time to input information in this app upfront?to small practical questions, such as – How many volunteers would we need to host a storytelling event?

From that long list of questions, we identified a handful of core questions that would need to be answered first, because the concept itself relies on those particular answers. For example, before How many volunteers would we need to host a storytelling event? we need to answer Can we recruit storytellers to sign up to tell their stories to an audience? Without storytellers, there’s no need for volunteers, because we don’t have an event to host.

COMPETITOR/MARKET ANALYSIS
A key aspect of concept definition is a competitor and market analysis. We needed to see what other products and services already exist in the world that are similar to what we want to create, whether as direct competition or as a similarly structured product for a different audience. From an impact perspective, we want to understand what perceived value the existing products and services provide to users. We also want to know in what ways these products are solving the users’ problems, and what aspects or features, if any, are missing, so that we can integrate or otherwise address those gaps. From a business perspective, we want to understand how similar services operate – what their business models are, how they reach their target audiences, how they’ve scaled, etc. so that we can start to better understand how we can take our concepts and turn them into real, viable products.

SERVICE BLUEPRINT
Another method we’re taking to help refine and bring clarity to our concepts is to make service blueprints. These are low-fidelity drafts, intended to help us start to make more sense of every touchpoint a user will encounter with a particular product or service over time and what actions are being taken ‘behind the scenes’ as a user makes that journey with our product.

PK-service blueprint 1

From this process, we start to see areas where the interactions are unclear, and which aspects of the product or service need more definition. We start to uncover what work will need to be done on the back end to enable the user’s interactions and what systems need to be in place for a user to have a smooth journey from initial discovery to an ideal future state of long-time use. We can also identify pain points in the user’s journey at this early stage, and work to overcome those potential gaps to make the user’s interactions seamless.

PK-service blueprint 2

You can see in the low-fidelity service blueprint for a storytelling presentation series that we are developing, that we’ve used bright pink sticky notes to call out potential failure points in the service. We can then address these pain points early on, and create structures within the service that diminish them or alleviate them entirely.

NEXT STEPS
We’re currently in the process of answering the core questions that we have about each concept through competitor analysis and research. This coming week we’ll take those answers and test them with potential users in order to validate (or invalidate) our assumptions and refine our concepts as necessary.

We’re also reflecting on our initial service blueprints to determine which areas of our proposed products need more definition and clarity. Through concept definition, we’re moving from a broad, hazy understanding of what we could create to defining exact, definitive boundaries about what we intend to create. We also have a vision of how our users will interact with our products, and how they solve our users’ problems not just through a single interaction, but over time.

Low Fidelity User Testing, Round 1 of 3

PROJECT OVERVIEW
For our capstone project, my team – comprised of Christina Davis, Catherine Woodiwiss, and myself – conducted research into the education and life experiences of young, first generation Americans in Austin. In quarter 3, our synthesized research has led us to develop a range of potential concepts for products and services which address the problems we identified. We came up with nearly 200 original concepts and down-selected to our top 5, which we fleshed out last week by making storyboards, lean canvases, and theories of change for each, to get a better sense of how user would interact with each design solution, and their potential impact.

After creating artifacts for our 5 original concepts, and receiving critical feedback, we realized that we weren’t as excited about all of them as we felt we should be to take them all forward in the design process. We decided to ideate more on our most compelling concept at this early stage, teasing it into several other variations that addressed the same problems with different ‘answers.’ Instead of down-selecting from our initial 5 concepts to 3 that we wanted to go out and test, we actually created an entirely new design concept, to test alongside 2 of our originals. Although partially going back to the drawing board set us back in our testing timeline, we felt it was better to iterate early on, and pursue products that were compelling to us and connected most with the problems that we identified in our research, rather than committing to lackluster ideas that we weren’t very excited about.

Over the next 3 weeks we’ll be running user tests with low-fidelity prototypes to test the value of each of our concepts with our target audience(s). We do this with 3 concepts concurrently to give ourselves more opportunity to explore potential solutions, rather than decide on a single solution and iterate on that one alone. We’ve crafted specific hypotheses for each concept that must be validated before moving forward with our product, as well as a prototype or testing method for each. Our concepts, hypotheses, and testing methods for each of our 3 distinct design concepts are outlined below.


CONCEPT 1: A digital tool for managing life and tracking personal goals.

Hypotheses:
Young people (under 30) will use digital tools with tailored options to manage life (bills, personal goals, etc).
Young people will do the upfront work to load their information into the tool.

Testing method:
We asked our original research participants to take photos throughout their day of things they wish they had help managing, and told them we would text them reminders throughout the day prompting them to take the photos.

camera challenge
Test Rationale:
The camera probe activity tests:
– That people will do work on the front end, because if they are willing to take photos throughout the day, they’ll likely be willing to do work of loading their info into a digital tool.
– Which areas of life are the most important for participants to manage.
– That reminders throughout the day are effective (because the tool we envision will do this as well).

Results so far:
We’ve had 2 participants respond to our camera probe request so far. One of them, Ashley, didn’t take the photos, but she did give us useful feedback –
I use Google calendar and the iPhone’s ‘Reminders’ notes to remind me about various tasks or appointments. It would be nice to have everything on one app though since Google calendars takes more effort to coordinate a task … and the Reminders notes app tends to get busy and filled up.”


CONCEPT 2: An online advice forum for First Generation Americans, written by First Generation Americans

Hypotheses:
Young, first-generation Americans will actively seek out answers to their needs and questions.
Young, first-generation Americans will value doing this anonymously, online.

Testing method:
We asked former research participants to fill out a brief questionnaire of times when they have sought out advice.
Advice questionnaire
We posted similar questions to 3 Reddit channels:  r/Advice, r/Immigration, and r/ApplyingtoCollege

1st generation Americans, what’s the best piece of advice you’ve gotten about choosing college/career? from Advice

Test Rationale:
– The questionnaire posted on Reddit tests that young, 1st gens use social/online channels and will gauge whether there is value in this type of advice.
– The request of former research participants tests that our target population has asked for advice, has found it helpful, and is willing to share that advice with others.

Results so far:
We’ve received 2 in-depth responses from previous research participants.
For example, Kristen told us, “In the last year, I needed to ask anyone who was good at financial planning for advice. I had just gotten my first new car, a credit card to build credit and other bills that piled on top of these big ones, because my paychecks were not aligning with them. I wished I had a guide for that, but I figured things out as time moved.”

Based on feedback so far, we feel that young first gen Americans would value a forum for seeking advice on navigating challenges, including and beyond the scope of school.


CONCEPT 3: A First Generation American Pecha Kucha event – Professionals who are first gen Americans will present on their work and experiences to an audience of young student first gen Americans

Hypotheses:
First generation American professionals are willing to participate as presenters of their work and life experiences.
There is an interested audience – specifically, 1st generation American young people/students.

Testing method:
We created a landing page for our Pecha Kucha event with the ability to be put on the attendee list, and are attempting to drive traffic to the site.

Screen Shot 2019-02-01 at 9.52.57 PM

We’re also recruiting presenters from our previous research contacts: including SMEs, stakeholders, and personal connections.

Test Rationale:
– The landing page gauges potential audience interest.
– Commitments from presenters validate our ability to host the event, and excitement around sharing their experiences.

Results so far:
We’ve had 5 email signups from first gen college students eager to attend the Pecha Kucha event, who we met while seeking feedback out in the field, at UT and St. Edward’s University.


NEXT STEPS
Reworking our original concepts delayed testing, so our initial round of testing will run through the beginning of next week in order to allow time for the participants that we contacted to respond. During the remainder of the first round of tests, we’ll be continuing to reach out to known contacts and referrals for their feedback on our concepts, as well as going out to university areas to solicit feedback in the moment.

Next week we’ll use the test results from week 1 to refine our concepts, refine the hypotheses that we test, define new prototypes to test with, and get more feedback to keep iterating on our design solutions.

 

 

A+ FCU Banking App: Redesigned Wireframes

In our Designing Digital Interfaces class, we’re exploring a redesign of a mobile banking app. I’m redesigning the banking app for my Austin-based credit union, A+ Federal Credit Union, that I regularly use and often find frustrating. The bank itself is very small, relative to big banks such as Chase or Wells Fargo, and as such, doesn’t have the design sensibility that these big corporations have. The app is complex, confusing, and the navigation is less than user-friendly. In trying to wrap my head around a redesign as a newcomer to both designing digital interfaces and understanding navigation, starting with this app I feel like I’ve been handed a new instrument and given some Rachmaninoff to tackle. I’m going to start first by playing some proverbial scales, and simply rework the major failures of the existing site, not straying too far from the original design. Baby steps.

You’ll see in the image of the home screen below, I’ve outlined some red boxes. The red boxes around the buttons within each account section allow the user to make transfers, deposit checks, and pay bills directly from the home screen. Previously, these options were nested deep in the menu (top left), located under another tab labeled ‘transactions’. Since these are high-level goals of a bank app user, I placed them on the home screen, where users can have quick and easy access.

Adding buttons and a Profile Section to the A+ app
Adding buttons and a Profile Section to the A+ app

The red box around the image in the top right of the home screen indicates a profile section that currently does not exist in the app at all. This is where the user can set and manage notifications, view statements, change mailing preferences, get help, and quickly log out.

The newly introduced 'Profile & Settings' page
The newly introduced ‘Profile & Settings’ page

Having user goals in mind (deposit a check, pay a bill) when redesigning this app helps me to think through the steps a user needs to take to get to their goal, and in turn start to tease apart and rebuild the currently over-complicated and non-intuitive pathways that exist within the A+ app.