A Mobile Bank App Adaptation

It’s been fun to pass from the designer hat to the product management hat for the past three quarters.

So far, I’ve learned how to break down, define and prioritize the necessary capabilities in a mobile application, I have drawn up scenarios inspired in real life situations and potential users in order to match them to these capabilities. I have also created low fidelity and high fidelity wireframes in Sketch, and have made them interactive for usability testing purposes which is also a method that I used in order to get feedback from real users.

Then, my product manager self went and talked to a developer in order to get an estimate of how long it would take to build the screens that were designed – which, by this time, were annotated to differentiate features from controls. This taught me what to expect from a conversation with a developer: the questions I should know to ask and the tools I should have whenever I engage in a conversation with them. After my conversation with the developer, I did a rough cut: this helped me prioritize which elements of the application I should prioritize to get built for a minimum viable product.

After defining our MVP, I created a roadmap – the visualization I will use to communicate to both the executive and development team about the latest progress.

Finally, I created a Strategy and Feature Brief (see full brief here), the purpose of this reading deck is to be shared throughout my hypothetical organization in order to share the vision of the product.

Screen Shot 2018-04-17 at 8.25.07 AM

Screen Shot 2018-04-16 at 8.44.06 PM

Screen Shot 2018-04-16 at 8.43.53 PM

Screen Shot 2018-04-16 at 8.44.18 PM

Screen Shot 2018-04-16 at 8.43.41 PM

Screen Shot 2018-04-16 at 9.26.11 PM


Screen Shot 2018-04-16 at 9.26.30 PM Screen Shot 2018-04-16 at 9.26.17 PM





What actually limits what we can imagine?

Prescribed Imagination

We’ve been exploring different answers to this question in the readings for this past week. We read about how simple things in our daily routines can actually be constraining us from thinking the possibilities beyond our current existence.

Going beyond the limitations of our imagination is tough, this is why designers and inventors have come up with methodologies that aim to disrupt the way we think and let us go a bit further than individually possible (aka, defamiliarization, insight combination, reframing). We can also imply that it takes imagination to come up with these methodologies, but it is also interesting to think about how, as humans, we are conscious about what we don’t know but curious to push the boundaries to see where our minds take us.

But imagination is an important element of innovation, so much so, that individuals in creative roles are now more important than ever. Seeking value and differentiation for a product or service is becoming harder, but chances are, if our methods are implemented in the right way, that a team of innovation is most likely to succeed in this task.

In his article “Management Education”, Roger Martin introduces one example of such methods, he states that “ […] design is not about either/or but about integrative thinking.” Integrative thinking being a way in which all perspectives (user, stakeholder, competitor, etc) around one problem are considered as a whole during the analysis, and never taken apart, avoiding tradeoffs.

Designing technology for humans

Technology has made us become more aware and proactive about our health. The massive amount of data we receive after two seconds of googling informs us (and can also get us a little panicky) but it has also made it more accessible for us to know about treatment options, their  success rates, costs, related support groups, etc. But it doesn’t really matter how much data has been made available to us, at the end of the day, our experience will be defined by the interaction with another human.

Designers are supposed to work based on empathy, but how many products or services are we designing that help people gain empathy for each other in an unbiased way? Quantifying data has become so important in order to track business performance, that the idea to stop and think about what people are really talking about is nonexistent. This resonates with what Tim and Karen say on their “The Cloud and Other Dangerous Metaphors” article published in The Atlantic:

“Our current data metaphors do us a disservice by masking the human behaviors, relationships, and communications that make up all that data we’re streaming and mining. They make it easy to get lost in the quantity of the data without remembering how personal so much of it is. And if people forget that, it’s easy to understand how large-scale ethical breaches happen; the metaphors help us to lose track of what we’re really talking about.”

Screen Shot 2018-04-15 at 2.38.45 PM

So how might we leverage existing technology and the concept of current social platforms to do this? How can we get past the day to day potentially frivolous information and help humans understand each other? We’re not talking about Facebook or Instagram here, we’re talking about something that is more complex but potentially more rewarding. Because how else do we gain empathy by people if not by asking questions. But how feasible is this in environments like, hospital rooms, to be able to ask questions without hindering efficiency.

We read a couple articles from April Starr, a designer that has shared some of her personal experiences with healthcare services. She does this by describing the patient/ caregiver perspectives, and the emotions that take place when they’re in one of the environments that can make people feel the most vulnerable; a hospital room filled with uncertainty and anxiety. Who would have thought that the humans that are there to make you feel better, aren’t cutting it?:

“Who are you? You walk into the room and we don’t know your level, specialty, name, or role. Should we listen to you? What questions can we ask you? Who the fuck knows?”
 Free ideas from a human-centered designer for hospitals that want to be (or make it seem like they are) patient-centric.

During a quick class activity, I challenged myself and my classmates to address this “how might we” question. The problem was a near future, where population will be exponentially larger and the communication between doctors and patients is still deficient. The frame I used for this activity was inspired on the dependence all organizations have on dashboards. The rules where the following:

Screen Shot 2018-04-15 at 6.40.34 PM

Although the dashboard format was a constraint, it was interesting to see how my classmates had different ideas and perspectives to display on the dashboard. Thinking not only about the content on the interface but also their physical (hardware) form.

But, let’s remember designers are not “it”

We most likely don’t have all the answers, which is why we need to find ways to find authentic ones, design research is a good way to start. It is still important to mention that, even though designers need to “think out of the box” on a daily basis and for professional purposes, necessity is still the mother of invention. All humans have the potential to be creative thinkers, thus, have the ability to push their thinking beyond what’s prescribed, and create solutions that suit their needs. Our role as designers is to make things in an integrative way.

Defining Magic Moments: KeyUp

Last week, we presented our progress for KeyUp to an audience composed of AC4D alumni, city representatives, and current students. We received all sorts of feedback that pointed us toward the fact that the framing of our problem needs to be more polished. We need to spend less time talking about our solution and more time speaking about the stories that led us to the solution and explain its relevance.

So, we went back to the whiteboard this week and have been keeping hard at work in order to answer the following question:

“How can we reach and engage young people without college degrees looking for better careers?”

To do this, we focused on clearly articulating what the problem that we are currently trying to solve is in order to break down KeyUp’s “jobs to be done” and consequently, the magic moment that KeyUp aims to provoke in people that are trying to find jobs that fit their lifestyle.

(Re)defining our problem

We went back to our past design research and reflected on the experiences we heard that inspired us to come up with the concept of KeyUp. A few of the statements that we heard and that we are treating as a foundation of our solution are the following:

Young adults need:

  • help finding careers that are suited to their lifestyles
  • help finding training even if they know what career they want to follow
  • to be able to stay in school once they’re in
  • to feel confident about their decision to not go to a 4-year college
  • to feel intellectually capable to choose “difficult” careers (e.g. people not wanting to choose a career in tech because it involves math)
What we heard of in Design Research

Our MVP’s magic moment

KeyUp’s main value proposition is to suggest areas of support that many people can qualify for but that they’re usually unaware of such as financial, transportation, and childcare aid. For the magic moment, we are trying to focus on all the aforementioned needs but mainly the following one:

“Young adults need help finding careers that are suited to their lifestyles.”

Magic Moment “I could actually swing going back to school”

Refocusing on artifacts


Another effort that we decided to spend time focusing on is the outreach piece. For this, we grabbed the key quotes that we resurfaced from our research and started ideating a series of statements that boldly state the benefits that KeyUp will provide to users looking for other career paths. The purpose of this new marketing campaign test is to hand them over to people in the streets and to use them in online ad campaigns. We will then measure which messages resonate best with users (as judged by click-throughs and affective responses). You can see examples of these (reviewed) artifacts below:

Postcard / Advertisement


Our website keyup.org has been alive for a while. Its earlier iterations provided information about who we are as a team and the purpose of the service. Nevertheless, we realized that in order to make our Minimum Viable Product more real, we needed to make key information accessible to users, especially if we were going to engage them through online advertisements. Our assumption is that updating the site to include testimonials and information about middle-skill careers will allow us to guide users to a site where they could start getting true value, and it helps us get metrics about the response the site is having to this audience.

The main information we’re providing to users is the middle skill level careers that someone could aim for, the salary they could eventually earn, the hours required for training, and the number of job openings in Austin. To complement our effort to get more exposure to potential KeyUp users, we added this career-specific content into the website, as well as quotes from people that we’ve heard from during our design research. The following are the aforementioned sections:

keyup.org — inspiring quote


keyup.org- job options
Design research in ACC Highland’s Job Fair

On Friday, we went to ACC for a career fair. We observed many people anxiously approaching booths with local businesses, asking lots of questions, getting interviewed, and handing out their resumes. Local businesses tried to sell their workplaces as the best places and passed out candy and swag. It was good to immerse ourselves in the experience and listen to the ways people describe their talents and interests.

We also spent time interviewing career fair goers. We learned why they came, how they learned about the career fair, what they were hoping to gain, and what they believed to be their next steps. A significant number of the people we interviewed were actually there to practice English and/or their interviewing skills. They also gave us feedback on our postcards. We learned that the bolder, cleaner messages featuring people had the most impact.

Visit with developer

On Thursday, we met with a developer so that we could get a better sense of how feasible our solution is. We wanted to get feedback from an experienced developer to see if 1) the project seemed inspiring to him, 2) how long it would take two developers to build KeyUp, and 3) how much it would cost.

First, the developer thought the project seemed inspiring and he wished he had time to work on it. Second, he said that it seemed like the project was something that a student developer would love to build. He suggested we figure out a way to pitch our project to developer bootcamp students who are about to work on their thesis projects. He said that bootcamp students are tasked with building something and they only want to practice coding, not coming up with an idea of a system. He suggested we try and create a relationship with either UT Coding Bootcamp or Hack Reactor.

Next steps

Next Friday the 13th, we will be conducting a design thinking workshop at Austin Youth Works with an audience of 10 students. In this session we will be testing our minimum viable product of which you will see a User Journey Map below.

MVP Journey Map.001
Customer Journey Map

Stay tuned! We will share our experience of facilitating this workshop next Saturday!

Product Manager Hat: Creating a Roadmap

For the first part of our Product Management project I met with a developer to estimate how long it would take to build the banking app for which I designed hero flows and user tested in the second quarter. During that conversation, the developer gave an estimation for how long each screen would take to build, the reasons why, and a few suggestions of what to do to make a few flows more attainable than others. If you’d like to take a look at the previous process, you can go here


Original Sizing Estimate
Original Sizing Estimate

The next step a product manager takes after sizing an application the way we did with our developers, is to reduce the scope of a hero flow to fit into the development timeline that is available. This is done in order to plan how to build the application by removing features but by making sure that it continues providing value for the user. This keeps app building planning realistic but still focused on the product’s vision.

According to the developer’s estimate, it would take 120 days to build the banking application, aka: the flows that were shown to him. In order to ship a product faster, we need to take certain steps to make sure we remove certain features from the application now, but without removing basic capabilities that allow function and user satisfaction.


Revisiting hero flow

I revisited the hero flow with the printed excel spreadsheet that had the estimate my developer gave me, I went through the screens, and basing myself out of the time it would take to build each one, I would make the decision to either cut down several features in one flow or let it as it stands.

Original hero flow for “Accounts” looks like the one below:

Screen Shot 2018-04-01 at 11.08.32 PM


Rough cut thin slice flow

Due to the conversation I had with my developer and basing myself out of some of the usability testings I did with potential users, I decided to cut down the “search” feature because I now that it’s something that users seldomly use. I also decided to remove the “credit limit bar” simply because it needs more visual design work. I also removed “make payment”, “money field” and “calendar” because this is a capability that can be found elsewhere in the app by going to “Move Money”. Having those features there only makes it more convenient to use. You can see an example below:


Rough Cut process

I crossed out each feature that will not make it for the Minimum Viable Product launch and then calculated how much it would take to build after that first round. There was a lot of back and forth doing this exercise, but was finally able to cut down development days from 120 days to 60.

60 hours dev


The “Accounts” flow rough cut ended up looking like the image below:

Rough Cut

New thin slice flow

After revisiting my hero flows, I went on to the next step and modified the wireframes according to the changes that were made during the rough cut, turning it into a thin slice flow:

thin slice accountsThis thin slice flow provides basic capabilities so that the user gets full functionality and value from the app.

You can take a look at all of the thin slices here.

Capability Description and Sequence

After defining the thin slice flow, a detailed description was provided for each of the features and placed in sequence. The capabilities are arranged on top of the timeline previously determined for each one of those capabilities that will be built under the MVP launch.

Screen Shot 2018-04-01 at 10.23.48 PM
Minimum Viable Product Roadmap with Estimate and Capacity

The same process was used to define the first and second launch of the app.

Product Roadmap

After finishing the rough cuts, I had everything needed to start putting together the product roadmap by illustrating the sequencing of the key product changes that I decided to make in order to adapt to capacity constraints.

The minimum viable product launch for my banking app is 60 man days, considering I will be having 2 developers working full time, this means the MVP will be launched in 6 weeks. After the MVP release, I will be launching features every 30 man days, aka 3 weeks.

Full product roadmap

You can take a look at the roadmap development process here


What I learned:

  • Designing a full vision is important to have as a guiding star, but taking into account how features can be removed by sets without removing value is a strategy worthy to have in mind.

Things I could have done better:

  • Be more detailed when note taking details for a specific screen. Providing more detail on the developer’s rationale about what can and cannot be done could better feed my decision making process to cut down features. This is only if there is no in-house developer available.

Next up, we will be reviewing our roadmaps during class and then we’ll continue developing a strategy brief to bring this app to development.

Influencing Outcomes


Influencing Outcomes

The overlying theme of these past two weeks in Theory class discussions have been around power. Once more, we individually read articles about subjects such as design as a tool for colonialism and activism, and also design as a way to instill convenience in people’s lives, as well as a tool for surveillance in today’s technological world that depends heavily on data and of which we don’t have much control on.

The first group of readings prompted the thought about why it is so important for designers to have a set of principles and ethics established for our practice. Designers oftentimes need to make decisions in a split second and in an ambiguous environment. These decisions may seem small and quasi insignificant at the beginning,  and even though for many designers, other people’s lives won’t be immediately affected by our outputs – we do need to invest more time thinking about the consequences of our creations and how they could potentially have a large impact on the lives of entire cultures in the long run. This is particularly in reference to Assia Lamzah’s article Urban design and architecture in the service of colonialism in Morocco which describes in detail how French colonialists’ influence in urbanism and architecture went about “disrupting the social fabric and cultural meaning of urban space” by imposing their ideas and own points of view in the design process, and not including the local voices that had been there from the beginning.

Colonizing with Design

The subject of “colonizing” with design or imposing design in an area that we’re not particularly knowledgeable on context wise, is pretty relevant to this recurrent topic about how design ethics are currently missing from the industry’s best practices. Currently, design is becoming a big boom So, the question could be, how do we make sure that we are not currently working on projects that won’t have long term negative effects in other people’s lives? How soon will we be able to know if we chose the right project or if we made the right decisions. And if this continues to be tricky to forecast, then should we just follow our best guess?

Synthesizing what people say vs. asking them what they want

But we can’t always depend on the best guess, an ethical designer should be able to provide the right synthesis between what a stakeholder he/she’s designing with says and does. We can’t really rely on what people say just for the sake of it. It is by synthesis and by applying the right amount of experience that will end up  helping us define the end form of the product, system or service. So if they can’t really become our companions along the way, then the words of Pelle Ehn resonate quite a bit when she asks, “How do we design systems to fit people?”. 

Designers and Inventors

The good news is that innovation and design isn’t something that can be taught to just a group of privileged people. More and more, the modern world becomes aware about different social impact initiatives that are founded by individuals that have no experience with design at all. Reflex Design Collectives speaks to this when saying,

but how much of the skills of a professional designer are ‘given’ from a teacher to a student, and how much are they cultivated from already existing skills available to all human-kind? 

Designers with a title aren’t the only ones that should comply to a design code of ethics, It should also be followed by any individual that will build something that people will use and that could potentially have a long term effect on socio-cultural and economic factors.


We have also discussed how much power a designer could potentially have in his space of business. According to Uday Gujendar’s , there are four levers that designers could exercise and pull. By maintaining a balance between the four vectors and continue practicing it for a long time, a designer in a new organization could finally get a sit at the decision making table.

Screen Shot 2018-03-29 at 11.14.38 PM 


There’s diverse perspectives on how people’s attention to a specific subject should be gained, Jon Kolko’s  Manipulation article quotes Victor Papanek’s perspective on the role of advertising design,

Advertising design, in persuading people to buy things they do not need, with money they do not have, in order to impress others who do not care, is probably the phoniest field in existence today. – Victor Papanek (1971).

But manipulation also seems to be an efficient tool to change people’s behavior towards a specific stance or practice.

So how can we use manipulation in the creative industry in order to be able to use design and convince/manipulate change on behalf of society. 

Screen Shot 2018-03-29 at 11.14.44 PM

.  We need to treat design work with respect and analyze it the way a UI developer would come up with edge cases; figure out what could potentially go wrong with a project and visualize how it could potentially trickle down into something bigger that could impact millions of people. After all, design, in all of its shapes and forms, is all “[…]about taking responsibility for the things we unleash in the world” (Jon Kolko, Manipulation).

Discovering the world of product management

This quarter in Product Management

So far we’ve learned skills that have to do with design, business development, and production of technological products.

We started this quarter with an introduction to product management, method and skill (that will be added to our toolkit) and that aims to better prepare us to lead product planning and development from beginning to end. {the intention of having this knowledge is…}

Before this first assignment, the class had a brief introduction to the world of developers. For this, three guest speakers came to AC4D and talked to us about their ventures, process and current projects that they’re working on. From server configuration, to web development, to hardware software development, all three speakers shared their perspective of what it should take for us to have an efficient feedback session with a developer as part of a Product Management role.

For this assignment, we were tasked to show our baking wireframes to a developer so they could and facilitate a feedback session with them so they could size – assigning relative estimates to unique features, components and controls. Before this first assignment, which I will be telling you all about below, my peers and I already had a general idea that:

  1. Developers strive for efficiency, the more accurate information they can have about your product, the better
  2. There is no universal way to do sizing (developers all use different methods but the most typical ones are “t-shirt sizing” and “fibonacci sizing”)
  3. The estimated time it will take is almost never accurate, but it’s useful to have active conversations with the developers anyways because it provides clarity of what it takes to develop a mobile app to everyone involved in the project.

Break down feature and capability

In order to prepare the screens of my banking application for my meeting with a developer (and AC4D alumni – Chap Ambrose), I started by reviewing the screens that I had created in Q2. I started by separatating each flow into its own category, duplicating the screens that I needed to in order for the flow to make sense.

Sizing Exercise - 1
Sizing exercise: Preparing screen flows for walkthrough with developer

After this I started analyzing each screen in order to categorize them by feature (behavior of the system that directly fulfill some user need. Aka: “view account summary”) and component or control (system parts that provide and encapsulate common functions needed to implement features. Aka: “drop down list”)



Components breakdown_example
Example of screen annotation for component breakdown (“Account Balance” flow)


Features breakdown_example
Example of screen annotation for feature breakdown (“Account Balance” flow)

After doing this for each one of my flows, I started documenting each feature and control in a spreadsheet by assigning them a label with a name, a unique identifier and a description under each of those elements. All of this is done outside of the context of the wireframes so the could stand on their own. Each screen pertaining to my wireframe flow was also given a unique identifier that was added to the documentation of my components/features so that they could be easily referenced.

Out of context documentation
Documentation of each feature and component individually and out of context.

The whole annotation process ended up looking something like this:

Annotated screens

For a detailed view of all the annotated screens click here, for the breakdown exercise. here, for the entire breakdown.  

Sizing Session

After finishing preparing my screens, it was time to meet with my assigned developer to get a estimate for the development of my app! Activity otherwise known as “sizing” – a method for assigning relative estimates to unique features, components and controls.

Prior to meeting with Chap he let us know that the proper way to show him our screens would be directly in my Sketch file. So before our meeting I made sure my annotations were made directly in my file. Our meeting was in a coffee shop, he had his computer where he opened an Google spreadsheet ready to annotate information for each of my screens. As I walked him through the screens, he quickly analyzed each one of them and asked questions, shared concerns and made suggestions. After I attempted to clarify each point, he identified each screen on one of his google spreadsheet fields and gave it a number. I will share my learnings below:

Things I hadn’t thought of:

Source of data: The developer will need to have an idea of the source of the data that my app will use. Since I’m not actually employed by bank, nor I’m a bank owner, I had no idea how to answer where the data of the transactions will be coming from, or the source of the API’s needed for to make it actionable.

Things I didn’t know:
  • By now I know that each developer has a way to measure how long it’s going to take them to complete a project. In class we were introduced to the concept of sizing using t-shirt sizing and the Fibonacci framework, but my developer used “points”.
  • API knowledge: There were a lot of questions regarding data sources which I had no idea how to answer, but definitely gave me a notion of what types of questions I would expect from another sizing conversation.
  • Legal concerns, due to the nature of the project – Banking Application -, there were questions around how safe it would be to handle private type information like a banking customer.
What I will do better next time:
  • Time management: Ask beforehand how long it will take to go over a specific amount of screens to know how much it will take to go through them during the sizing session.
  • I would have liked to have had an intake form with each screen number so I could take notes for each screen in a more efficient way.
  • Missing screens: there are a lot of interactions I did not think through when building the screens for my app. Many of them have to do with edge cases that I did not take the time to come up with. To do this, it is advised to spend some time analyzing each screen and come up with different scenarios that could trigger different responses.

Unfortunately, the meeting had a hard stop after exactly one hour and I had more screens that we did not have time to go over. But at the end of our meeting I was able to get a high level estimate of how long my app will take to be developed.

Screenshot of estimate spreadsheet (Flows “Account balance” and “Pay someone”)

For a view of the entire sizing spreadsheet, please click here.

Fields highlighted in orange are missing screens that the developer did not know how to estimate. I also learned that, the less unknowns the developer has or detects in the customer (myself in this case) the more likely he or she will be to double the amount of time it would take for the app to be developed. Considering that I potentially had only 50% of screens of the entire system I was given an estimate of 120 days of work (excluding questions marks, aka: screens without wireframes).

Next Steps

After this exercise, we will share our learnings in class and get feedback which we’ll then use to create a roadmap to plan for our product development.

Selfish and Sensible Designers

It’s week two of Q4 and our Theory of Interaction Design and Social Entrepreneurship class has kicked off with a curated list of readings that we discussed in class and then synthesized for better understanding, very similar rhythm to our theory class of Q1.

But before I go ahead and talk about my conclusions around the assigned readings, I want to share my personal perspective on why I think design theory is important for design practicioners. After describing the phenomenological and positivist approaches in a digital technology context, and the importance of designers to have them in mind when making decisions, Richard Anderson says:

Theory informs practice. Without knowing the types of things described above [positivist and phenomenological concepts], decisions are still made, but they are made with a less informed, less thoughtful consideration.

Theory informs practice because of its narrative based on other’s experience and research. Having a clear concept of theory as as a design practitioner is necessary because it provides a knowledge base that we can use to learn from other people’s mistakes and points of view. But it is mainly necessary because it helps us develop our own set of principles.

But having principles as a designer isn’t enough. In his article “Yet Another Dilemma”, Richard Anderson sheds light into a problem that I believe is latent in the design and entrepreneurship community; in many instances we don’t remember to follow up, and when this happens, we disregard following the act of following through. This translates countless hours spent problem finding, collaborating and ideating solutions that will never see the light of day.




If our role is to use design as a tool to shape behavior, it is our responsibility to shape this behavior in the right direction and follow through to make sure that change happens in a meaningful way. The way we should be able to do this is by taking into consideration the context and culture that we’re somehow “intervening”

And this is something that I’ve personally experienced this in the school setting too. Like Daniela Papi-Thornton and Michael Gordon point out in their “Rethinking Business Plan Competitions” article, design students tend to focus a lot of time developing their portfolio, even though the projects are meant to address social impact issues more and more, design students care about the output that they’ll be able to show the world. But this needs to change, designers need to care more about showing the process and outcomes their decision making.  

So many things happen during these working sessions, we come up with endless amounts of ideas, prototypes, talk to so many people, but at the end of the day, what are we doing with this shared knowledge? And this is where I wonder, what does it really take to enable change?

Screen Shot 2018-03-15 at 6.05.41 PM

If we add a best practice to follow through on our design initiatives, make it part of our “design toolkit” – along with all of these activities and methodologies that we use. If none of this is possible, then at least we need to be able to set the right expectations for the people that we’re engaging.

If we get together, and ideate, but nothing seems to be changing, is it good practice to take matters into our own hands?

This is where social entrepreneurship comes into play. Like we read in Adele Peter’s article “Did this new nonprofit crack the code for building developing world housing?”, designers in this case took the matter into their own hands – they detected a problem and they decided to come up with a strategy to solve for it. They followed through and they’re seeing change happen. But as we discussed several times in class discussion, there is a justified expectation that taking matters into our own hands as designers isn’t the right path to take, policy and legislation is, which begs the question if we are fighting the right fight.

But what about practice and experimentation?

In 2015, I attended a design workshop in my home town imparted by a design strategist. Her method was the following:

  1. Gather a bunch of newspapers
  2. Pick an article that talks about a problem in your country
  3. Get a consensus within your team
  4. Start ideating a solution

We read some of the articles and we picked the subject of childhood obesity. In Mexico, 34% of children between 5 and 19 years old are considered obese. In 2015, a study confirmed that with a 32.8% of the population being obese, Mexico is now the fattest country in the hemisphere.


Our diet, once based out of beans and maize slowly transformed into a diet high in cheap processed foods. This is making our children grow up to be fatter than ever.


With the intention of addressing a nutritional learning gap, Woop is a product that was designed to teach young children to moderate their intake of food containing high amounts of sugar, which seems to be a task that is hard to do for parents.

A team of 5 people created a working prototype in a week, but we were so worried about having our prototype looking good for the presentation, that we never really worried about making sure if it was indeed contributing to solving the real problem.

And as I read “The High Line’s Next Balancing Art” from Laura Bliss, and reflecting in this past project of my college years, I kept thinking – who where we really designing for? Was it for these children that are prone to obesity, to change their lives and contribute to “change the world”, or was it for us, design students, that wanted a nice looking design in our portfolios that aimed to contribute to a meaningful problem?

All of this to say that we never really followed validated the intention of our design.

But who is a designer nowadays and who’s holding them accountable?

Design went from the traditional practice of creating tangible goods to a practice of systems thinking and it that has gained a lot of traction during the last few years. Designers nowadays have been inheriting more and more responsibilities because we are required to foster relationships with the people we are designing with. Anyone that detects a problem and decides to come up with a solution in a creative way, taking into account end user input – empathy building – is considered a designer.

So how can we keep designing and keep our reputations and stakeholder’s dignity intact?

We can’t.

Because we’re human.

But we can definitely try…

and if failure happens, then that can only translate into valuable experience.

We do need to make ourselves accountable and responsible for the relationships we build along the way.


Theory, like in any other disciplines allows professionals to develop principles which they will then apply to all aspects of their work. If our role as designers “lies[…] in encouraging behavioral change and explicitly shaping culture in a positive and lasting way” (Kolko, Misguided focus on brand and user experience), setting expectations before hand with the people that we’re engaging, and designing with is imperative. This will not only allow us to preserve our participant’s dignity intact, but also to acknowledge design as a user-focused craft to the eyes of others that don’t recognize its impact yet. Because what is empathy and rapport building if we don’t follow through with the humans we engage with.


Building a Service Blueprint for KeyUp

The last week of Q3 approaches, but we (Adam, Mary Hannah, and Mariangela) continue to validate our service idea: KeyUp, a digital solution that aims to connect young adults to training programs and supporting services, with the mission to have them attain a well-paid, mid-skill level career, improve their quality of life, and subsequently, increase their level of civic participation.

While conducting experiments, we finished putting together our website (check it out!  https://www.keyup.org/) which we have shown to a couple of young adults from whom we gathered and implemented feedback. We’ve also been spending some time on building our online presence on Instagram (https://www.instagram.com/keyupaustin/)  and Facebook (coming soon).

Screen Shot 2018-02-16 at 8.36.23 PM


This week, these were the hypotheses we tested in order to de-risk the development of our service:

  • If we manage to get 30 young adults interested in our product, we will get 5 people to participate in co-creating paper prototypes for our digital solution.
  • If we pitch our service idea to 4 stakeholders working in community outreach and also those that specialize in connecting individuals to job opportunities, they will agree to support us in our endeavor.
  • If we create social media accounts on Facebook and Instagram, we will be able to attract attention from key target audiences.

Experiment 1: Testing platform UI

The digital piece of our solution will be the main point of interaction between young adults and our service, so we wanted to make sure that the interface efficiently communicated information that is of relevance to them. In order to do this we created a paper prototype that we intended to use in a co-creation activity with young adults.

Success criteria:

We will get the contact information of 30 young adults, of whom five people will be willing to attend a participatory activity.

Actual results:
We only managed to get 3 individuals to agree to do a participatory research activity.
Reaching out to young adults that will actually follow up with us continues to be a challenge.

Experiment 2: Creating partnership with stakeholders

By speaking to an array of stakeholders, experts in the areas of continuing education and supporting services, we hoped to confirm that they supported and would use an app that would connect young adults with training programs and services to get them into middle skills jobs.

Success criteria:

We talked to four stakeholders hoping that we could detect opportunity areas to partner with them.

Actual results:

The services that we’ve reached out to have been extremely responsive and have started introducing us to other interested parties. We have now had meetings or scheduled meeting with almost every stakeholder that we identified or that another stakeholder has recommended we look into, indicating that we are approaching a comprehensive understanding of the actors in the youth workforce space. Our conclusion as a result of these interviews is that despite their active efforts to coordinate with each other, many of these communities and programs are working in silos. No one we spoke with had a list of all training programs and services available in Austin for people trying to reach middle-skill jobs, and few would even hazard guesses. Therefore, KeyUp would be filling a gap in the efforts of current stakeholders.

Next steps

UI paper prototyping

This week we focused on the researching and refining content for our digital solution.
In order to prove validation of our solution, we need to be sure that the information that we’re providing actually is valuable to the young adults we’re trying to connect to programs and services that will guide them through a sea of educational options.

After having put together a first paper UI kit in order to test it, we realized that we were dealing with an extensive amount of data about existing training programs, careers, and supporting services. The challenge lies in the fact that we can’t just google training programs and make a list of our findings; we need to actually do the due diligence of scrubbing data and provide information about programs that are legitimate and have a good reputation.

Paper prototype for UI participatory activity

Pivot: We decided to choose three industries that we would like to be “subject matter experts” about so that we’ll be able to provide the best information out there for prospective users. These areas are: health care, tech, and skilled trade jobs, all industries identified as well-paying and high growth in Austin.

Service blueprint

KeyUp potential end users

After the research we conducted, we realized that there are at least four types of users that could interact with our service. We decided to focus on the user that is in an “exploratory” phase while searching for jobs and that suddenly stumbles upon “KeyUp” through Google or social media. The reason why we decided to choose this user is because they will be following the full KeyUp journey from beginning to end.

Screen Shot 2018-02-16 at 8.29.25 PM
Iterations of Service Blueprints

We will continue working on defining what our service consists of by iterating on our service blueprint as we keep on conducting interviews with stakeholders and potential end users. We’ll use our service blueprint to prompt conversation about our service in order to receive feedback and refine our solution.

Screen Shot 2018-02-16 at 9.01.19 PM
Last iteration of Service Blueprint


Redesigning a banking app… with a twist

What we did this week

This week, we were challenged with what sounds to be a pretty common scenario in the real world:
“Your bank has acquired a new analytics company, and their boss wants to integrate their core product as fast as possible”
This is the way we learn the skills to rapidly integrate new capabilities into an existing or developing product. With the screens that we have produced until now – please read this blog post in case this is the first time you stumble upon this article – we were tasked to integrate new financial model capabilities into this new bank application that we have worked on for the past eight weeks. The very first question was – how do we do this in a way that isn’t disruptive to the already validated design?


In order to quickly ideate for this unexpected twist, I opted to use a few of the methods originally introduced by our professor – Jon Kolko – at the beginning of the quarter:

– Character creation
– Scenario
– Task assignment


In short, I wrote a short story of the individual I’m designing for. He is a 30 year old designer – not much of a planner – who has a pipeline of ambitious plans for 2018. With a project to build a house, and an upcoming dream trip to Japan, Tony wants to have his finances in order to keep everything from falling off track starting this new year.

Choosing Implementations

The client’s ask:

– An Account Overview to view spending trends
– A Recommendations feature which would allow the user to dynamically visualize how changes in monthly payments can impact the user’s account
Anomalous transaction analysis which allows the user to be instantly aware of any strange transactions
– The Money Calculator, which allows the user to know what money is available to spend at any given time

Taking into account what the “client’s” ask consisted on, I crafted a quick and dirty map that linked my character’s story with the aforementioned capabilities:


As a shortcut to storyboarding, this diagram was a useful first step that helped me figure which would be a logical flow for an individual with these characteristics to follow under his circumstances.

Some competitive analysis for inspiration

I chose a different ideation technique to get me started with sketching. I researched current personal finance mobile applications that are currently thriving in the market looking for what made them special. I then (quickly) sketched by hand a few of these features and showed them to a couple of people. They then told me which features they would like to see in a personal finance application of their own.

Here’s how that turnout looked like (the ones marked red where the preferred features) –

Screen Shot 2017-12-13 at 5.07.59 PM         Screen Shot 2017-12-13 at 5.08.07 PM Screen Shot 2017-12-13 at 5.08.14 PM

After this second round of ideation, I started to draw some actual screens and the digital product began to take form.

Screen Shot 2017-12-13 at 4.52.51 PM

Testing the design

Just like I have been doing with previous iterations of this same exercise, I tested an initial round of my paper wireframes to get initial feedback of where my ideas were going. For this activity, I used a mixture of methods like the technique called Think Aloud Protocol (which consists on assigning a task to an individual and have them explain out loud how they go about accomplishing the task), as well as a simple “show and tell me what you think” activity.

This last one proved to be quite handy, specially for a design that had so many features and little time to build an interactive prototype.

After I gathered and processed user input, I started building wireframes on my digital tool which I tested one more time with three users with the same techniques I mentioned before.

The "review my budget" capability did not look aesthetically aligned to the rest of the screen.

List of Accounts

User 1- “I guess…This seems useful. But what if I want to change my “budget”? – What if I want to have different budgets per months or per seasons? – I guess I’m saying that because Christmas is coming and all I’ve been thinking is how I don’t want to spend too much…” […]
User 2 – “What is “Compare Spending”? Is this between accounts?” – this [section?] here looks a bit odd compared to the rest of the stuff on the screen – although I see why it could be helpful.”
I got rid of the "Compare Spending" option and added an editing capability where users are able to set either a monthly or weekly budget. This way, the message will be easier to consume.


Budget DetailsShow me more

Spending Overview




Next Steps
For my next steps, I intend to research more into personal finance tools and how they can engage the user in a more efficient way and what makes current finance tools to not be as successful.

Civic Engagement Project: Walking the Walls

For the past six weeks, Mary Hannah Duhon, Adam Chasen and myself have been working on a design research project related to Civic Engagement in Austin.

Our team has been working to understand how young people between the ages 18 – 22 and who currently are not attending college, understand civic engagement, how they interact with government, as well as what are the government programs in Austin that are currently trying to reach out to them to get them involved.

This past week, we worked on conducting secondary research to further support our findings. This helped us truly define why this age group is important, as well as some historical context of the types of programs that exist in order to promote Civic Engagement among youth.

You can take a sneak peak of how this looked like in the following video:


For the next two weeks, we will be working on combining insights with the other two teams that are also working on a design research project involving Civic Engagement but with different focus statements. This way, our efforts will be combined in order to craft a single story that will persuade our audience – this December 16th – that Civic Engagement in Austin can be improved through human centered design.