Moving From Ideation to Evaluation

The first steps of the home stretch have been taken. We have been talking our idea into existence; it has been focused, and become more explicit. It exists, but it’s still got a way to go. Moving from our prior model from the end of the prior quarter, Kelsey and I have come from the complicated desktop interface and moved towards something simple. We haven’t completely decided on a name quite yet, but it exists, and for now at least, it’s called Quarters. More importantly, focused to ensure our product would actually be usable, instead of a multi-tool. Tackling a multitude of problems is not realistic, so we have focused to trying to help find stable, affordable housing for our population.

After last quarter, Kelsey and I realized we needed to make a change. But we felt pretty lost in all of the ideas, all of the things we wanted to do. Focusing on just one thing is probably the most difficult part for me thus far. We argued, and we talked, and we tried to focus. There are so many things we could do, but what should we do? We have been working on our wireframes and our testing plan to confirm we have made the right choice.

The ideal state of our product is to make use of, and potentially cultivate, a group of private renters in the local area, as well as other inexpensive housing options, who will work with individuals coming from the street for housing. Right now there is no way for people to directly connect with these renters, and the supportive organizations normally work with case management referrals. Our product would allow someone to connect with a housing organization or private renter they would be applicable for.

To do this, we want to use a natural flowing dialogue system, with simple answers, mostly yes or no to begin with, age and gender. We want to gather information and make it feel like we aren’t probing or being intrusive. Setting the tone of the messages becomes incredibly important, it has to be respectful and well thought out. Some of the screens are shown below, as I stated above, they are rough, but we’re working towards something simple and effective. 3screen

Ultimately, our goal from all of this is to decrease the amount of time people spend on the street. We have our sights set high, we’re working on figuring out if this would even help. We’re trying to answer questions on whether there is infrastructure to support this, whether we could tap into the network of landlords willing to rent to individuals experiencing homelessness, or if we would have to try to make our own. As we make the wireframes more real, questions just keep popping up, what if this, what if that, what happens here? It feels like it will be endless, but it’s also exciting.

I kind of get lost in the making and working something into existence. It’s akin to making pottery, you poke holes, push it all the way back down to a ball of clay again, pull it up, see something to change, make a ball, repeat, only once it’s well made do you allow it to dry for polish. It seems like I have been thinking about design in too theoretical of a way to this point. I spent too much time thinking and talking, and not enough time making a thing. It’s easier to work when there is something to work off of, and it has taken entirely too long to come to this conclusion. Feedback and conversations around a thing are always better (they tell us this all the time).

As we move forward to testing our idea, we move cautiously. Working with the population we want to target, it’s difficult to not want to over-promise a capability, or paint an inaccurate picture of what will happen. Deciding how to introduce our idea has been difficult. What to say about what we are testing, and how to ensure we aren’t making promises we cannot keep. It makes me feel like a bad person, but false hope is worse than none at all. Our test consists of to texts or emails our participants and talk to them about their past, and find out some basic information about their history. Using that info, we will contact housing programs in the city to see if they have availability if our participants are eligible or would be a good fit for a transitional property or something low-rent. We hope to assist with renters assistance, but this is all contingent on our participants trusting us and keeping in contact, as well as our rigor in research.

We have been setting expectations low, explaining who we are, and what we are doing, very simply. We started research, thought of this thing, and want to see if it will help. A barrier we seem to have hit here as well is narrowing our focus of participants. Our target group has been difficult to pin down, so we have participants over a range of demographics, but all sharing a few of the most key qualities.

Our pilot begins Monday, we have a few participants scheduled for the first week. As we round out the third week of this final quarter, anxiety is high. I want this to work, I hope it does, and if it does not work, I hope we know why and can make the necessary changes to make this a viable and useful product. Because ultimately our goal is to help people live stable lives.


Simple Beginnings

As students at AC4D, Kelsey and I were tasked with finding a social problem with the theme of sustainability. We were both passionate about the sustainability of affordable housing in Austin, TX. During our research into the space, we found that “affordable” housing in Austin still is not all that affordable. The price range for these units and homes are still only available to people who have income above $45,000. There are so many people who make less than this in the city, so many people who struggle to afford rent and need help or face living on the street. So we went to speak with those individuals specifically. At ARCH and around downtown Austin, we spoke with individuals about their experiences with homelessness and what it is like to try to get off of the street. We found that people do not always want to be off of the street, we saw how rapid rehousing services and permanent supportive housing services help the people who are most vulnerable. But we also saw how many people are left behind. How many people are lost by the system and do not qualify for these housing initiatives. We wondered: are there programs for these individuals? Do they have any options? They felt like they were standing still; like there was no where for them to go but down until they were where the system would pick them up again.

We found services who would work with nearly all of our research participants. We wondered: How can we connect these individuals to the support they need?

Enter Quarters, a web-based experience for connecting individuals with housing services near them. Using a responsive and dynamic dialogue system, we find what these people need to apply for housing programs, guide them through the processes, and connect them with the organization to apply.

Our Promise

We promise to connect individuals experiencing homelessness to stable housing. Using Quarters, individuals will be able to connect with housing programs catering to their needs and their situation. Quarters will also help individuals keep track of their applications, contact the organizations for their progress towards housing, and assist in getting documents required for some applications. The people who we are focusing on need structure, but do not receive any. Quarters is filling a gap left by the system and current case management, helping individuals who are in need and receive little help from the state as the system is now.

Our Business Structure

Current cost of an individual on the street is nebulous. Figures range from just above $14,000 to upwards of $30,000. One cost estimate stays the same: $10,000 to house, and give case management to, the chronically homeless of the country.
Quarter would help to reduce the cost of individuals to the state, regardless of case management. They would find housing faster, reducing their costs to emergency organizations and charities for homeless individuals. We hope to expand Quarter to include free legal, job, and financial organizations these people need as well. These additions will also help stabilize our target population’s lives beyond housing, keeping them housed, off of the street, and living for themselves.

To cover costs, we would use local, state, and federal funds appropriated for use in non-profits helping individuals experiencing homelessness. There are many funds available for people in this space, as well as a consistent public spotlight on the problem. Any lack of funding would need to be made up from donors. Whether corporate or private, donations will help cover overhead. Monetizing Quarters seems predatory; as our population is already marginalized. Funding for our endeavors would need to be appropriated from public monies or private funding. Our in-progress business plan can be found here.

Intending to Do Good – Corporate Donation and Public Opinion


Intention is an interesting concept philosophically. The question is I seek to answer is this: Does having an intention other than just charity matter if the outcome produces a social good? My immediate reaction was, yes this does in fact matter. For our intention shades everything going into a project or initiative, and things selfishly intended are not as beneficial as they could be. What then is to be said about an action with unintended consequences? There are many examples of products or services being created due to a latent need found purely by accident, or technologies arising from another research project. Michael Hobbes uses PlayPump International, a company who made water pumps powered by children playing, as an example of good intentions but a failed execution. They raised a huge amount of money, and instituted their idea in many towns. Unfortunately, though well intended, the pumps created issues. In some towns, locals were paying children to play with the pump to get water. Others show women pushing the pump around to get their water. Obviously the company did not intend for this consequence, but does their intention matter since these things did happen? Not for some people. Critique of this idea as well as others with similar unforeseen outcomes is high, and in hindsight, there are obvious mechanisms to used for evaluation to prevent such outcomes. But they wanted to do good. They set out to do good.


Which brings around the point of the authors in this post. Themed as “With the Best Intentions,” these authors all focus on different pieces of the nonprofit sector, highlighting this that work and things that do not. Mark Manson in his article Everything Is Fucked and I’m Pretty Sure It’s the Internet’s Fault, he explores the intentions of the internet. He said “There was a near-utopian level of optimism during this time. Technologists envisioned a highly-educated global population that would tap into the infinite wisdom available at their fingertips.” This is not the internet we see today. What our internet looks like is Kim Kardashian, Donald Trump, and cat pictures. The internet has done a lot of good, too. It allows the instantaneous sharing of information, and it allows us to reach people on a grand scale. Manson argues however, the internet does the opposite. The internet allows us to find our tribes and seek comfort, Manson says “The internet in the end was not designed to give people the information they need. It gives people the information they want.” This is a problem. It allows people (including myself) to retreat to the safety and comfort of an echo chamber instead of having a continued and diverse conversation. When we look at charities online, there are horror stories and success stories abound with many organizations. Scathing reviews exist for almost anything now, and it’s difficult to figure out what is true and what is not.


My contention here is that intention, when considering charitable donation, does not matter, to a point. Basically, if an entity (company or private individual) wants to fund charitable organizations, this should not be looked down on. This is my opinion, and seek to support it further. Take for instance the product(RED) campaign. This is huge, and to this point, has raised $465 million dollars for charities. A criticism of this charity during for some time was the limitation of their effects. During its inception, the Global Fund was only targeting a few countries in Africa, but now it has expanded affect to over 100 countries, and also gives money to support local initiatives. Their goal is to end the AIDS epidemic in the world by providing treatment, prevention and education. The major criticism of this organization centered around its income source, using consumerism to bolster charitable donation. Some even said it was stealing donations away from other organizations with similar missions, whilst failing to provide relief on the scale necessary. Since such critique, it seems as if they have expanded, according to their site, to a much wider reach than in 2010, but an important consideration remains—their funding source is still the same. Another point to make is this: there is no precedent for corporations making donations, save donations of profits directly to organizations. By extending this to consumerism it is a bit questionable, but ultimately, they do not have to do anything. This argument is weak, but still true. Previous to this, what percentage of sales went to charity? Marginal in comparison I’m sure.


Controversial? Most definitely. But, is use of this revenue channel bad or good? It’s hard to say, but this is unfortunately why intention becomes a large part of this distinction. You can frame the idea in a few ways. For instance, RED was created because GAP and Bono were hoping to provide social good through a new revenue stream. It’s certainly logical in hindsight; allowing consumers to choose a specific product bearing the logo and color of product(RED) and a portion of the proceeds go to charity. That’s great; it makes charitable donation available wherever these items are sold. On the flip-side, the enrolled companies are using this as a veiled publicity stunt to further their image with the public. They use this good intention to make themselves look better than other companies with prospects of gaining an edge on the competition. Because after all, the world runs on emotions–the things causing people to donate to charities in the first place. We know companies are aware of the weight of these actions.


The intentions of this movement are good, at least in part. The product(RED) campaign has raised money for the Global Fund. No one is disputing this. They have delivered on their promise of products with their brand giving profits to charity. They have also allowed private companies to increase profits by marketing with product(RED). The intention seems to be selfish in nature, and it can be a struggle to see what good may come out of this. What if instead, the real effect, though some years removed, is a precedent of charitable donation from for-profit companies and corporations.


In Alex Holder’s Sex Doesn’t Sell Anymore, Activism Does article, he describes companies like Lyft using charitable donation to a public cause to outstrip the user base of their direct competitor: Uber. Uber responds in kind by making a donation larger to cover their loss of consumer base and to cleanse their public image. Holder quotes Will Fowler as saying “Brands are allowing people to pat themselves on the back without them personally having to sacrifice anything.” The defining piece of charity is not self-sacrifice, it is the voluntary help. So, is the move to donate to charity for an overall profit for the company, and an overall net good, a bad thing?


My opinion is no. At the Austin Center for Design, the faculty teach and believe in the idea of a “social” business. A self sustaining profitable business also producing a net social good from its interactions and/or product offerings. Muhammad Yunus describes social businesses as connecting to both the selfishness of humans as well as their selflessness simultaneously. The goal of the business is to grow and scale, maintain a profitable margin, while also providing a social good or service to address a specific social problem. Seemingly, this is what product(RED) is by definition. Their model is taking profit made from product sales or credit card transactions and distributing the money made to their non profit organization of choice. It’s a simple value proposition, and to this point, it has been succeeding. Scaling and growing a customer base as well as increasing donation and the ability to make change for The Global Fund.


If we think about the other businesses who fuel product(RED), their primary goal is profit, but they also have a social good packaged in as well in offering the choice to donate by buying certain products. Whether the intention is to publicize their efforts, or gather a larger customer base, the question remains–is it not still a social good? When first considering this, it seemed to be a less than well intended campaign, but as I read Jon Kolko’s Design Strategy, Product Management, Education and Writing, I found myself conflicted. He states “[The future for designers] …lies instead in encouraging behavioral change and explicitly shaping culture in a positive and lasting way.” The intention of product(RED) could be a beginning step in the right direction for all business. As with Uber and Lyft competing with donations, other companies have joined the repertoire of donors. Amazon with their Smile campaign, alongside many others. Charity is possible alongside consumerism; in fact it works pretty well. Now, all told, none of these organizations are in the top 100 of largest recipients of donations, but the amount of money they are raising is certainly not trivial. The product(RED) campaign has enabled the Global Fund to fund local charities all over the world to address the issues at the ground level by the people in the communities. This model could be a tipping factor for other businesses ensuring their profitability and wealth is used in part to fund social initiatives around the world.


If implemented properly, models like these, percentage of purchase, a percentage of profits overall, etc, would create a large sum of money for charities. It would also be a reminder that everything you buy has a portion going to charity. There are obvious potential downfalls. The number of normal donations could fall dramatically. If people are getting their warm and fuzzy feelings from normal purchasing, why would they donate directly to the cause? Arguably, knowing everything included donation might be a catalyst to make people more charitable overall, and be more mindful of what we are buying and where our money is going. Behavior change is difficult, but much easier when prevalent. If you give people the tools and the precedent, they will adopt in kind from the scaffold built around them.


There is a lot of criticism for Amazon’s smile movement, similar to how Phu argues disqualifies product(RED) as a truly beneficial initiative. My question to her focuses on the final sentence of the article, which sounds like a call to action, “Ultimately it means that individuals need to start taking personal agency to advocate for social change and look into the how their consumption may impact others.” If these campaigns allow people to see how their consumption can impact others, why not start there? Why not have consumers push for the increased donation of corporations and for profit companies? Why not make this an accepted and necessary practice? If the expectation is that all companies will partake, then it may gain traction and proliferate. 2015 was the most generous year from the United States, with around 373 billion dollars raised for charities. The highest portion given was from individuals, at 264.5 billion, and corporate giving placed last at a mere 18.45 billion, even though their profits are far higher than the net profit of the individuals in this country. The money and capability is there, but the expectation or, better yet, requirement is not.


The next question is: how do we decide who gets the money? Money is great, but when it’s thrown into the wrong programs, the effect, dollar for dollar, diminishes. The intention of charitable donations is to make a difference in the lives of whomever the organization targets. Their execution defines how successful their endeavors are, and the hope is as much money donated as possible goes to the end recipient of the aid. We analyze intentions and the potential executions and invest that way. Unfortunately, the results are not always as projected. From small organizations just starting out, to large organizations who have been doing aid work forever, there are diverse ways of implementing solutions to the community at large. Some organizations like the PlayPump story start out successful in a single small community, scale up operation due to public support, and fail in other markets because the context and need is different.



In Michael Hobbes’s articles Stop Trying to Save the World, he gives us a concise understanding of his view when he says “What I want to talk shit on is the paradigm of the Big Idea—that once we identify the correct one, we can simply unfurl it on the entire developing world like a picnic blanket.” Here, Hobbes is calling out organizations for not testing their solutions, by hoping their method will apply to everyone everywhere. Unfortunately organizations do not always take into consideration the human component of the systems they are trying to impact. They believe, our method will work for everyone because it works for us. The push needs to be funding companies who show the ability to adapt to the level of diversity existent in human cultures. Not only does this take practice, testing, and consistent reflection, but it also may take organizations being smaller or paying more rigorous attention to outcomes.


New story community pictured above.

For this reason, organizations like New Story, who builds housing currently in seven cities in Central and South America, are wildly successful. New Story makes connections on the ground where they plan to take effect, and work with the local governments and organizations to build in the best locations and build the most effective forms of housing. Not only do they help the communities they go to by giving them shelter and building homes, but they also hire local workers which also bolsters local economies. Adele Peters tells us how New Story built 151 homes in Haiti with a much smaller budget than the six home producing initiative made by the Red Cross costing $500 million. This story highlights what is wrong with the nonprofit industry: there is not enough communication. Whether it is organization to organization, or organization to community, the channels of what will work and what is not working are broken. When you consider the transparency of New Story’s practices compared to most other nonprofits, you see a stark contrast between the moving parts and money understanding from an organization like New Story versus Red Cross. The effectivity and efficiency of the smaller organization is huge in comparison because they are able to dive deep to see what matters instead of using established business channels to solve a new problem. The highlight here is that a larger organization takes time to adapt to a new situation and can afford to fail. But what cost does their failure bring? In this case, there is an obvious net negative as funds were not appropriately used for housing and furthermore, did not make a dent in the problem of 60,000 displaced individuals. Currently, the Global Fund, the recipient of the funds from product(RED) does just that. Not only do they fund their own projects, but deliver funds to other local organizations to extend their reach to as many areas as possible. They are changing with the criticism they receive, and are making sure their solutions are applicable to as many people as possible. They are moving in the right direction.



If efficacy starts to deteriorate within organizations, why not push for smaller models or for a model more akin to what the Global Fund does? Or give money directly to the small nonprofits like New Story. Their models of empowering local groups and local people to do the work they need within constraints they understand is more effective than throwing money at a situation and hoping for the best. Jessi Hempel explains this well in The [Human] Codebreakers when she explains how Jan Chipchase and Serota undertake research projects. She says that Chipchase “believes the problem lies in their intent: Instead of entering new markets with an open mind, they approach with a strategy in place, then look for the people who prove their theories right.” In the nonprofit world, these strategies, even when considering providing for the most basic needs, can lead to failures like PlayPumps or the Red Cross housing initiative in Haiti. I’m not discounting the efficacy of these ideas, either. The Red Cross does many things well, and it is an incredibly important organization. However, failures give us the chance to learn and grow, and hopefully these situations provide their leadership with a learning experience on how to approach projects in the future.


The need for charity is real, and companies are approaching this from a variety of ways. From using increased prices on consumer goods for a cause, or taking a small portion of an ATM or transaction fee, to nonprofits being funded by the people of a country, product(RED) is trying to help. This was the intention, and it was well executed, and has raised a decent amount of money. Their charity is doing great work. GAP’s intention was to sell products that would help this effort, but also profit. Their intention was fulfilled on both ends, and the question was: Does it matter if there is a profitable intention? No. Not really. The consensus seems to be it would be better if it were just a donation, but they are increasing money delivered to a cause. The next question we sought to answer is: who should get this money? The answer to that is much more straightforward: the people who can recognize where it’s needed. Not a building corporation here, or a developer from another country. Hire the most local people and find people who understand the true needs, not only of the people and their culture, but also those who have fluency in the local regulations and laws. Simply put, we need to be taking all of the money we can from anyone who is willing to give it. If we can trick other companies to do the same and contribute by having charitable contributions be publicized, let’s do it. After all, they are the smallest contributors to charities in the United States, making up only 4% of the donations from the US. They have the power to do more, to donate more, to make a difference in countless lives, and they should be. They should do it by fueling efforts to understand the culture and by uplifting the local people instead of applying a generic solution to every area and hoping it sticks. We need to treat people like people and seek to understand them. Use our skepticism and our ability to ask why to truly understand. This is how we will make a change for the better in the world, this is the behavior change we need. Ask why and seek to truly understand.


AT&T Redesign Features and Functionality

This is the final installment of the AT&T application redesign saga. From the last post here(prior post showing development estimate details), the design has been flattened to reflect a monochromatic color scheme, and has also gone through a bit of redesign. The full set of screens can be found here(full set of screens), this file is a bit messy, but it gives every screen designed for the AT&T management experience. From the last post, the application underwent a few changes. These were to keep a more consistent spacing, padding, and text style throughout the application to a consistent experience and style. This final installment will cover the various features and expand on the value delivered by the final product.

Backtracking to about 14 weeks ago, the task at hand was to find problems existent in the current application and consider ways of redesigning the interaction to better help users navigate, use, and be satisfied with the experience provided by their wireless account management tool. There were three main findings discovered through user research. They are listed below with explanations of the impact the finding had on the redesign of the application. The manifestation of these implications will be shown later alongside the feature delivering on the implication.

Users want the capability of an employee without the hassle of going to the store. – Essentially users do not want to have to contact AT&T or go to one of their stores or kiosks unless they want to. It is inconvenient to try to make changes to an account through a dedicated management application and still have to call support for help. This left users feeling frustrated and under-appreciated while using the application, as they hoped their experience would be simple and fluid.

Which brings us to our next insight into user needs:

Users need simple, familiar navigation, obvious way-finding and feature placement to encourage error prevention.- Much of what users were saying was the application was “like a maze.” They were getting redirected, links would stop loading due to the web wrap, and the interaction with the application was sub-par at best. These people wanted a responsive, thorough application where they did not have to play a guessing game to complete their tasks.

Finally, Users want to see progress to monthly limits quickly and easily.– Even before paying their bills, users come to the AT&T application to see their monthly data, talk, and text balances. For many users, especially those with multiple lines held by their children, it was of the utmost importance to be able to see how much data was used total, as well as per device. This allowed for accountability on the user’s end, and allows users to increase these balances before incurring overage charges.

What do all of these mean?

The previous statements for user needs, or insights, led to three principles followed very closely during the design process. These are:

-Give users full account control; allow them to do everything they may want to do to impact their mobile bill or plan from their phone.

-Use familiar and build in navigation, and more obvious iconography within the application so users feel more aware of their progress towards accomplishing a task, and are more cognizant of where they should be going to complete their tasks.

-Give users as much information as possible to make informed decisions that will effect their wireless accounts. This, basically, is showing users all of their metrics in easily digestible formats so they are able to make the appropriate changes.

As stated previously, next will be what features were created in direct relation to the insights and design implications found during research. This is an abbreviated version of the full feature brief, detailing each feature and the value delivered to the user. The full feature brief and design details are available here.

Full Account Control

Adherence to this first principle is difficult to illustrate, but giving users the full functionality of the application, from managing authorized users to creating a warranty claim for your broken or malfunctioning device, the redesign has users covered no matter what their desired task. The screens below illustrate the authorized users area, the warranty claim, and the other device settings available to users.

3.10      6.11       8.4

Users Need Simple Familiar Navigation, and Obvious Wayfinding

Giving users simple and familiar navigation options allows them to use an application fluidly and easily, even if they have never used it before. Previously, the functionality of the application was buried. This was remedied with the addition of the bottom navigation icons as well as the removal of the overflow hamburger menu. Users are also always able to go home without going back, or can go back on any screen in the redesign. In the longer tasks, counters showing how many more steps to completion show users their progress to their goal. Shown below are a few screens exemplifying this. The first is within the warranty claim, showing users their progress through the task. The headings added at the top of the screens help to set apart where the user is in relation to the rest of the application. This bar shows pertinent information for the current task, and shows where the user currently is with the less specific heading at the top of the screen.

6.5      6.8       8.3

Users Want to See Their Progress to Monthly Limits

The most used feature of this application is the ability to view current data usage. Most people worry less about their talk and text limits as they are seldom reached or broken, but with the current emphasis on data usage and the movement to always on connectivity, data limits are becoming more and more of a burden. Below is the home screen showing the current usage juxtaposed to the time remaining in the billing cycle. The second screen shows the more detailed usage view, showing users their full usage as the home screen does, but also giving the individual device usage.

2.1       2.2

The final piece is the proposed release timeline over a period of ten weeks. It shows the value delivered during each release, as well as specific features related to that value. It is shown below.


Thank you for your interest in the process and outcomes of this project. It has been a long journey, but experiencing every piece fitting together to create a cohesive design, development plan, and release strategy taught much more than anticipated. Testing with users and doing research to inform a design is difficult, but the value presented in this technique is huge. Knowing the product created will have the desired effects and having the data to back up the claim is a huge confidence boost. Everything was not a happy path though, the attention to detail required creating screens is huge, the thought behind releases and thin-slicing the application requires a level of objectivity I did not have before going through this course. This project and process has given me a new appreciation for the technology we interact with daily, and has ignited a passion for user testing and design I did not have before.

Development and Delivery Roadmap

Since the last post made, the project has moved from need to be thin slicing into a tangible release timeframe. In working with the flows and figuring out what pieces are the most necessary, a timeline of events and schedule for the two developer team has been created. When thin slicing, it was understood the application needs to deliver real value to the user, but also must fit within a four week development timeframe. This activity forced a detailed inspection of the flows, but also the elements within, giving an opportunity to decide between things like custom navigation or a more speedy release. This also required another dive into prior user research to ensure the flows chosen for the initial release would deliver the most value to users. It makes sense, the more delivered on the front end, the more likely it is for users to continue using the application and more likely for a higher volume of use in general. Below is the spreadsheet used to down select flows and thin slice into workable pieces.dev_roadmap

The longer it takes to release different pieces, the less likely people will be to use the application. It reminds me of a forum post for the new Pixel C tablet. At release, it was promised to have USB-C to HDMI capability, but, over a year later, the software has yet to match their promise. This destroys not only the user’s experience with the device, but also the credibility of an organization. Finding this forum post made it hit home how important delivering in a timely fashion is important, but also how important open and clear communication from development teams and product teams truly is. Collaboration is key on all pieces of a project. This is one of the most important things I have found from my work here. Keeping users, developers, project managers, and any other stakeholder informed and as a part of the design and creation process is integral to having a successful and well thought out product. The feedback from a multiplicity of views is important to shape the vision for the future. It can also muddy your perspective, though, so keeping having a strong initial vision and executing to your plan is just as important as listening to users and stakeholders during design and development.

Planning the development was a unique challenge. When speaking with Mark, he expressed that it can take time for developers to become accustomed to an API, and the syntactical structures it requires. While planning the first release, padding was introduced to ensure both developers were able to become familiar with the API. For the first release, the Login, View Data Usage, and Bill Payment flows are the focus. After going through reviews and the research results gathered, it seemed most people came to the application most frequently for these tasks. Including these specific flows seemed obvious after looking back to user research. The full development roadmap is below. It details what developers should be working on during each phase of development, when releases are scheduled, estimated cost of hours, and scheduled progress updates.

The first release, called “Deliver,” is scheduled for four weeks after the start date. The first flows scheduled to be made are the login and view usage flows. Both are simple, and should be able to be developed in the first two weeks. The login flow was estimated at three days, and view usage at less than one, giving the development team a much longer than anticipated time to create the flow. This is to allow for mistakes or any difficulty learning the API functionality. The developers are scheduled to work more collaboratively to understand how the API is programmed, as well as familiarizing themselves with the style and workflow of the other developer on their team. The payment flow was estimated at 4 days without PayPal integration. The PayPal was scrapped in favor of ApplePay, for simplicity of integration and the ability to add a native iOS feature over a custom control for ease of programming. Given the padding on the front end for learning, there is a chance to add a smaller flow on the front end. If time allows, (potentially 3-5 working days) the change password and email flow should be started/completed depending on time allowance. The flows for the first release are shown below.

Login PayBill1Paybill2Paybill3Paybill 4

The second release was more difficult to plan. Trying to figure our what comes first was significantly easier than rating the subsequent functionality of the application. Here, it was assumed the first release would be limited to the Login, View Usage, and Payment flows. There is no allowance of the initial padding carried from the first release. The second release, Expand, creates the flows to change the plan options, such as data amounts and the talk and text plans, and the ability to change the account password and email address on file. This was shaped from user testing as well, and from some personal experience. It was difficult to decide between adding the ability to upgrade and suspend devices, but many people still visit brick and mortar stores for device upgrades, and call for more advanced device management. In my experience from working with users, they like to interact with their hardware before buying it. Having to go to a store or call to increase data on the fly seems like an unnecessary inconvenience, hence the decision to add it second. The second release is scheduled for two weeks after the initial release. This is so users are able to use the limited functionality, but expect more features to be added in the future.

The third release, titled “Process,” adds the final piece of expected value for users, meaning what the original application delivered. The Upgrade Device and Suspend Device flows were saved for the third release, for the reasons cited above, but also because of their ability to be developed in tandem. Many of the screens in the two flows are shared, with the exception of the new device selection screens. There is a limited amount of custom navigation here, and the flows are still estimated at 10 days together with the release of these functions scheduled at the end of the third release, two weeks after releasing the plan options and security flows. Continuing a consistent update pattern is good practice to keep users interested, but to also build loyalty. Knowing what the users want to be able to do and showing them you are working towards their wishes builds loyalty to the company and application. The best indication of this is the success of the update changelog after an application updates. Many people probably do not read through these all the way, but seeing the changelog and knowing the development and design teams are working to provide a better, more fluid experience provides a user a feeling of security and assurance.

The fourth and final release is labeled “Convenience” because it adds a new feature for users. The ability to file a warranty claim from a phone, or even from your phone if it’s still semi-usable seems to be a significantly more intuitive process than calling a specific warranty line for a replacement device. This flow is also estimated at 8 days even though it shares many screens with the other device flow. Due to the integration with a third party system for warranties (as AT&T does not directly warrant the phone), as discussed with Mark, the flow is expected to take additional time. Which is another reason for saving this flow for the end. Learning additional API language and coding to work with a new back end system could interrupt the workflow of the developers used to working in the AT&T specific system, as well as coming back to the AT&T system. Moving these potential hiccups to the end of the development cycle seemed logical; keeping the most valuable pieces of the application in the first releases allows for additional time to be spent integrating to a third party system after the value for users has been delivered. It is also the longest flow, taking up an entire two week development phase on it’s own, which was also a contributing factor to it being the final piece delivered.

Application development is incredibly detailed and process oriented. Ensuring all pieces are created without errors, making a detailed timeline of events and deadlines, and overall just coordinating these things without having the moving parts was valuable to experience and understand. Knowing the product has to deliver value within time a specific time constraint is stressful, even when the stakeholders and the product is purely conceptual. Feeling confident in the process, and being familiar with how to create a timeline, coordinate releases, and manage the work flow has been a great experience. The most important piece however, is understanding the necessity of clear communication first with users in the design phase to help shape the final form and vision for the application. Developers second, to understand their limitations, reservations, and input to make the product as seamless and useable as possible. And finally, the stakeholders, ensuring they are satisfied with the release timelines and the value delivered to their users for the money they are spending on your work.


The Development Dash

Moving through the development process has been both challenging and incredibly interesting. Application system support was my job for quite some time, and seeing and working with people who create these systems for the first time is a valuable experience. While working on this application design from the last iteration, I kept in mind the simplicity of using standard controls opposed to custom controls and features that would require more time to build and more resources to be expended. This section of the development project is to estimate the time for development and the estimated subsequent releases to finalize the application.

To be more clear, this estimating process would only be for the iOS version of the application. For this I am working on a timeline with two developers, working full-time, over the course of one month. This is for the initial launch of the minimum viable product, or MVP. Generally, a separate team of developers would be working on an Android version as well, therefore doubling the estimated hours worked for the development of both.

In meeting with Mark, I gained insight helping me to ground my design in reality. His opinions and recommendations are important in shaping the way the application is going to be planned for release. It was apparent while working with him that his criticisms, questions and opinions on the design were grounded in an experiential, creating, capacity, rather than my hopeful and optimistic view. Mark’s help pointed me in the direction I need to go from here. There were many notes and changes to be done in the screens, and a bit of frustration in making some decisions to cut things from the application,

IMG_0073             IMG_0072

The decision to use mostly built-in controls for navigation and functionality paid off, as these are simple to code and create on screen. The few custom controls I did have were discussed thoroughly and Mark and I worked together to down select the features, controls, and components present in the end design. This process was difficult, picking apart the screens to see which pieces were the most difficult to code and implement, as well as the time ramifications to keep them in the design.

Working with the developer to down select and thin slice is something I found to be very important. Out assignment pointed us to doing this alone, but while talking with Mark, the conversations about controls and features, and how to redesign, came organically in the collaborative setting. I was grateful to have such an experienced developer working with me and explaining each piece and question as we went through, ensuring we were on the same page.

One example of this is the password reset flow which is below, the original screens on the left and the redesign on the right. It involved a popup and dynamic icons to appear when a user typed their password. Initially these were important design elements, but the work required for this piece was too large for the value it delivers. It may be a cool way to show password adherence, and it may be effective, but there are far more simple ways to display this information. In the end, a more standard password adherence option was chosen to replace the initial design. This brought the development time down by roughly two days, and condensed the password reset and email update options from 6 days to 4, allowing it to be released alongside of another piece of the application instead of as a standalone feature set.

3.7       3.6      3.6.2      3.4.2

The Change Plan and Features data option was changed as well, though I did stick with a custom control. Instead of using a picker, Mark agreed that using the style of selection below was clear and allowed users a low chance for errors. On the back end, when I began estimating the time it would take to add these components, it requires a high level of reconsideration into using the standard controls integrated into the OS. Having two days dedicated to a simple payment structure seems a bit wasteful in the grand scheme design vs launch. Below are the two screens we were deciding between. I have yet to build out a screen with a picker for each of the elements, but plan on doing so to see how it feels. The screenshots below show the old design the three screens above and the updated design being those below.

2.3    2.3a    2.3b

2.3alt     2.3a2     2.3b2

Another piece removed was the PayPal integration. It was certainly a nice thought, but without the server side framework to support it, coding to work within the PayPal api was an unnecessary time-sink. To remedy this and add some more freedom with payment options, Mark and I decided on working with the OS payment method, Apple Pay. Integration with this system should generally be a more simple task since it would be integrating directly in with iOS and a more familiar development platform. Below is the initial screen for PayPal, and the screen for ApplePay (left and right respectively).


To get to the smallest piece of product for launch, I went back to the reviews and survey information from our research and sought what users really needed the application to do. Most people seemed to be most worried about viewing their data usage per device, and paying their bill. These two pieces, along with logging in, are the most valuable pieces of the application. They provide people with the information they want and the information they need to make decisions to manage their cell phone plan. The other pieces are scheduled for a later release simply due to resource and time constraint. Here is the tentative roadmap for release as it stands. To this point.

From here, working towards a more cohesive release schedule is the goal. Figuring out which pieces of the application should be released when is an important detail. Scheduling developers for specific tasks is also a challenge. Given their unfamiliarity with both the API language as well as one another presents a unique challenge to every development team. Thinking about a more collaborative effort between the two developers would potentially lead to a more productive team, but eats time on the front end. Then again, different work styles and an incoherence between coding styles could present problems later on.

Identifying and working through these unique challenges and thoughts has made me more attentive to the details in my design, as well as the potential problems and difficulties development presents to a designer and developer. These challenges are manifested differently, but come down to the same basics: whether a design is feasible, and whether it will work as intended. The most important take away from this entire process has been the near necessity of developers being in direct and open contact with a design team. Without open communication, the design may not be implemented correctly, or thee may be decisions and cuts made to the design without an opportunity for discussion or proper redesign. It feels like there are so many moving parts to keep track of, and in reality, there are.

Evaluation and Redesign

Last quarter in our Ideation class, we created wireframes for a redesign of the myAT&T account management application. Moving in the the third quarter, for our first evaluation project, additional think aloud user testing on our wireframes was performed, along with both a heuristic analysis, and a cognitive walkthrough. The full set of screens the evaluations were preformed on can be found here.

The AT&T application was chosen because it is in need of some serious TLC. The current state is confusing for users to navigate, and it makes it difficult for them to perform tasks they had initially been able to do with the application. Our group surveyed users to see what the biggest pain points for the application were in their mind, but also looked through reviews to see what people were saying. Most of what we heard were things like “it’s an unending maze” or “It’s very difficult to find various device plans and you cannot change the options when you do find them.” These are obviously issues with the application because these tasks are its intended use.

Creating a set of screens and flows with tasks to accomplish was the next step in redesigning a better account management experience. Much of this initial wire framing was playing with the placement of different options and how to access the important pieces of information without overload like there is in the application currently. By performing think aloud user testing throughout the process with each iteration, the design was molded by real world users and their opinions on the way applications should function. This think aloud user testing is one of the most successful forms of evaluation. Testing in this way allows a designer to understand the interaction a user has with the screens, as well as understanding and giving insight to what users are thinking as they are navigating. The hope is as the user accomplishes specific tasks, they will speak out loud, describing what they’re doing and and how they feel about the flow.

Through the most recent round of user testing, the design I created was tested by four users. The feedback I received was valuable, mostly because the things pointed out as issues in the design were things I had looked over and not even considered to be problems. The biggest issues were a normalization of language, with Ken telling me “I don’t know what suspending a device is, but this is how I do it,” and another user telling me “I hope this doesn’t charge me more for the same plan I already have, I have no way to see my total.” These pieces of information, along with the other recordings of these users, give insight into the missed pieces and the opportunities for further iteration and improvement.

The feedback received was used to directly impact the screens below, they are posted along with their predecessors. The redesigned screens help to provide more indicative language of the task users are trying to complete, as well as moving the slider for Autopay to a new screen so it is not accidentally toggled.

suspend device 18      change plan 3

The screen to the left shows the device options view, and to the left you see plan changes. Both screens are crowded and the issues the users complained of are evident.

deviceop   editplan    minutes    minutes1

The left most screen here is the redesign of the device view, and the other three are the plan change screens. They have been exploded into separate screens and show more clearly the new costs and what is being paid for.

Think aloud user testing is only one of the tools used to evaluate the application design though. Along with the think aloud protocol, I performed a cognitive walkthrough on my application flows to find problems associated with the usage and language it contains. A cognitive walkthrough uses a set of four guidelines to evaluate each screen for it’s efficacy. These are:

Will the user try to achieve the desired effect?
Will the user notice that the correct action is available?
Will the user associate the correct action with the effect they’re trying to achieve?
If the correct action is performed, will the user see that progress is being made to the solution of their task?

These four questions allowed a deeper dive into the interaction of the user with the screen, and the user testing results were backed by this walkthrough. Each instance of a “no” response is recorded and rated with severity and frequency to document how big of an issue it is, which defines when it should be fixed (either immediate and before release, or something smaller that could wait) and to show how often these mistakes are made to identify a pattern of poor design strategy. It also showed how badly the design was in need of another and another and another iteration to get it right.

In addition to having the frequency with the description of the issue and severity, there is a column in the test to add notes for redesign, so as the walkthrough is completed, there is a set of principles to move forward with in redesigning the application. Using this tool alongside user testing was interesting because with user testing performed, it allowed a new, more objective view of the design I had created, as well as a further inspection of the elements contained within it.

The cognitive walkthrough returned some modal criticism, and some exploded flows due to this. Just creating screens where they should be and eliminating the modals that should have been screens. Also, the cognitive walkthrough was the first time I stepped back from the application and asked why I did the things I did. It made me realize how important spacing and making information digestible on a screen is. You can see in the earlier iteration, everything was crammed and had modals flying everywhere. In the redesign, most modals have been eliminated except for where necessary, and all of the text and buttons have gotten enough breaking room to feel less bloated and crammed.

change plan 4      paybill 2     viewstatement 9

The modal screen on the left caused a lot of trouble with users during testing, and was consistently hit on with the walkthrough because it does not indicate well the movement. Also, the walkthrough showed that the full statement view was disconnected from the rest of the flow, as it is two taps deep with the same button name.

editplan      confirmedit      payment     statement

The screens on the left coincide with those on the left above, as do the two on the right correspond with the statement view on the right above. Both sets of screens were designed to have more space and have more indicative terms and a more effective design language to get users to quickly understand the effect of their action.

Evaluation does not stop there, however. The next step was to perform heuristic analyses and discuss the findings with the evaluators. They individually assess the application based on a set of ten heuristics (listed below), and then come together to discuss redesign strategy and other issues they may have seen during their evaluation. Similar to the walkthrough, the issues recorded are rated with the same severity and frequency ratings, as well as the potential resolution for the issue found.

A heuristic analysis is a test where an evaluator will go through the application at least twice. The first pass is to get a general understanding of flow and movement within the application, and the second is a more detailed look at the specific interactions within the tasks to be completed. This test relies on set criteria or best practices of application design, looking for things like consistent text, normal language, and appropriate way finding for the user. This test is performed, ideally, by at least three evaluators. After the tests are completed, a debrief where overall issues with the application are discussed alongside the successful pieces of the flows as well. The ten heuristics are:

Visibility of system status
Match between system and the real world
User control and freedom
Consistency and standards
Error prevention
Recognition rather than recall
Flexibility and efficiency of use
Aesthetic and minimalist design
Help users recognize, diagnose and recover from errors
Help and documentation

This list helps to determine whether or not an application design will allow users to navigate it intuitively, recover from errors, learn the system easily, and provide a consistent and visually pleasing experience. These evaluations were performed by myself and my class mates, to return the most informative results possible. The heuristic analysis further reinforced the issues users brought up in testing, as well as some more that were not touched upon within the cognitive walkthrough or the user testing.

The heuristic analyses on my flows returned nearly 100 points of interest to take into consideration when moving forward. The biggest pieces taken from the analyses were the lack of visibility of password requirements until you mess up, and the overwhelming feeling users would get when trying to edit their plan details. Both of these have been redesigned, though possibly are not much better than they were before. Below, the screens are shown in order of the prior iteration above the most recent.

paybill 2      changepassword 32      changepassword 34

On the left, this highlights where the evaluators believed the Autopay was too conspicuous and easy to toggle unintentionally. To the right are the password change flows that were problematic due to not knowing requirements before entering the new password.

payment    autopay    password     passwordreq

The order is the same as above, but the Autopay has been added to another screen, and password requirements have been added while inputting the new password.

Overall, the three evaluations of the redesigned application show there is an overuse of modals, an overuse of jargon-y language, unclear to a normal user, and the lack of space. The most valuable experience from testing was the realization that I quite enjoy performing usability testing. More importantly, it has made me take a step back while creating and thinking more thoroughly when designing the interaction someone may actually see. The full set of redesigned screens to this point can be viewed here. They are currently a work in progress, and will probably deviate from their current form.

Looking forward to the coming weeks, there is time for further iteration and development, along with testing to refine the interface to something pretty, usable, and intuitive. Soon, developers will be working with these flows to explain what is and is not possible, and evaluating based on other criteria such as expense and simplicity of development. They will help with estimating timelines for production and testing beyond the current wireframe state. I am looking forward to understanding the way development works and the challenges it presents and am looking forward to coding my own piece of the application.

Final Thoughts On Service Design

The past eight weeks have flown by, and as our work for service design comes to an end Conner and I have been looking back over the course to reflect on what we did well, and where we missed opportunities. Although we didn’t test our prototypes yet due to missed opportunities on our part, we learned a significant amount going through the process. Mostly that service design is both challenging and exciting. The tangible result of the work speaks volumes to what we have learned over the past four months at AC4D. We have an ongoing conversation with We Are Blood, so the future is still hopeful for the final result of the project, and we are hoping to continue with them sometime in the new year.

When we received this project, we had no idea where we wanted to go, and through canvasing businesses and organizations in Austin, we decided to partner with We Are Blood. We chose to work with We Are Blood because their mission is to help the community, and because they were going through a rebrand at the time and were very open to help on their journey to reach as many people as possible.

Our first days at We Are Blood were spent researching, talking to donors to understand why they donate, where they started, and what keeps them coming back. We also spoke with the phlebotomists of We Are Blood to learn about their point of view. Most of what we heard from our participants is this: they like to know they are helping people with their work and their time.


When we were working with donors at the donation center on South Lamar, we met John, who is the poster child for blood donation. He sees himself as a part of the organization and knows he is providing life for someone at the end of the day. He donates platelets every two weeks unless he’s sick. He works towards making the maximum 24 donations per year as a personal goal. He told us it’s a small action and a small commitment to make such a huge difference in another person’s life. John really helped to solidify our mission, and helped give us the motivation to work through all of the details.
After research, we worked on creating a customer journey from our donors plotting their feelings and thoughts on the map to see where pain points exist in the donation process. Creating a journey map was in my opinion the most effective synthesis we have done so far. Seeing people’s actions mixed with their feelings within a journey very tangibly shows where opportunities arise for the organization. We found nine areas where people either felt uncomfortable, or were largely not considered when the service was designed. The main points we decided to focus on were the lack of understanding donors have during the donation process, the misperception on the donor’s part of how continuous the need for blood is, and the opportunity We Are Blood has to create an empathetic connection between the donor and the recipient.


When we spoke with our donors, we asked them what would make donation better, or what would make donation more tangible for them. We heard they didn’t have any idea what happened to their blood when they left the organization. When we saw all of the steps and tests the blood goes through, we wondered why there wasn’t more transparency into this process. The organization does so much to make sure people who need blood get clean and processed blood to help them heal. And the employees know where the blood goes and know that it is used to help people, but donors are unaware of what happens once they leave.

Getting to these insights was easy once we had met John, and felt the connection to the organization and their mission to make a community of blood donors in central Texas. While we were focused on creating empathy for the donors, we began to feel empathy for the mission and became more connected to the problems they were experiencing. During our meetings with We Are Blood, they found our insights to be valuable to what they are doing and the direction they’re heading in now. Having a client tell us our work was valuable was the first step to feeling like we were providing genuine value. Our work was not over yet, however. We thought of many different ways we could deliver the value we promised (connecting donors to the recipient of their blood) and created an email that would help us to show when their blood was at a hospital waiting to be used.

Unfortunately, this is where our journey has ended to this point. Due to our later than planned delivery of our prototypes, coupled with a lack of forethought on their potential obligations caused us to not be able to test our solutions. Though we have been unable to test, we think what we have proposed would create the value promised to We Are Blood, and help to connect a larger potion of the community to their cause, and hopefully increase their blood and platelet donations.

Overall the project feels successful. We accomplished most of what we set out to do. We established ourselves as designers and provided valuable insights into an organization’s service offering. We found the breakdowns and created simple and effective solutions to help resolve the pain points existent in the system. Most importantly, Conner and I walk away from this project knowing we did our best to help an organization better reach their clientele and make a more tangible connection to them.


Our final presentation deck can be found here, and our other design briefs that detail our process and findings are in the previous posts for this class.

Flows, Fidelity, and Testing

Over the past quarter, we have been working to redesign the overall experience of the AT&T account management application. When we started, we gathered the pain points of the application by asking uses to express what they would like to do with the app, and what they were unable to do. This was done with actual users of the application, but also many points were taken from reviews of the newest releases of the applications on their respective app stores. Many people thought the app was confusing, or limited in functionality. While this seemed to be true, once working through the application, I found most of what people would like to do is there, but not displayed in an understandable capacity. The multitude of options and paths a user is able to take to get to the same screen is baffling. The application ultimately seemed to be trying to do too much for the way it was laid out. The hamburger menu is full of headings that lead to different spaces, and having the menu weighted on the right, while nice for some people, shies away from an accepted industry standard. Navigating through the application is tedious as it is simply a gui laid over a custom html browser optimized for mobile views.
What does all of this mean? It seems the actual user experience was not fully considered while the application was being developed, these pain points potentially rise from a lack of user centered design processes for the application. While undertaking the basic redesign of the application, we started by sketching simple mocks on sticky notes, just to show the flow and understand what would drive a user to move through the application to accomplish a specific task. This lead to the creation of the concept model (which is explained in an earlier post). From the concept model of the current state, I thought of what would make using the application a better experience.  A few things came through for this; a simpler navigation scheme, less busy screens, and a smaller amount of functionality. The trade off in functionality gives a much cleaner user experience and removed much of the unnecessary fluff.
When I moved to creating the first digital prototype, I wanted to make a simple navigation function for the application. My idea was initially a hidden bottom menu, allowing for a larger viewing screen. Feedback on this was negative though, and the navigation should persist for easy access and simplicity of navigation. The sketches of this are below, they were in the rougher stages of sketching out screens, so the idea didn’t make it too far. IMG_0202

There were a lot of edits, and a lot of pointers of things to change in the following iterations. The next set was still pretty rough, and I didn’t do myself any favors trying to keep things within a small frame, but liked the idea of having screens where everything was laid out and didn’t need to be scrolled. Using Wroeblewski’s idea of the bottom navigation, I changed my initial system a bit to have a consistent icon bar on the bottoms of the different screens. These were the screens I did a first round of user test with. By and large the navigation went well, other than missing a few screens that felt necessary, I had only a few pieces of feed back on the overall experience. The user told me going directly from a plan change to a confirmation felt too final for changes or purchases. This was resolved in the next iteration. I learned that things should be well accessible and spaced with weights on the more important texts.


This set of screens was also when I was given feedback on the text sizes and buttonlessness of my buttons. They were quite small and not very articulated from the background of the application. My next iteration shored this up, and added the screens I felt were missing. This set below was also user tested with no hangups in navigating to complete the tasks requested. Of the user test in the first round, the same in the second commended the improvement of the visual style and ease of use. Which made me feel great.

The subsequent revisions have been more superficial, adding proper pop up menus, text sizes and coloring buttons to set them further apart from the background. The user test for these have gone over well, too. I’ve used my roommates for testing this whole time, and the best piece of feedback on the final iteration was that “it feels more fluid now.” Which was a nice confidence boost. By and large though, text still feels a bit cramped, mostly because I have tried to stay within a single screen size. Which overall was challenging, but also limiting, but I refused to let go of my first idea, and ended up holding myself back with that worrying more about formatting for clarity than a proper spacing for all of the text on the screen. Below are some shots of the main screens in the final pass.

changepassword 31 change plan 2 change plan 1

During the time we have off, I plan on revising and testing more, to have a solid set of screens for the beginning of next quarter. I’m happy with them and they function as designed according to testing, but it still feels lacking. Doing this again, I would have to say I would certainly use longer screens to as not to constrain myself to a small size and try to normalize a text size and reposition after it’s been formatted once. I would also make grouped pieces and paste them to all artboards to have a well a laid framework throughout the application.

Week 7 : Reflection

Looking back over this quarter, if I had it to do over, there would certainly be some major changes in process flow and starting things earlier than I had thought necessary. It was naive to think our insights would be easily won. This point however, does not make the work any less powerful or rewarding. We are still getting to the understanding we wished to ascertain, albeit slower than originally planned.

Mainly what I’ve found is a need for better management of multiple projects and setting clear goals for each piece of each project. Today in the research class, a guest from Aunt Bertha came to talk with us about the theory of change, and the value arising from mapping the path of influence to get a handle on where impact could be made, and if that impact would be worth pursuing. Theory of change is still something I have not fully grasped, but it seemingly can apply to many different pieces of work. Making these diagrams can help lay out what impact you are trying to make with any deliverable or any artifact created and help you get to the meat much quicker than without a plan. Thinking back over my life and the things I have worked on, I realized that I have never really done this. Never truly set goals to fulfill or asked myself what it will take to achieve those goals. It’s a strange thing to be pulled out of my world in this way and to be looking to something as simple as a diagram to help guide me in everyday life.

Looking at the past six weeks, I wish I had been more specific setting goals and deadlines for them to be met. I’ve gotten all of the work done that’s required, but I can’t help but think to myself, “What if you had time for another iteration,” or “what if you had done this differently.” While reflection is a necessary part of learning, it seems as though more often than not, it comes later than is advantageous. Since it has been such a rush this quarter to complete work and complete research, I have not had much time to reflect on what I’ve done, but spending time in the data this week and looking over the groupings, I am beginning to feel like this is what I should be doing. My mind took its time in thinking I could do this, and do it well, but I am feeling better about the process overall and believing in the value human centered design has on the world. It has been a difficult road, and I never thought such a short amount of time—four months—would simultaneously pass so quickly, yet feel like an eternity.

It has however, solidified my belief this is the proper path for me. Working with people, but more so for them has always been my goal. I know there is difficulty and I know there is opportunity to help, but until now I felt helpless to affect change.One thing I’ve found has helped was learning how to keep a continual conversation with participants even after the interview has ended. I can hear these people giving me answers to questions I have for them now, even though we spoke weeks ago, consistently and clearly. Wanting to know how they would feel about certain things, or what they would tell me if I asked them where we should be looking. The sentiments expressed behind vocabulary and spoken language are increasingly more important. It reminds me of Derrida’s The Work of Mourning, where he contends that after death, we continue conversations with people and are able to hear their active voice from beyond their existence. Working with utterances feels very much like this, like a continued conversation with a person after their physical representation is less than immediately accessible. While these participants are still alive, the ideal holds true. Joan Kirkby calls this the remembrance of the future, she posits their words are a call for transformation and responsibility to them, and in the cases of our participants, I feel this more and more. I feel their needs and their goals and dreams as if they were with me now. While their motivations for certain actions will remain a mystery, their words and hopes and what they wish to achieve is fresh and pressing in my mind. This conversation wills me to work hard to make a difference, it makes me want to make a change for them, not to leave a mark, not for myself, but through others is the true fulfillment.