Validating a Hypothesis: Grocery List Optimizer

My team and I have decided on an idea for our final project, which is to create a grocery list optimizer (the name is still a work in progress). The mobile app will look for money saving opportunities within someone’s grocery list as well as making healthier recommendations. Moving forward with this idea we need to validate that we are building the right thing.

I had the urge to want to jump to creating the product now that’s it has become more of a concrete idea, but this is idealistic thinking. For all we know our idea may make sense theoretically, but in the real world we could possibly be missing the mark. This is why we will be conducting a pilot for the next 4-5 weeks. The point of the pilot is to validate our idea through a simplified version using manual tactics rather than creating the mobile application. In the end, it could manifest into something completely different than a mobile application.

The first week we are employing a strategy of testing our idea in person while our participants shop to capture as much feedback as possible. There are also small nuances we may not be thinking about that we will be able to observe to better our product. Although I’m excited to start getting people’s opinion, my mind was jumping into simulating the idea as close as possible for “accurate” results. This landed our group into focusing on the wrong thing, which I may have been facilitating a bit. There are many grocery store apps on the App Store, most of very poor quality. As we continued researching what currently exists we learned that HEB has their own app with many of the features we have planned on incorporating. I saw two things happened because of this.

  1. Momentum in our creation seemed to slow because “someone else is already doing something similar”.
  2. It limited our mind as to what was possible and began to slightly feel defeated.



Because of the similarities, my mind was wanting to try to leverage the already existing system to help us conduct our pilot. I was excited to test using something that was so close to our idea because I felt then we could really focus on the details that separates us apart from them. The point I was missing is that the purpose of our pilot is to not simulate our system, but simulate the core value our system is providing.

The advantages we are providing over the HEB application, and many others in the grocery store is that:

  1. We are being more proactive about money saving opportunities.
  2. We aren’t limited to working with any singular grocery store chain.
  3. Most importantly, we are helping people eat healthier in an incremental manner
How it works

During our pilot, we have some primary assumptions that we are looking to confirm our hypothesis and whether or not our idea should manifest into another form. After all, we could design an award winning mobile application, but if the application doesn’t meet people where they are at it will ultimately fail. The assumptions we are testing include:

  • People use grocery lists, and if not, they will use one
  • People will choose a healthier option if prompted
  • People will choose a lower price over a brand they like
  • People are willing to leave brands and items they’re used to
  • People generally want to eat healthier
  • People will eat new items they purchase
  • People will be more likely to buy a new item if they get the new item before they get the original item

To quickly kick start our pilot and start gathering data we reached out to our friend and family network and asked people to send us pictures of their pantries and fridges. The purpose of this is to further understand the variety of food people keep at home, as well as starting to identify opportunities where we can begin making recommendations. One realization this made me think of is that by looking at individual items it could possibly feel healthier than what the end meal is being created. But this doesn’t exactly tell us what is being created when items are combined. This should be a consideration moving forward.




After spending a week testing our idea out in person we want to back further out to see if we can have the same affect without being there in person. We acknowledge that by conducting our test it in person we are introducing a bias that wouldn’t normally be there if they were shopping by themselves.  So it’s important to learn from this first week then run the rest of the pilot as remote as possible. Our goal is a minimum of 15 tests, ideally we would work a number of people for multiple weeks to learn how they shopping habits might evolve, even if in a relatively short period of time. Just because someone eats healthier one week, doesn’t mean they’ll continue down that path.

There are so many small nuances in using coupons and trying to save money while grocery shopping, this might have started to distract a little from our primary goal: helping people adopt a healthier diet with small gradual changes. The money saving techniques are how we plan on providing more value to the user to have more inclination to use our service, but we can’t let that turn us away from our primary goal.

Lastly, a very important detail we are addressing is the fact that we aren’t subject matter experts within the food space. As we started fleshing out the pilot and were forced to start making recommendations on real lists, we learned when fact checking the recommendations that were coming to mind that they weren’t as healthy as we originally thought. This is where it’s vital for us to bring in nutritionists and/or dietitians into our pilot. We have a meeting scheduled with a dietitian this week to help us navigate recommendations within our pilot. When our product becomes a reality we will work even closer with a dietitian, if not hire one, to ensure the quality of our product is where it needs to be to make healthy food recommendations.

There are even more questions that are derived when trying to build an idea than when creating an idea. I am excited to receive feedback from our pilot and mature our idea into something that will help people adopt a healthier diet. If you’d like more detail of our plan you may read our pilot plan deck.

The Outcome, Regardless of Intention

As designers, everything we do from the type of problems we work on solving to making the choice of using a radio button or a check box stems from intention. Without intention, choices are made blindly causing an arbitrary execution. I believe intentions are important within design, but where the conversation becomes a bit muddy is when we began considering the outcome of our intentions. There are examples where, despite the best intentions, the outcome is less than ideal, and vice versa. This leads me to ask the question, “how important is intention when the outcome is what creates impact?”


One space where this question applies is when developing for the emerging world. Most people are familiar that there is a good amount of effort in assisting developing countries who are less fortunate than our own. There was an effort to provide clean water to people who did not have easy access. Michael Hobbes explains, “It seemed like such a good idea: A merry-go-round hooked up to a water pump. In rural sub-Saharan Africa, where children are plentiful but clean water is scarce, the PlayPump harnessed one to provide the other.” In theory this is a fantastic idea, except when the outcome is examined. After implementing the PlayPumps, Frontline returned to see the impact that had been created. They, “Discovered pumps rusting, billboards unsold, women stooping to turn the wheel in pairs. Many of the villages hadn’t even been asked if they wanted a PlayPump, they just got one, sometimes replacing the hand pumps they already had.”


The biggest opportunity in this example would have been to reach out to the recipients of the PlayPumps and learned how this effort would have been received. If the community wanted this or if they would even use it. It would have been discovered that this solution may not have been the best solution to the situation at hand, or even a solution at all.


There is another example where working with the developing world was in fact successful. New Story was able to build 151 houses in Haiti which ended up housing 1,200 people where as the Red Cross changed course after only building six houses even though they had raised half a billion dollars for the cause. The Red Cross, “struggled to attract residents because,’ the areas they planned on building were, ‘too far from basic needs like work and food.” The cofounder of New Story, Alexandria Lafci, explains, “This is what participatory design is so crucial and is something we incorporate into all of our communities. We ask families for their input about the location, the style of home, broader community needs, etc.” The findings led New Story to deciding to build their community only about 10 minutes away from their jobs and support networks. Because of this, the community was in a position to adopt the housing because it fit into what was important into their own personal life, unlike the PlayPump example. They are expanding to launch similar efforts in El Salvador and Bolivia, but the models will be slightly different because each location affords unique needs. Participatory design will be used once again to accommodate the small amount of income that exists (unlike the population in Haiti) and will implement a pay it forward model to invest in future communities. Once again, tailored to the specific needs of the population New Story is designing for.


A mix of these two efforts include the example of New York’s High Line project. Robert Hammond had the idea of “turning a disused elevated railway on Manhattan’s West Side into a high-design ‘linear park’. He thought it would attract maybe 300,000 visitors a year.” The problem lies in that, “he and his co-founder Joshua David didn’t really think about what the High Line could do to the neighborhood, apart from adding a little extra breathing room.” The project was successful in the sense that it drew new business and condos, as well as the expectation that it will generate $1 billion to the city over the next 20 years. Where the project was unsuccessful is that the park didn’t appeal to the direct neighborhood it was originally intended for. On either side of the park were local housing projects, which consisted primarily of people of color. The traffic the park ended up drawing were predominately white and mostly tourists. Reactions to the park consisted of feelings that local residents, “didn’t feel it was built for them; they didn’t see people who looked like them using it, and they didn’t like the park’s mulch-heavy programming.”


During the project locals were asked questions similar to which colors they liked, not necessarily what specifically they would like from the park itself. Because of this Hammond admits that, “ultimately, we failed.” Where they story begins to change is when you look at what happened next. This self proclaimed failure led Hammond creating the High Line Network, which is a coalition of designers and planners building adaptive reuse parks in the High Line mold. The entire purpose of the network is to further examine how to improve neglected neighborhoods, without pushing away they very people they intend to serve. A component of this organization is conducting listening sessions to hear feedback about his project, which started a number of new initiatives including paid-job trainings and further development on the two housing projects previously mentioned. These efforts are due to participatory design, which leads to a more successful execution of intention.


Another frame within this conversation is that of corporate philanthropy. One side of this conversation tends to lean towards a negative view that corporations are only incorporating philanthropy into their business model in order to sell more goods, regardless of the outcome. For example, the PRODUCT (RED) campaign is a campaign founded by Gap that has asked companies to create a red version of their product and donate a percentage of the proceeds towards the HIV/AIDS effort in Africa. One could argue that this effort feels ingenuous due to the fact companies are pushing commoditization as an effort for social impact. They see the effort as saying, “if you buy this product, then you’ll save lives.” In fact their slogan is quite literally “buy (RED), save lives.” On one hand I completely agree and there is something unsettling about this effort that doesn’t seem to fit the effort.


With that being said, despite some room for improvement in transparency, the organization has raised $465 million dollars and claims to have impacted over 90 million lives. It has allowed doctors to spend more time on their research and slow down HIV transmission. This is where intention becomes tricky. I can see the intention of this effort coming from a place of genuine interest in causing an impact, but I can also potentially see the motivating factor being that to drive higher profits via a philanthropic effort. This is a detail we may never fully know, but one fact remains: the amount of money raised to increase resources for a social cause. If this is the outcome with either intention driving the effort, then how much does it truly matter? An opportunity was identified to raise a significant amount of money for a good cause and was acted upon. Yes, I would love to believe that the effort was genuinely altruistic, but if you were the one directly benefiting PRODUCT (RED), does it change the outcome of the benefit?


Initial intentions in design can be come from a variety of motivating factors, but I would argue that the outcome is what is most important. Action can come from a place of good intention yet have negative outcomes, while it can also come from a place of poor intentions and have positive outcomes. Regardless, the outcome is what we are left with whether that be further conversation, fundraising, or housing for people in need. Ideally, we should consider the outcome while we are designing in order to optimize our intentions.

myAT&T Mobile App Redesign – Feature Brief

If you’ve been following along you’re familiar that we are approaching the end of our myAT&T mobile app redesign. During this time a significant amount of work has been done and can feel overwhelming reflecting on what exactly has been done. This is where the benefit of a feature brief comes into play.

A design strategy feature brief is a stand-alone document that condenses the design process into a digestible format. To accomplish this, this document includes:

1. Behavioral insights and principles associated
2. High-level value promise
3. Capabilities and the features associated
4. High-level roadmap

Behavioral insights are derived from research and help shape what the product will become by evolving insights into design principles. My behavioral insights and principles are as follows:

1. Customers use a “set it and forget it” mentality when it comes to managing their mobile phone account. Therefore, Instead of trying to do everything involved in managing a mobile phone account, our product should focus on bringing the highest valued features into a simplified experience.
2. Customers are primarily interested in viewing their current data usage compared to their data plan limits. Therefore, Our product should give quick and easy access to current data usage in an easy to digest visualization.
3. Customers expect a familiar and smooth experience when managing their mobile phone account, especially from their phone. Our product should use standard navigation and patterns that are already familiar to a user.

A value promise is a succinct statement that is further derived from the design principles created from research. This statement is formatted in a way that paints a clear picture of the primary intentions of the designed experience. It is also used to measure if the product was in fact successful when compared to those intentions. My value promise:

We promise to provide personalized value while creating a streamlined and familiar experience.

Next in the feature brief are detailed capabilities of the product. The capabilities will typically include what value the capability provide the user, the features involved to create this value, and one or two visual screens to show how the value and features manifest within the design. Below is an example of my data plan capability.


Capability - Data Plan 1

Capability - Data Plan 2

The last section of the feature brief includes a roadmap very similar to what was created previously. The difference is that the roadmap included in the feature brief is displayed at a higher-level eliminating specific dates or timelines. It should be relative, not absolute. The reasoning for this is that it could potentially create unrealistic promises that may not be fully realized at this point.

Roadmap v1.0

The feature brief is a valuable stand-alone document that is able to give a brief summary of the most important aspects of the product being created, without having to be there to explain anything. You may view my feature brief in full in the link below:

myAT&T Mobile App Redesign – Feature Brief

If you would like to review the entire process involved redesigning the myAT&T mobile experience you may use the following links:

Redesigning myAT&T – Storyboard Flows
Redesigning myAT&T – Sketches to Digital Wireframes and User Testing
Evaluation my myAT&T Mobile Redesign
Making myAT&T Designs a Reality – Part 1
Making myAT&T Designs a Reality – Part 2, Roadmapping
myAT&T Mobile App Redesign – Feature Brief


Making myAT&T Designs a Reality – Part 2, Roadmapping

Last week we looked at the first steps involved in turning our myAT&T mobile app redesign into a real working product. This included looking at technical capabilities and estimating how long it would take for each feature set, or flow, would take for a team of two developers to create. This week we will be looking at how a product manager (in this case, me) will use this information to thin-slice each screen, prioritize, and create a roadmap to bring the designs to life.

The designs were originally created as an ideal state, without time and resource constraints being a consideration. Now that we actually need a plan release cycles, less impactful features become less of a priority to be able to release updates to the app on a regular basis. We can get to a faster release cycle by thin slicing our designs.

Thin-slicing is the act of reviewing each screen and asking how necessary each individual control is on every screen. Next, you remove components that provide the user the last value in achieving their goal while still adding value to the user. This was difficult due to the fact that I had created these screens with intent for every design decision. It became my baby.

My strategy for thin-slicing was to make several passes of the screens and ask myself how necessary each control, or element on the screen, was important to the overall goal of the user. I combined this answer with the estimations from development, findings from heuristic and cognitive evaluations, think aloud protocol, and what would ultimately be most useful to the user. There was also a consideration of not cutting some features in the first release because they could be reused throughout the rest of the app. With a front loading of reusable components, you are able to get a more valuable product quicker to the user.

One example of this was an in-app notification, primarily indicating that a task has successfully been completed. This was something I added after my original design evaluations and after re-testing the feature it was very-well received among users. The ambiguity was gone. While this may have taken six days of a developers time during the release cycle, the framework will then exist to be reused adding significant value throughout the rest of the app.

In App Notification

Another example of this was the functionality of adding an inactive button compared to an active button. This isn’t 100% necessary for the user to complete his or her task, but an inactive button communicates not being able to continue due to missing or incorrect information. An expectation is very quickly established which will prevent the user from becoming frustrated. Because this only took two days of a developers time to implement and still allowed me to make the first release on time, I decided to keep the functionality.


After taking several passing of thin-slicing my designs it was time to prioritize features and then create a roadmap. First, I revised my estimation spreadsheet to reflect the features I removed during my thin-slicing exercise. This provides the basis in creating a ideal roadmap.

A roadmap is chart or graph that can take a number of forms, but ultimately identifies who will be working on what, how long it will take, and when release cycles occur. We have an initial release constraint of four weeks, which equates to a total of 40 man days. With two developers working on the project that will drop the timeline down to 20 man days. Since logging in is mandatory to be able to use the app, the became the main priority. Logging in ended up taking a total of 14 man days for one developer. To cut back time for developing log in, I removed a password reset and sign up feature and decided to instead direct the user to a web view to complete these tasks. Using a web view is not an ideal mobile experience, but it allowed me to get most of the features I really would like for viewing our plan and usage. This dropped the log in estimation by four days.

I prioritized viewing your plan and usage because that is what users were saying they check the most often to help avoid data overages. This ended up being the second most expensive flow to add in the beginning, but like I mentioned earlier to included a large number of reusable components to make further release cycles much quicker. After the thin-sliced flows were mapped, I reintroduced the original features I removed from each flow into the roadmap.

The following is the roadmap I created:

Roadmap v1

One of the primary benefits I received going through this process was the fact that it allowed me to think differently about which features were most important. This was a consideration during design, but without the constraints of time or money you view it differently. It’s a much more pragmatic view when looking at designs. Both are very useful. With a design specific mentality you may tend to focus on creating an ideal experience, which you could. But with a product manager mentality, I felt a mental shift occur which led me to seeing the bare necessities. I think if I introduce this mentality during the design phase, it could arguably reach a more simple and elegant design solution.

Another perspective I took away from this process was also further realizing how expensive each individual control is and how we can make sacrifices to produce similar functionality, even though it maybe not an ideal experience. The realization of how expensive designs are, even a basic understanding, is invaluable when designing a first version of an app. It can help make certain design decisions which will afford v1 to be shipped sooner. Once v1 is released, you can then, go back and add the features that allow the experience to shine. This also gives time for more feedback from real users and ultimately creating a better experience than originally imagined.

The next steps are to actually start producing some of these screens and functionality within Xcode and produce a feature brief outlining the work that has been done to date. I’m excited to dive into Xcode to further gain empathy for what all is involved in a developers world to create the app experience. This will ultimately only make me a better designer.

Making myAT&T Designs a Reality – Part 1

If you’ve been following the students enrolled in AC4D, you’re aware that we have been working on redesigning the myAT&T mobile experience. If you’re just now tuning in, please click here to see the process we’ve used, which includes understanding of the current space, generating ideas, and creating wireframes. The next step in this process is to switch our mental state from a designer, to take on more of the role of a product manager and developer to take the next steps in order to ship (or submit) our app.
As a designer, putting on the hat of a developer and product manager is valuable in the same way that approaching design in a human-centered way is valuable. It provides further insight into other perspectives that will ultimately inform your design to create an overall better experience. More specifically, collaborating with a developer will frame how “expensive” a certain component, feature, or flow will be. This affords the opportunity for consolidation and exposure to technical constraints that may have otherwise been invisible coming from a designer’s perspective.
After establishing the resources needed to create the experience, we use a product manager’s skillset to prioritize the most important features. This affords the team to ship a product faster without having to create and perfect the entire experience.


For this project I collaborated with Chap, a previous AC4D alumna and current developer, to estimate out the resources needed for my app. To prepare for this I laid out each one of my screens to create a singular flow with individual features outlined, as well as annotations. Doing his helps identify the overall flow from screen to screen and makes the system more digestible to a developer who may not have been working alongside the designer.

Here is an example of what one flow looks like. Click here to see all of the flows.

Plan Flow@1x


Next, Chap and I went through each flow screen by screen and feature by feature as I explained the system to him. This turned into a conversation about the system from a developer’s perspective, especially when it came to back-end functionality (where the app will get its information, such as how much data the user has used for the month). This brought to the surface how a seemingly simple feature can turn into a much larger feature, which can then be reevaluated on how important it is to the experience.
During this conversation Chap and I also logged how long he estimated each one of these features would take to develop into a spreadsheet. The spreadsheet included columns which consisted of screen ID, feature description, points, days estimated to create (with two developers working 8 hours each day), any notes that may be relevant, and the price associated with each feature. We also used a point system to establish the number of days it would take to create each feature. A point is representative of a “man day” which is a whole day of a developer working for 8 hours. This is normally documented using the Fibonacci sequence: 0, .5, 1, 2, 3, 5, 8, 13… The problem with this type of estimation is that is typically very inaccurate due to being very difficult to estimate this type of work, unless you have years and years of experience. Typically the work is underestimated. Despite Chap having plenty of experience, he acknowledges this by subtracting .25 points per developer per day, as well as adding an additional 30 percent to each estimation.

For this project we estimated the time based on two developers working full time (40 hours a week). Overall, Chap estimated my app to take about 53 days with two developers working full time. The benefit that came from this included being able to quickly glance and see which features take up the most resources, which can then be passed to a product manager for prioritization.

Here is what part of the spreadsheet looks like. Click here to see all of it.



We didn’t have a designated product manager for this project like we did a developer, so we are taking on that role. The challenge for the product manager comes from the fact that we only have 20 days before we need to ship the product!


This is where the skillset of a product manager becomes extremely valuable. They will help prioritize which features are the most important to the user to establish a v1 release, followed up by a roadmap and timelines in which the rest of the features will be added to the app. Part of this exercise will be to modify the existing flows based on this prioritization to meet that deadline, while still retaining as much value as possible. Stay tuned for the next blog post to see how this looks.

Evaluation my myAT&T Mobile Redesign

In previous blog posts I have detailed how we the class of 2017 has been tasked with redesigning the current myAT&T experience. We conducted research to conclude the top pain points/features we were to incorporate into our design, concept mapping to gain a high level understanding of the space. We then applied divergent thinking to focus on the experience without being distracted from the granular details. Next was to start manifesting our ideas by sketching out screens to get our ideas into a more tangible form, followed by increasing the fidelity by digitizing our sketches into wireframes.
The next step in the process is to perform evaluation through three primary methodologies: think aloud protocol, cognitive walkthrough, and heuristic evaluation. After spending so much time in the designs it’s easy to become tunnel visioned and miss opportunities to make your designed experience better for the end user. This potentially limiting viewpoint affords the needs to conduct the previously mentioned evaluative methodologies.
The first methodology I conducted is “think aloud protocol,” which evaluates the usability of my designs by encouraging a user to think out loud as they use your product or service with specific tasks to complete. The intention is to understand how users will navigate my designs, and more importantly the thoughts behind the what and why the user is performing certain actions. There may be a resistance to conducting this exercise due to the assumption that verbalizing internal thoughts will interrupt the task at hand. Experiments were conducted to validate this methodology and found that there is no affect on thought sequences, as long as there is no introspection. This is primarily why the only thing a facilitator of this exercise can say is, “please keep talking.” This avoids any introspection that wouldn’t normally exist within the user.

I created an InVision prototype and recorded the user’s comments, reactions, and  screen activity.

Overall, I conducted two rounds of think aloud protocol. One round with five users, and one round with three users. Between the two rounds I iterated on my designs applying feedback, then conducted the second round to validate whether or not my new designs were successful. New opportunities were presented during the second round as well.
Next, a “cognitive walkthrough” was performed. Cognitive walkthrough is a methodology used for evaluating the learnability of a product based on a theory of problem solving in unfamiliar situations. Think if it as examining the designs from the mentality of a user who had never seen the product before. Although this was not done with actual users, it helps frame the mind to look at the system from the point of view of creating something that doesn’t need any training to use. A cognitive walkthrough is performed by focusing on the primary tasks the user would want/need to perform within the app. These tasks include:

1. Compare your current usage to other data plans, then change your data plan accordingly.
2. Upgrade your current device to the new iPhone 7.
3. Suspend your phone because it was stolen while you were on vacation.
4. Process a insurance claim because you cracked your screen.
5. Make a payment on your current wireless bill and enroll in auto-pay.
6. Update your account’s password.

While examine each task screen by screen I asked four questions to arrive at opportunities to improve the learnability of the design. The questions include:

1. Will the user try to achieve the right effect?
2. Will the user notice that the correct action is available?
3. Will the user associate the correct action with the effect that user is trying to achieve?
4. If the correct action is performed, will the user see that progress is being made towards a goal?

If any of the previous questions show a problem, I then logged that problem into a spreadsheet with a unique identifier, unique screen ID (labeled prior to examination), problem description, severity (1-5, 5 is high), frequency (1-5, 5 is common), and a proposed solution. This makes it easy to identify specific problems relating to specific screens and prioritize opportunities within the design that would have the most significant impact to the overall experience.

Cognitive Walkthrough Thumbnail


The last methodology used during this process is called “heuristic evaluation.” The purpose of this exercise is to compare an interface to an established list of heuristics, or best practices, to identify usability problems. These 10 heuristics have been identified by Jakob Nelson in collaboration with Rolf Molich in 1990 and is generally deemed by others to include good principles to follow. Even though they were established 20 years ago, they still hold true to today’s usability standards. Heuristic evaluation is arguably more detail oriented as you identify each individual control on every screen and compare it to these heuristics, which include:

1. Visibility of system status
2. Match between system and the real world
3. User control and freedom
4. Consistency and standards
5. Error prevention
6. Recognition rather than recall
7. Flexibility and efficiency of use
8. Aesthetic and minimalist design
9. Help users recognize, diagnose, and recover from errors
10. Help and documentation

To capture these areas of opportunity a very similar spreadsheet is used as the one used in cognitive walkthrough. The difference being it helping to capture which of the 10 heuristics a specific control violates to be able to easily refer back to. The spreadsheet serves the same purpose in prioritizing efforts where would have the largest impact throughout the system.

Heuristic Evaluation Thumbnail


After the three evaluation methods were conducted, I then took the culmination of my findings to be able to decide on which changes could provide a significant improvement to the overall experience. Although there was plenty room for improvement, I chose the following three opportunities.
The first improvement I decided to make was definitely the most simple and easiest to implement, but still has very beneficial implications. When users were asked to both suspend a device and submit an insurance claim, their first tendency was to navigate to the account tab. When there were no options for device management they paused and were confused on what to do next. Eventually they realized that tapping the device tab would give them the necessary options. To solve for this I decided to simply add a manage devices options within the account tab. This will then redirect the user to the devices tab.

First Improvement

The second improvement I decided to to take advantage of is also in the devices section. Before I conducted evaluation I placed a CTA (call to action, or button) below the currently selected device which would then drill down to see more device options. There are a couple of opportunities here. For one, the device information at the top of the second screen shows a number of redundant information and doesn’t add any extra value the user wasn’t already exposed to. In addition to this, the current phrasing of “view device details” could be misinterpreted to mean device hardware information. To solve for both of the issues I decided to consolidate the two screen into a single screen. I believe this solves these problems by eliminating the confusing phrasing and immediately providing the options the user may want.

Second Improvement

The third opportunity I decided to work through was working with the visualization of data usage for the month. There were also a few opportunities within this space. One of which was simplifying the current billing cycle information as well as the data usage information into a single chart. Users were having a difficult time processing the way I displayed the information within a bar. This placement also was difficult to compare, which was another problem. Being able to compare your current usage wasn’t as clear as I’d like it to be. Users were having to take time to process what was on the screen rather than scanning the screen. Lastly, I noticed that users were trying to tap on each individual data plan bar to update their data plan. To combat this I added a button for each plan. I think there is still more opportunity to make this specific screen even more user-friendly which I will continue to explore.

Third Improvement

Moving forward I will continue to work on these key opportunities, but also work on a number of smaller details that will make the overall experience more user-friendly. As a class, we will also be meeting with a couple of professional developer to gain a better insight into feasibility of our ideas and help create a plan of prioritization.

If you would like to see my presentation, you may view it here.

Redesigning myAT&T – Sketches to Digital Wireframes and User Testing

After completing our sticky note storyboarding in Rapid Ideation we then moved forward by creating higher fidelity wireframes using pencil and paper on a phone screen template. Previously, we only concentrated on the most important task or idea for each screen in our sticky notes. Because of this key information within each screen was missing to fully realize what the experience may be like. By moving to pencil and paper it allows us to consider the more granular level detail of each screen, such as UI components and the navigation. Here are a few examples of some of my sketches.


The next step was to critique each other’s screens for anything that might be missing or confusing. At this point we may have been missing back buttons or smaller detailed informational items that were less important to the primary point on the screen, but still important to include. One benefit from beginning with sketching is that changes are much easier to make, part due to the effort involved and arguably we are much less attached to what we have created at this fidelity. Once the entire flow made sense in sketch format, we then moved on to digitizing our wireframes (view full resolution).


Iteration is very important at this stage from feedback about the designs we are working with, both from other designers as well as users who are not as familiar with the project. To confirm our designs were communicating what we intended, we conducted user testing via the “Think Aloud Protocol”. With this protocol we ask users to tell us everything that is going through their minds about what their seeing and feeling about each screen. From feedback we received during user we took into consideration on future iterations of our wireframes.

To set this up I created a Craft InVision prototype to be able to tap from screen to screen. At this fidelity it’s pretty close to what a final experience may look like and can be used to gain valuable insights about usability and perception of information on the screen. I also plugged in the phone into my computer and recorded what was being used and said during the user test. Lastly, I took notes to highlight breakdowns or opportunities I noticed or the user mentioned.

One of the main findings that came out of user testing was learning that people gravitated towards the account tab I was using in my navigation when they wanted to submit an insurance claim, or suspend a device. I intended them to go to the device tab to do so. Although, these users did eventually get to the intended location, and admitted that they felt it made a little more sense than what they were accustomed to (they were probably just being nice), their feedback told me I should provide a button within the account tab to navigate to these same locations.

Another change in my designs that my user testing informed was for a more consistent messaging system. I realized that I had 3-4 different ways of showing confirmation that the action had been completed. There was also a place where I could have included a more clear success message that was missing. As soon as I updated this users had no confusion as to whether or not the task was completed.

Over the break I plan to iterate more on my designs and test them in front of other people focusing on more error states and any edge cases that arise to make sure the functionality of my app is complete.

Service Design – Thinking of Solutions

For our Service Design class, Garrett and I have been working with We Are Blood, formerly known as The Blood Center of Central Texas. We chose to work with them due to the fact that despite their success, they still need an increase in donations.

To date, we have conducted research relating to the donors and employees and synthesized our findings via externalization and primarily the creation of a customer journey map. The purpose of this was to help us visualize the entirety of the donation process in relation to our interviews and identify potential breakdowns. This led us to where we are today, creating potential solutions to help minimize the breakdowns we have identified. In deciding which ideas would be most impactful to We Are Blood we weighed the impact to donors, value to We Are Blood, and the amount of effort for implementation.

Overall, We Are Blood is missing an opportunity to create an emotional connection to all of their donors. Some donors coming into donation centers and mobile drives do not feel connected to the mission of We Are Blood. These donors often do not donate again, causing the blood supply to be lower than it could be. There is also a lost opportunity during the donation to make donors feel more comfortable by explaining the process.

The first major area of opportunity is around perception. We found that the one-off donors don’t see the need for blood as continuous and only come to donate whenever there is a tragic event. The irony here is that due to the sudden increase in donations We Are Blood ends up not being able to use all of the donations they receive. In fact, 36,000 units of blood are used every day in the United States. There is very much a constant demand.

To communicate the continuous need and motivate people to come in outside of tragic events we want create a sign which will be able to be seen by people when they drive by the Lamar donation center. There will be two primary components of this sign. One being a blood bag about ⅓ full with a message explaining how they are always in need of donations. The other component will be an interchangeable “fact” that will further communicate the constant need for donations, such as “36,000 units of blood are used every day in the United States.” The reason for being able to update the sign is to catch people’s interest with new information rather than ending up ignoring what the sign is trying to communicate. Although this is one version of implementation, this same message could take the forms of a billboard, a pamphlet, or a dedicated page on their website. We think the sign outside would be the best immediate course of action due to the low cost and modular design being able to update frequently.

Vignette 2 Border


The next area of focus we decided to work on is around the understanding of the process of donation. We found a number of donors who weren’t exactly sure what was happening during the donation process; they were just along for the ride. This created anxiety and a feeling of discomfort for the donor. When we asked a phlebotomist about the disclosure of the donation process to the donors we found out that he/she will only explain the details if he/she is asked, or is visibly distressed. The problem here is that these emotions can deter someone away from becoming a regular donor.

To help combat these negative emotions we are recommending that the phlebotomists regularly explain what is happening to donors, especially to first time donors. This will help create that emotional connection we identified earlier. In addition, we noticed that there are a number of TVs within the donation room that were never being utilized. We feel this is a perfect medium to be able to help communicate the donation process, in addition to the phlebotomists’ explanation. We understand the the phlebotomists are busy and won’t always be able to explain or help facilitate this need in the donor. Overall, by explaining more of the process while someone is getting literally stuck with a needle, their overall anxiety will be reduced affording a higher chance of returning for more donations.

We are proposing a presentation of that includes a step by step explanation of the process, stories of successful donations, and even some powerful facts about blood donation. It’s important to note that the presentation should be able to be viewed with or without sound. The unused TVs are a perfect medium of delivery considering they are already in place and are not currently being used for anything else. All that would be needed is to create the presentation. This could also take the form of a pamphlet that is handed out, but since the donors are already sitting in the chair we see the explanation being powerful while the actual donation is occurring.

Vignette 3 Border

The last opportunity we are proposing solutions for is around creating empathy between the donor and the recipient. We found that donors want to feel like they are helping an individual, not a business. By creating this emotional connection we are providing a more tangible result to the donation. Right now there isn’t much that happens after your donation, in relation to the donor. This is what creates the feeling of donating to a business and not an individual. We feel this opportunity has the largest potential to increase regular donors out of what we have found.

To create this connection we want to utilize technologies that We Are Blood currently has and is also working towards. The ultimate goal will be able to send an email or text message with information ranging from the donation was simply used to even a short description of that person and how the donor’s blood helped their situation. We heard from most donors that they would love this information, although some did say they would prefer not to know the details of the person, but would still love to know when their donation was used. Either way, this would still create empathy for the donor and their efforts. This also affords a way to schedule another time for the donor to come in to donate.


Vignette 1 Border


We Are Blood is working to connect to all donors and make them feel like family to ensure the blood supply of Central Texas is available for generations to come. These designs offer value not only to the organization, but also to the donor as they work together to provide life saving products for the community overall.

If you would like to review this information in deck form, you may view it here. The deck also has an appendix which details more of our findings and our process.

Redesigning myAT&T – Storyboard Flows

Our project for Rapid Ideation and Creative Problem Solving this quarter is redesigning the mobile experience for managing your AT&T mobile phone account. We chose this problem due to how much opportunity there is to improve on the experience, especially on the mobile platform. Not only is there opportunity for improvement, pretty much everyone can relate to the frustration with a majority of cell phone providers. Previously I detailed the value of concept mapping as well as a reflection on the process.

After concept mapping we explored what it looked like to storyboard the six flows we decided to focus on as a group. In previous classes we have created storyboards, but there was a larger emphasis on character development then. While characters are useful in establishing a narrative, this focus was more to be more utilitarian; establish the happy-path. Taking practice of telling a more traditional narrative or story and applying it to an exercise like fleshing out flows made the process feel much more comfortable and natural.

The six flows we chose are include:

  1. Plan management
    1. a.) The ability to view current plan and features.
    2. b.) The ability to compare usage against available plans.
    3. c.) The ability to change a plan.
  2. The ability to upgrade a device.
  3. The ability to suspend or remove a device.
  4. The ability to make a warranty claim.
  5. The ability to make a payment/set up automatic payments.
  6. The ability to review and set account security.

I have had some experience sketching out flows of screens before, but there was a very beneficial constraint I have not previously applied. That constraint was the use of pure sticky notes and a Sharpie marker. Using minimal real estate combined with a thick marker forced me to focus on the most important aspects of each screen.

In the past I worked on larger pieces of paper with a thinner writing instrument, but this format led me to pay attention to navigation, placement of components, and really even the layout of the entire screen. It’s arguably too early in the process to be focusing on those details. At this stage in the game those details become distracting, pulling you away from first establishing the hero flow. I was becoming stuck in the granular details rather than stepping back and looking at the picture as a whole before fleshing out the intricacies.

The format I implemented for my storyboards were using a purple sticky note to denote the flow I was working on and light blue sticky notes for the actual flow. Within each flow, the top row shows the high-level functionality while the bottom row gives a small description of what each screen is accomplishing.

Storyboard 1

From here, I actually stepped away from working on it for a day. I wanted my mind to marinate in the flows a little before I took another stab at it. Whenever I did come back to the flows consolidation seemed to be a focus of my actions. I placed yellow sticky notes over the blue sticky notes when I saw an opportunity for iterating towards simplification with the iterated screen.

Storyboard 2

This also allowed me to easily recognize that three of the six flows began with a very similar screen design. Reducing the number of steps will ultimately provide a better experience for the end user allowing them to accomplish their task in less time. The storyboards will inform the structure of design moving into the more detailed wireframe stage, which we are working on currently.

There is a level of clarity I received during this process due to the focus of the bigger picture, which was derived from the constraints of the sticky note real estate and the thick weight of the Sharpie marker. This affords a smaller cognitive load when continuing into higher fidelity wireframes. After all, that’s the benefit of applying process, right?

Team Food Freedom – Beginning Research

Well, it’s begun! Team Food Freedom has begun our larger AC4D project. My team and I have decided to research “access to healthy food among low-income individuals in Austin”. Our group is aware of the important role food, more so healthy food, plays in our every day life. We are curious how access to healthy food, from a physical and mental space, influences people’s eating habits and perception of food. The area of focus could lead to a number of directions that aren’t necessarily known at this point. That’s what is exciting about ethnographic research, it could present a space that we are completely unaware of at the moment.

This quarter started off slower than what was hoped. Although, I think overall the class is moving forward with more confidence this quarter. This is due partly because we deeper exposure into the process from the previous quarter, as well as becoming more comfortable living within ambiguity. This allowed us to get more exposure to opportunities of improvement within the process. Learn by doing, right? I know on a personal level this has been extremely beneficial because generally over-think things, which typically becomes a barrier to making. Part of this is due to being unfamiliar. To combat this I will externalize more and sit within the data longer.

To focus our research participants we are defining low-income as someone who makes less than $10/hr, which comes out to less than $20,800 annual income before taxes. The living wage in Austin is reported as earning $9.52/hour. Living wage is defined as the level of income that a person must make to support themselves in a given location. Focusing on this level of income will allow us to consider how physical (location and financial) access affects diet and food perception. Generally, higher quality food is more expensive and could be a potential barrier. With a higher income one could assume that access becomes much less of a barrier and then would primarily focus on any mental/habitual barriers. We are interested learning more about both types of access. If we were to focus on incomes at or below the poverty line, we would lose the opportunity of healthy food as being a focus. The idea here is that someone in this position would be focusing more on problems that would be more important than healthy food in their minds.

At first we were recruiting from too broad of a pool which wasn’t providing enough constraints. With the recommendation of Ruby Ku, we applied the above constraints, which ultimately started to give us more traction. So far we have reached out to community organizers, neighbors, approaching people at HEB, posting online, and asking people we come across in our day to day routines.

Gaining participants began with minimal traction, but as the quarter as progressed we have started to make significant progress. I think part of the initial slow pace was subconsciously thinking in the back of our minds that we have until next April to finish the project, without thinking of the steps in the process we haven’t even been exposed to yet. This mentality has definitely changed within the last week. We went from 5 participants scheduled and/interviewed to about 15. We would still like to get a few more scheduled.

The slow start was a reminder that in this world there is never time to waste. Whenever opportunity presents itself we need to capitalize on that time. Even if it’s only 30 minutes of transcribing, replying to a couple of emails, or working on a blog post it’s still progress. After all, the end project’s success is going to stem from incredible number of smaller 30 minute tasks. I can’t wait to see what Food Freedom comes up with!