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.

Week 6: Understanding

Moving through our research project has been an interesting experience. From speaking with our participants, to the focus shift we’ve had in the past weeks of synthesis, everything seems to be fitting into place. Our shift came when we unknowingly moved from the topic of understanding affordable housing in Austin and the barriers to getting into affordable units, to exploring the barriers to entry into transitional and temporary housing for individuals experiencing homelessness. While there is an issue of affordable housing all over the city, at the bottom, there seems to be less and less availability for a growing population of people disenfranchised by the city’s growth. Many of these people have jobs and are doing what they can to get services through the city to assist them, but there simply are not enough open units for these people to live in. We’ve found a few key things in our research, seemingly all worth exploring.
Kelsey and I found quite a few interesting patterns in our participant’s words and stories. Many feel like the city doesn’t do enough to help them, or that there is corruption at some level that is preventing all of the money from trickling to where it should go. Eddie calls out specifically the types of cars people working for the arch drive, and Francine told us about the case workers going through boxes at Salvation Army before giving the clothes to the women who need them. These people feel like the system they’re interacting with is not there to help them, it’s there to keep them separated and keep them down. This may not be the reality, obviously many of the organizations working with individuals experiencing homelessness in the city are doing their best, or at least what they can, to help these individuals find stable housing. But with the lack of housing available, and the ubiquity of wait lists on nearly all rent controlled or income based communities in the city, hope can be depleted quickly.
Todd is a good example of how the system should work, and how it doesn’t. A few years ago, Todd found himself in a similar situation to the one he is in now. He was living on the street, and working with case workers at the ARCH and other organizations to get housing. In 2010, he was able to find housing and get himself a job to sustain that unit himself with a bit of help. Now Todd says that case work and services like this have changed. They’re no longer working, specifically Todd told us that case management has gone down hill and you’re lucky to even be paired with a case manager if you’re not high risk. This is a common sentiment based on the way case workers and services are assigned. Stepping back from this, I can see the difficulty in how to ascertain who gets housing and who does not. From a top down view and from a perspective of ethics, how does one put a value, or a risk analysis on a human being?
The coordinated assessment test tries to do just that. It uses yes or no questions to put a numerical risk value on how likely an individual will be to die or have trouble living on the street. The higher the number, the higher your risk. People without physical or mental disabilities, or people who are able to work consistently have a difficult time even getting onto case management through ARCH. What is difficult for me to understand with the coordinated assessment is how someone went about creating a cost/risk analysis of a human life that does not also take into account a volition for change, or the basic drive to change a situation. The entire process, when it comes to putting a survival rating on these humans, is sterile and industrial. There’s no account of a person, just of a human.
Ethically, it makes sense, looking out for those who are most “vulnerable” but hearing Francine’s story of struggle to find shelter for herself and her daughter, and her unborn child, and hearing how she’s not a substance abuser, she has a full time job, but she’s unable to find a place to live without assistance. Escaping an abusive relationship was her utmost priority and now she’s facing having to return or live on the street and risk losing her children. Right now for Francine, there’s no answer, nowhere to turn she hasn’t already, and time is running out.
But people get housed from ARCH all the time, people who are higher risk and higher “need.” People like David, who’s had a rough go. He was displaced during Katrina and In the first weeks of 2008 found himself homeless in Austin after losing his FEMA money and losing his job. Since then, David was living on the street, spending most of his days drinking 12 packs of Lone Star tall boys, until he decided to have a “fight with the concrete” as he said. He ended up breaking his wrist and getting a bit battered up and going to the ER. After this visit, he was made to take the coordinate assessment again, and it said he was a high risk and he qualified for rapid rehousing and was placed into a unit.
It seems like some people with an equally, or arguably higher, level of need are being passed over. The city is doing what it can to house all people who don’t have a place to go by creating programs for housing, new buildings with donations from the state to nonprofit developers, and land grants to help build those properties, but there’s still not enough space. It seems as the problem is solved, it just continues to grow.
As Kelsey and I narrow our insights down, there’s certainly an opportunity here. Looking at the way people are rated for cost to the state and not their likelihood of self-sustaining is baffling. The solutions are still muddy though. Is it build more housing for people in these types of situations? Is it set up more programs or even better transit from places that are less expensive to live? We’re working to come up with ideas to help ease this tension and ease the difficulties people have while seeking housing.

Early Insights into Affordable Housing

After wrapping up research at the beginning of this week and diving into the data, we have reached a few preliminary insights. Let’s backtrack a bit though. We had spoken with people at the top and bottom of the space, but were missing a middle ground. With interviews spanning the case worker, housing designer and architect, and a non-profit board member dealing in tax credits, as well as the lowest end where people are in dire need of housing, the middle ground of “normal” affordable housing was missed.
We spoke with Shannon on Sunday and learned that for her, affordable housing came in the package of a single bedroom unit in Austin with a price tag of 1100 a month for someone making 20-30k a year. If you think about it, the requirements for rent in the city don’t even technically allow someone at this rate of pay to rent a unit this expensive, they require at least 3x the amount of rent in many cases. This apparently scales with the cost of units, because someone making $20,000 a year may have difficulty covering all of their other bills (utilities were not included) if rent was a significant portion of their total income yearly. Someone making $20k a year and paying 13200 in rent before paying any bills doesn’t seem like it truly falls on the affordable side.
For Shannon, this wasn’t the biggest issue because she had supplemental income from her parents supporting her, as she had just graduated and was trying to start a career. Not everyone has this however and it seems like it would be difficult to cover all of their expenses and pay for rent on time each month. The problem then, doesn’t seem to be isolated to a single cell of affordable housing. All over there seem to be inconsistencies like this and it leads me to believe landlords use the “3x rent” requirement to further weed out people that are in the very low income bracket. This gave us insight into these manufactured barriers to entry that accost many people as they look for housing.
We have heard from multiple participants that these barriers are largely manufactured for income requirements, as rent assistance is available to many of the people living in the very low income bracket. As we have worked through a bit of synthesis, patterns like this have started to emerge, but more so we have seen patterns in the behaviors of the people interacting.
Beginning with something Matthew said to us that now he has a place to stay, just a room to rent, and he’s still on a list so “it’s all good.” Matthew is 67, lost his wife 4 years ago, and had been homeless after being in prison for 17 years. He changed his life when he got out though, and made an effort to truly turn things around. He told us after prison, he was picked up at the bus station and taken to a rehab facility that he stayed in until it closed. His hope is inspiring, but it’s unique. Many of the people we spoke to feel like they have no hope. Eddy, for instance, was released from prison two days before we spoke to him. He was on a list for housing before he got picked up, and while he was in prison, he became eligible for the unit. Now, six months after being picked up on a false charge, Eddy is no longer eligible for housing, and feels discouraged being back on the streets, right back where he was three years ago. On a list.
His experience is typical from what we’ve seen. Regardless of criminal background, financial stability, or medical conditions, wait lists are the story for most people. There are a few cases where we’ve found an individual rapidly rehoused and they’re walking on cloud nine. George is in this situation now. He recently was given an apartment because his Coordinated Assessment showed he was a high risk for staying on the streets. It seems like people are more hopeful and more ready to change their lives and work towards a better end goal once they’re housed. Cultivating hope and helping to keep people hopeful helps greatly in changing their situation, but the wait lists and lack of communication to people waiting for housing from case managers or other advocates seems to be depressing more than anything. This is a result of multiple things, whether the income or criminal background barriers, or more simply, the lack of availability of units for people in situations at the very low income bracket.
As we dive farther into the data, more and more patterns are arising, looking from things like drug abuse, mental health, victims of theft, or more commonly, people fighting with the system for help. We have complaints about case management, saying they don’t do enough, but case managers telling us they work with people as best they can. There are conflicts, and people working on resolutions, but there are barriers at every level. From the income requirements and landlords denying housing vouchers, to developers trying to work with the city to buy land to create more affordable housing opportunities for people in the city.
It feels like there is still a piece of the puzzle missing, but largely it may be due to needing to further work with the data and understand what it has to offer. Hopefully as we move forward, we will gain stronger insights to help narrow our focus area and lead to solid design principles to help alleviate the problem space. Right now, it still seems like too big of a problem to tackle, but I know there are areas we can work with. They are just a bit elusive yet.

Week 4: Shattered Perceptions

Being behind in research helped to frame this week for me. There was a lot of catch up to do, and I think we did it successfully. There were also many opportunities for me to feel closer to people I don’t know more than any other time since I’ve moved to Austin. Speaking to individuals at the ARCH is an eye opening experience. I had a lot of premade judgments before going to talk to our participants this week. After speaking with a case worker and managers of non-profits who try to help ease the space of homelessness, it seemed like there was plenty of infrastructure to allow people to get into housing and get off of the street. The reality of the situation is radically different. While there are people who live on the street and survive off of the kindness of the system and strangers, many of them try to help themselves but are unable to because of limitations of the policies or limitations of the availability of housing in general.

All over Austin, there are people on waitlists that desperately need help. There are people with health problems, struggling day to day without a home while others with housing spend their nights outside by choice. It was eye opening to hear these individual stories that bring people into the situations they find themselves in. There are a variety of backgrounds, a variety of people, and a vast difference in mindset. One thing that is mostly constant is a hope for the future. Often it seems hope is all individuals experience homelessness have. We spoke with Francine this week, a mother who is doing everything she can to keep herself and her daughter safe and fed. She has a full time job, a case manager, and a temporary room with the Salvation Army. She uses the free childcare they offer during her work hours so she has somewhere to take her daughter while she works to support them both. Francine has run into several issues however. She doesn’t make quite enough money to have three times the monthly rent, as required, at most apartment complexes in Austin. She also has not been able to get into affordable housing due to long waitlists and extremely limited availability. Within the next month and a half, Francine is facing another crisis. After leaving an abusive relationship to go to the women’s shelter, she’s still unable to find housing to sustain herself. She’s on day 55 of 90 staying at the Salvation Army, and when that time expires, she and her daughter will have nowhere to go.

Most people would agree that everyone should have a home, it seems inarguable, but as we found speaking with Ace, a case manager for Caritas, it seems the biggest barrier to creating more affordable housing is the idea that while everyone should have a place to stay, many people qualify that with “but not in my backyard.” This is also a common theme, while we were speaking with a Foundation Communities design lead, he said this hasn’t quite been a huge issue, they do see people outspoken against affordable development in many areas of Austin.

This week what I’ve learned doesn’t make me feel good about humanity. Normally, week to week, we either learn new techniques to help make things better, or we find opportunities to make a difference, however small, but this week was starkly different. I found that normal people, doing everything they’re able in their given situation, are still not able to make it into homes more often than not. Francine’s case is unfortunately not unique. She’s luckier than many though, she didn’t have to wait long to get into the Salvation Army Shelter, she has no criminal record, no evictions, and a full time job. She qualifies for assistance programs, but the housing for her simply isn’t available. Other people we spoke to do have these barriers to entry into the affordable housing that is available.

Charlie, for example, has been on a waitlist for housing for three years. Before this, he was on another waitlist for three years again, which never resolved to anything. He self-resolved and found himself an apartment through Front Steps, paid his rent on time with his disability and housing voucher, but was evicted wrongfully after another company acquired the property. This caused him to have an eviction debt that he couldn’t pay off, and without paying it off, he was not eligible to rent an apartment. The year after he was evicted, he had surgery, and has had ongoing health issues, but due to his prior convictions, a lack of social security card and ID, and his eviction debt, he hasn’t qualified for housing, until now. Six years of homelessness in Austin, predicated by 19 years of being on and off of the street, and Charlie is excited for housing. He is however dubious as to whether everything will work out. The most important thing for Charlie is his dog, Bubba. Bubba has to be able to come with him, and I could understand why, as while we were talking, Bubba curled up at my feet and fell asleep with his snout on my feet. Charlie’s situation is probably one of the more common we’ve encountered during our research at the ARCH. Prior convictions and eviction debt, and sometimes a lack of income on top of that due to the limited amount of money SSI or SSDI provides.

Obviously this is a problem. These individuals often do not have the means to be employed, whether due to a physical or mental disability, and their monthly checks of $733 nowhere near cover more than double rent in over half of the city. Even with housing vouchers, most of these individuals are priced out of normal, unsubsidized housing in the city, and even many section 8 properties since many may not qualify for the voucher. These individuals are only part of the story, though. Later on yesterday, we were talking with individuals outside of the ARCH that either hadn’t gotten a bed for the night, or didn’t try.

The latter is what we saw, people choosing to sleep on the street instead of lining up to sleep in the ARCH. The last few people Kelsey and I spoke with last night had stories much the same as others we had heard. The main difference was how they were dealing with it. I’m going to go back a bit here before we move forward though. The first day we went to the ARCH, we spoke with Thomas, who chose to go back to the ARCH after being off of the streets for a few years because he wanted to be humbled, and because he was unhappy where he was working. He knew he couldn’t sustain his apartment without his income, but he made the decision anyway. Thomas told me how some people he sees at the ARCH are happy where they are. He isn’t happy about being there, but he knows that he will get another job, and get another apartment before long. Thomas told me he doesn’t understand some of the people there, they just spend their days smoking K2 and hanging out, not trying to change their situation. When he explained this to me, I thought there had to be a reason. Either they were fed up with the system not helping them, or they had a plan for everything to come out alright.

Last night, speaking to James and Colin, I found that my assumption was wrong. They are fed up with the system in a sense, but they don’t have plans. They choose to be there. Either from a sense that it’s the only option currently, or from the blunt of K2 they had just smoked, they seemed happy, and said they were happy. They’re part of a community of people, and they’re where they want to be. We talked for a bit about what they were doing, and why they were there, and both expressed a similar sentiment of not knowing what was going to happen next, and not really worrying about the future. As Colin said, “I’m happy right now, I’m content, and this is what the world is giving me now. I’m taking my time filing for disability. I’ve discovered a lot in my years of craziness, especially the past two and a half, and this is where I’m at, and I like it…no I love it.” James echoed this sentiment, saying he just came from Houston, and has been on the street since 16 when he left his parents’ house, and hasn’t looked back.

For me, this is a difficult to wrap my head around. Pleasure seeking in its most pure form, living a truly mean life, seems almost Ascetic, but simultaneously indulges in what one would normally deny. It’s a Cyrenaic lifestyle, something that’s not been discussed publicly in millennia, seeking pleasure outside of the realm of normal philosophical or knowledgeable pursuits, above others. Our society doesn’t cater to this type of existence, and looks down upon it. But there’s something freeing in the idyll (I use idyll due to the unsustainable quality of the lifestyle) of living for oneself, wherever that path may wind. Ultimately, I walk away from this week of research and reflection highly conflicted, but with a changed view of what a homeless individual is, and a greater level of respect for them beyond what I could have conceived prior.