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.

Buttons

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.

My AT&T Redesign: Roadmap

Since last week’s update, the AT&T application redesign has continued to work towards the goal of release. Previously I had presented our newly updated hero flows for all screens within the application and asked a software developer for an estimate on the time it would take to create each feature. Once I meet with the software developer I understood that the application would take around 42 days to complete. This date is contingent on having two designers working on the application for 40 hours a week. Now though, there is an additional constraint, I must release a version of the application within the next four weeks, or 20 working days, that still delivers on the value promise previously established. Within this post I explain the review process the application went through to produce a version that contained limited features, but still delivered on the value. I also explain the process of roadmapping, a technique used to schedule the development of the different features of the application for its phased releases.

Before any of the review process occurred, I reminded myself of the value promise I had originally established. The value promise is what I wanted to deliver to the user. This value promise is derived from direct quotes and insights made through research. For AT&T I had two pieces that grounded my value promise. One individual said the current application “could almost just be a widget, all it needs to do is allow me to pay my monthly bill and view my data usage”. This sentiment helped me understand that users don’t find value in the frivolous additional actions the current application offers. It also alluded to the fact that users want to have control over their service. The most important aspects of a user’s service would seem to be a user’s ability to pay their own bill and their ability to review their data. In being able to view their own data, a user feels more in control to prevent any overages. Additionally, many of the users I spoke with agreed that the current application “does way too much”. From this and other similar sentiments, it can be concluded that users don’t want a swiss army knife application, but one that is deliberate in its capabilities. After synthesizing users quotes, I concluded that the AT&T application redesign should deliver an application that is less capable, but more intentional in its operations and there needed to be a sense of control given to the user on sensitive matters.

Delivering on the value promise was again only one constraint, I also had to work out a way to release my application with features within 20 working days. This meant I needed to review what were the essential features of my application that could be created in the 20 working days and released. These were the two established constraints I was working within.

I began reviewing all the features and flows alongside their estimate. In order to prevent myself from duplicating times, I cut out each screen and physically mapped out how the application would work. Then I began to quantify the total costs of each screen, and added some preliminary notes around what the application needed to do in the first release. I organized my work based on four sections of the application: Login, Billing, Usage, Devices and Account. Below are two images of these physical maps with my additional comments and notes on the various screens.  Billing
Account

Again, mapping out these different sections helped make sure I didn’t duplicate estimated times for feature development. It also helped me separate the different flow between what would be published in each different phase. Finally, the method helped me see where various features overlapped. Knowing when features needed to be put in the same release helped me make sure they were placed in a release order that made sense.

Once I had figured out the costs of each feature and its place within my application, I began to review what features I wanted within the first release of the application. I’ll refer to this release as Phase I. Again the constraint tied to this release was that it could only include 20 working days. The other constraint I was working with was the value promise. I took these constraints and reviewed my application to see what essential actions of the application were needed to deliver the value promise and and what could be developed in the allotted time period.

I knew from the beginning the Phase I release needed to have the Login and Home features. These were essential since they’re necessary for opening the application. Based on the assumption that the application needed to give users control over their monthly bill and their data, I decided that those two flows needed to be added to the application’s Phase I release as well. Now the tricky part was that with the flows that had been included in Phase I: Login, Home screen, Pay bill, View data; there were already a number of additional flows that were necessary to build out the essential flows. These additional flows included: Managing payment methods, Change password for a Word, Change user name. Each of these flows were needed in Phase I in order for the essential flows to be functional.

Then I adding up all these costs associated with the full flows and found I was over the 20 day limit. Below is an image of my math, showing the cost of each feature for the flow and how they were over my 20 day limit.

 

Phase I Costs

In order to cut down the costs even further I made the decision to remove the option of having no password as a feature. Originally, my three password options were the most expensive part of my application, so I knew from the beginning since security wasn’t part of my value promise I would need to remove a password option feature or two from the Phase I release. After I removed the flow for no password and the login options for no password, I had reach the goal of about 19 days for development.

From there I began the whole process over again with only the remaining features. The challenge with these features and flows, was the question of what would deliver the most value in the next phase. Since there was no time constraint, I had to discern their delivered value as the only constraint.

The foundation of my application is structured around delivering a small number of actions done well, and on giving the user control. The Phase II focus was then structured around data and users control. The activities I had design to be accessed from data were “Change Data” and “Send Notification”. By allowing a customer to change their data on their own, they again feel a newfound sense of control. By giving a user the ability to see their data is almost over and sent out a messages, the user can again feel more in control of their data and service. Each of these actions give the user a better sense of control over their data.

For the final Phase, again there was a reduction on constraints. I no longer needed to worry about the time constraint, and I didn’t need to worry about the value promise, since all my features collectively delivered up on it. Rather with this phase, I focused on how I wanted the software developers working on the features so that there would be a minimal amount of blockage between the two developers. This issue wasn’t ignored on the other flows, it just became a much larger issue with the final Phase III assets. If it came to be I know I would be able to remove a few of these remaining features

After I had learned which features would be placed in which Phase, I began to “Road Map” the features out. This in a broad sense means mapping out when each feature is created by the software designer. On a more granular degree, I created an Excel sheet that contained each of the resources, on the y-axis and the days of the week on the x-axis and I plotted where and when a feature was created. It also contains direction around how many resources would be applied to the feature for creation. For the first round, I was drawing these maps out next to the Phase’s features and estimated time. Below is a picture of my each phases’ sheet:

 

RoadMap

 

One of the largest constraint I struggled with while mapping out the features was making sure I wasn’t causes development block. If a feature was dependent on another feature, I had to make sure to organize the timeline so that the first feature was build before the other. After I had a paper version of the graph locked, I then started to digitize them. In digitizing the timelines, I also added a short explanation for each feature being developed, as well as a color that coordinated with the section of the application. Below are links to two PDFs containing the roadmaps.

Roadmap- Phase 1

Roadmap- Phase II&III
As we continue working on the My AT&T redesign, our next steps including writing out the HTML code for a screen of the application to actually work, and creating a document for another individual that explains what the new application looks like, why it’s an improvement from the last version and how to build it out.

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.
Roadmap

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.

 

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.

Spreadsheet

 

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.

My AT&T App Redesign: Features, Capabilities, Controls, and Development Meetings

In the last blog post about the My AT&T Redesign I had completed three usability tests, had evaluated the results, and begun to integrate those findings into my application. A link to the post is here. Since then, the project has turned to a more concrete phase, where cost and time have begun to play a role. Within the past two weeks, I’ve redesign my application (both the actions within it, as well as aesthetics), identified the features, controls and capabilities within it, and meet with a Software developer, Chap to get an estimate on the time it will take to develop. Within this article there is an in depth look at each step to explain what these mean.

After I presented my findings for user testing, I received feedback that my application lacked a “realness” to it. So I asked Jon to meet with me and discuss my app at length. In between meeting with Jon and my presentation, I also design three examples of different application styles for my home screens and asked my mentor to give me feedback on them. Below is a PDF of the three styles.

 

HomeScreen_V1-01

My mentor replied with resources for inspiration, a fresh perspective on the three styles, and a nod to the third version as their preferences. After reading her feedback, I decided to use the third option as my style for the next iteration of my application.

While I was still working on creating more visually pleasing screens, I meet with Jon. He suggested I focus on two specific details of the application:

  1. Making the application look more like an IOS application. Pulling toolkits and existing resources to create the screens, rather than my own visuals and buttons in Illustrator.
  2. Concentrate on what is happening within the app. Questioning why I’m including certain flows and actions within my app rather than just accepting “how things have always been done.”

 

An example of how the application lacked a sense of realness can be exemplified in the slider bar I created for the Plan flow. I had created my own slider bar, instead of just pulling from an IOS toolkit. Below is an image of my old slide bar, and now the newer IOS approved one I’ve placed in my application.

 

Sliderbard-01

 

Jon explained that by creating my own icons and buttons I’d made it more difficult for a software developer, because IOS elements have already been coded. Developers just have to copy paste when writing the code when creating those elements. In creating my own, I’m making the developer go and write brand new code, which causes additional unnecessary costs. If I had had a certain element that needed to be completely created from scratch, then I could have asked a developer to specifically make it, but I felt all the elements from the IOS toolkit covered my needs within the application.

An example of Jon’s second point was exemplified in the password flow. Previously I had requested that the user add in their new code and type it twice and I had certain requirements on what the password had to contained. Jon reminded me that I needed to be more conscious of what I’m requiring of users. In my next iteration of the application I striped away all the requriements of changing a password, and only included what I thought would be necessary for a user to feel their password was changed.

After meeting with Jon, I reviewed my printouts and went through each screen marking up what I wanted to keep, to remove, to add, and what needed to be on each screen. This evaluation forced me to review what I was asking of users for each flow, and if I wanted to keep it or trash it. Below is an image of what this process looked like.

 

IMG_0189

 

After reviewing every element of the contents, I began to tackle the organization of the application. Moving flows between the four sections of Billing, Usage, Devices and Account. Once I had a plan that contains all the flows I wanted, and where I wanted them, I was able to start building screen.

In a week, I build every screen for each flow with proper IOS elements and screens that were more consciously crafted. For IOS styling, I downloaded a toolkit to pull elements from, and found resources on the internet that explained the spacing requirements. I referenced the annotated printouts when deciding what elements needed to stay on each screen. I also was able to go back to my inspirations from Q2 and pull in some ideas for that time too.

After creating the new app I needed to get an estimate for the time it would take a developer to create the application. I had learned from class that when developing an application, the real cost is associated with the features and overall time it would take to build the various elements of the application. In order to meet with my developer,  I needed to identify these elements and explain their purpose within the application.

I took all the flows and identified each screen with a number. The on each screen I identified the features and controls with names. A feature is something that adds value to the user’s experience. For example in the application the pie chart containing an account’s data usage. The counterbalance to features are the controls, which are elements that are needed for the structure of the application, such as the accordion information storage style used throughout the application. Once I had each named and identified each feature/control, I printed them out and set up a meeting time with the developer, Chap.

During our meeting, Chap and I discussed each flow individually, identifying the features and controls in context of the flow. As we went through flows Chap and I identified potential error states that needed to be addressed, where there were places of overlap between screens, and some of the more difficult elements of my app and what solutions he saw were possible. As I identified the various elements, Chap was documenting the screen name and element with a point amount associated with the cost of the feature. One point equaled one day of development. Chap then added a 30% padding time for himself so that he had some room if he needed the additional time. So now for each day of estimation, Chap had 1.3 days to complete the feature. Chap then took the total estimated amount of time and divided that between two developers. This is because we assumed the development would be executed by a team of two developers. At the end of our meeting, Chap shared the excel document with me, so I could reference each cost and element. All total my application would take 41.17 day to create if two developers work on it for 8 hours a day. Here is a link with the file: Application Estimates 

The two most expensive features in the application came from the password feature options, first the option to replace your password with the Iphone’s Touch ID and the second was to opt out of having a password. For both of these features they were estimated to take around 3 and a half days for two developers. For perspective, on average my other features were only estimated to take about 87% of two developers days. This is high estimate was due two pieces. First Chap explained that he’d need to understand if it was even possible to have these options within the application, and secondly there needed to be the estimated time associated with building out these elements. His explanation of these two steps helped me understand where these costs were coming from and what that time would be spent doing.

Another interesting element Chap highlighted during our meeting, was that when coding all of these pieces, he would need to work with various teams within AT&T to write out the proper code to extract that information associated with the accounts. An element from my application that required direct communication with AT&T to gain the right information is the Data Usage pie chart. Since the information displayed is so specific to the account, Chap would need to code the right request to display the various percentages of usage. That information would need to come directly from AT&T. This also means there is a general costs with working on any app that is spent by the developer familiarize themselves with other resources they would potentially we working with.

Since my meeting with Chap, I’ve updated the screens to reflect the changes we discussed, and I updated my flows so that they contain both the screen title, and the cost associated with their buildout. Below are links to each sections’ flows with costs associated with them.

Home & Billing Flows

Devices Flow

Plan Flows

Account Flows

Since this project is under a time constraint of four week, I now need to reduce my development time. This means, going through my application and deciding which features and controls are going to be keep and which are going to be eliminated for the first launch, but added back in later. I’m looking forward to working out a way to deliver a valuable application to the client, but still maintain our timeline of four week of development work.

Scoping Development – Timeline & Resources

-Tying the process together-

In my previous blog post I discussed the processes associated with evaluating a mobile application. The application we are redesigning is the iOS version for myAT&T. From the usability evaluations of our wireframes we furthered the redesign. Correcting all of the usability issues that we found. Our main goal was to be able to bring it to a developer and get it estimated for cost and timeline. Development is exciting because you start the conversation about making it all real.

The core takeaways from the evaluations were as follows:

  • The experience feels discombobulated. There is little to no feeling of continuity. The user always feels slightly unsure if they’re doing it right.
  • Attributes and/or Features are not effectively communicating their purpose. The design does not provide clarity.
  • Visibility, control and freedom are huge overarching issues. Each screen is separate with separate actions and it is relatively arduous to go back a couple steps to change something.
  • Hierarchy and priority are not clearly visualized. Everything feels the same. The design does not draw the users attention to the next step.

I tied together all of this feedback and redesigned my tasks to compliment these findings. From there it was time for development.

I took my giant printouts up to the 14th floor of a downtown office building and sat down for a development estimation meeting. In preparation for this meeting I compiled all of the flows, showed where the user was interacting with each screen and broke out all of the key components, controls and features within the application onto a separate print. In describing the attributes and functions of each component, feature, and control I started to see where I had gone wrong. It is hard to foresee issues when immersed in the core of 1 phase of a process (Design) but now that the conversation was turning towards development I was easily able to identify what would be a misstep in terms of engineering my design. In design I felt like I had been gearing everything to the user (good right? Not so good for development) and attempting to make the flow as seamless as possible. So essentially I was basing my decisions for what to build off of the prior screen and the task that was needed. Now development comes in, which means money and time are ringing loud and clear.

As I sat down to this meeting I was excited to hear what the developer would have to say about my designs.

I gave him the shpeel;

“We are redesigning the mobile experience of the AT&T iOS application. The reason this is a significant build is because, currently, in the experience it feels like someone duct taped multiple apps together. You can accomplish the same tasks from multiple different angles, there is conflicting navigation attributes etc. My value promise for this build is founded on the idea that someone’s mobile phone account management application is not one that they want to “hang out” on. Sure it needs to be good looking in a trustable way but a user should be able to accomplish their task quickly and simply with as few steps as possible.” And with that brief background we began.

While walking him through the flows he pointed out all of the controls that I had made custom that could use standard iOS features which means the code is already written and open source. Less build time for simple things = a faster delivery to the user as well as the ability to put development resources towards more important functions. Therefore I said yes to his suggestions. Further down the line I can bring custom elements in if I wish but at this stage, to provide value to the user, custom features are not essential. This also helped because, within my design, it leveraged the same simple attributes for different uses.

I had built out radio buttons:

Screen Shot 2017-02-02 at 5.02.04 PM   

I had built out a selector:

   Screen Shot 2017-02-02 at 5.02.27 PM

I had built out a different kind of selector:

Screen Shot 2017-02-02 at 5.03.01 PM

All of these can be streamlined into the usage of an iOS picker, similar to the one below, for all of these use cases:

Screen Shot 2017-02-02 at 5.04.27 PM

From these changes a design language seems to be emerging in the form of

If there is one choice…  it’s a click.

If there are multiple choices…  it’s a swipe.

A click is commitment

A swipe implies freedom

The developers next question stumped me because it was one that slipped my mind and I hadnt even considered it. “How long do you want it to take before it “times-out” and logs you our of the app”? This is an interesting piece of the story because, in terms of the pathway through the flows, it was meaningless. However, to the overall customer experience it was highly important. Imagine if you were in the middle of buying your new iphone and got kicked off because you were trying to pick between silver and rose gold, not cool! He said it really wouldn’t take a different amount of time to code a different time-out duration but it did need to be defined. Good to know.

*Learning: In design you can’t just focus on your specific task, you must push your mind to consider all of the surrounding influences and potential scenerios.*

We then assessed my custom features:

Usage/usage progress bars:

Screen Shot 2017-02-02 at 5.07.20 PM Screen Shot 2017-02-02 at 5.07.30 PM

A phone selection carousel:

Screen Shot 2017-02-02 at 5.07.07 PM

These we isolated from the estimation of the other flows and gave them a timeline by themselves. Another thing is that there are billions of people on the planet.. Someone has probably made something similar to your idea before. Don’t reinvent the wheel. Use the resources that already exist. It is fine and awesome to craft your own designs, but make sure that that is realistic for the scope of the project. Is the company you are working with strong in branding which makes that a very important consideration? Or are you trying to get the product shipped out the door and the importance lies more in the functionality and initial value to the user. This is something that I couldn’t have been aware of before building my first set of screens for an app.

The output from all of the above is an estimation for the scope of the work, both price and time. We were delegated 2 (theoretical) developers working full time. So…

Resources: 2 Developers @ 40 hours per week

Salaries: $200,000 each

Estimation (in man days):

60 days to complete the project (30 days per man)

Timeline: 6 weeks

Price: $44,609.67 in total

To explain the work; I have run my system through 3 types of evaluations (Heuristic Evaluation, cognitive walkthrough, and think aloud protocol), I met with a developer; understood the way development is thought about and executed and now am moving into the phase where I need to think about the features i’m delivering and why, this phase aggregates the importance of all of the prior phases and makes me see how important it is to take all of these things into account at once. Which, from my understanding, is why at the Austin Center for Design we are learning them all as a fluid skillset. There are exponentially valuable details that are lost when a project gets handed off from one step to the other. In conversation with a developer when asked a question I am referencing all the way back to when I did research with users of the current experience to discover their most painful interactions with the myAT&T application. That reference spans across 3 disciplines.

I am looking forward to the next time I go to begin an app build because from project launch I will be considering the user, their needs, what they think about and are used to (Design Research), the goals of the service, what the criteria and principles for creation are and designing for and within those parameters and requirements (Interaction Design) as well as development and the pace and price by which my designs would be developed (Product Management). It’s all coming together!

The full collection of artifacts (task oriented screen flows, features and components broken out of the flows, estimations on cost/time, summaries, insights and conclusions are Development estimation – read out.

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).

paypal5.13

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.

Product Management Part 1: Development Estimation

For the past few months, we’ve worked to redesign AT&T’s mobile app. The process has included research, concepting, sketching, and wireframing, evaluation, & iteration. The next step of the process is product development — bringing the app into reality.

Design vs. Product Development

As designers, we are user-centered; we focus on people, their goals, and the way the design will support their experience in achieving those goals. Design is all about visualizing an ideal state and sketching our way to that future.

Once we get into production, however, we must also be technology-centered. “Shipping,” or product development requires the product manager to be pragmatic as she brings the product to market.

While the design process is all about the user’s behavior and feelings, product management zeroes in on the system’s components, features, and controls.

Shipping

The first step to shipping is consulting with a developer. While designers love to play in ambiguity, developers tend towards “well-defined” problems, strive for efficiency, hate to do the same work twice, and guard their time.

Although these two mental frameworks may seem antithetical, it helps the designer move from “blue sky” to “realistic,” consider reusable components (leading to efficiencies), and get ready for sizing.

Sizing

Sizing is a method for assigning relative time estimates to build unique features, components, and controls. Sizing helps guide priorities, identify total time on task for a development effort, and steer redesign efforts to quickly launch the product.

Sizing, despite being often being wildly inaccurate, 1) provides clarity to stakeholders who have to commit to delivery (to a board of directors, for example); 2) provides clarity to marketers, who need to build campaigns around delivery dates to understand an order of magnitude for producing a product; 3) gives the entire team a view of the product, so they understand it thoroughly; and 4) forces detailed interactions between the designers and developers.

Sizing Method

To size my wireframes, I walked my developer through my flows, and he estimated how long it would take him to create each component, screen by screen. He gave his calculations in “man days” (a man day being equal to one day of work for one person), and estimates ranged anywhere between a half day to 3 days. 

Then, I asked my developer to estimate how long it would take two developers to create each flow. To my surprise, instead of simply halving his calculations, he divided them by 1.5, to account for sick days, inefficiencies, or unforeseen roadblocks.

As, again, sizing is often inaccurate, I then took his calculations and added a 30% padding to each, a common practice among product managers. You can see calculations illustrated below, as well as in this spreadsheet: myAT&T redesign estimation – Sally 

Login & Homescreen

Autopay Change Password   Upgrade Phone Part 1 Upgrade Phone Part 2

As of the latest calculations, production would take 51.5 man days. The next challenge will be updating the design to only require the allotted 40 man days. Stay tuned for Part 2: Thin Slicing & Road Mapping.

The dilemma of empathy in design — an interview with Chelsea Hostetter

As designers, we are aware of the importance of infusing empathy into the design process, but we rarely stop to reflect on the emotional reverberations and obstacles that empathy infuses into the design process. In our interview, Chelsea(AC4D 2014) speaks specifically about those challenges in designing for and with the queer community in Austin — a group that she is a part of and strongly supports. Chelsea is well known in the AC4D community for her abilities as an illustrator, designer, and patient teacher, purposefully conveying emotion and meaning through sketching.

How did you find out about AC4D?

In 2008, I was working as a graphic design intern at a financial company called MPower Labs. My boss was Suzi Sosa, who is Jon Kolko’s friend and one of the investors in AC4D; she mentioned it offhand. Right after I had gotten out of undergraduate I looked at it again and I felt like I wasn’t 100% ready for graduate school. Around the same time, I applied to the Center for Cartoon Studies (CCS), an exclusive graduate school for professional cartoonists, and they accepted me. I remember thinking, well, I could avoid this shitty economy and go to graduate school in Vermont for cartooning, but there was something in me that said, “no, you should stay in Austin and see what happens.” So I declined to go to CCS, and ended up staying here in Austin and working on my professional career.

Fast forward to 2012, four years later. Alex Wykoff was my coworker at a tech company I was working at and he wanted to be a designer. He told me about this school called the Austin Center for Design, said we should apply together. I felt like the first time was just a coincidence. The second time was a sign. When the universe knocks at your door twice, you go with it. So I decided to apply with Alex. I was excited that we both got in, and we were both nervous about it, but I was very happy to be able to work with him throughout the AC4D experience.

What got you to say definitively you were attending?

I went to the Austin Center for Design bootcamp and realized that there was so much more utility and purpose to design than I previously thought (shameless plug, one’s coming up!). I had been looking at other schools like RISD and SCAD, and the work that I saw people producing was a bunch of really pretty — technically very impressive — but a lot of the work that I saw didn’t have a lot of feeling or emotion behind it. Or even purpose, really. I would see student projects where people would design these beautiful 3D printed bikes, but they weren’t meant for people to ride. They weren’t meant for consumption, they were meant to be art pieces. While I think that’s nice, I’m very utilitarian in professional design. If it doesn’t function as it should but looks nice, it’s useful for beauty but not much else. When I spoke with Jon, and then saw the types of people that Austin Center for Design attracted, I realized that this was the right decision for me to go there instead of any of the other schools. I knew that A, the coursework was going to be difficult and I like to seek out challenges; and B, the social entrepreneurship piece was a piece I really cared about. It wasn’t about making art pieces that go into the world and are forgotten. It was about making an impact and making a difference.

Tell me about your year at AC4D.

It was hard! (laughs) I think one of the things that struck me about AC4D that the curriculum is really at the same pacing and difficulty level as at Carnegie Mellon University (where I did my undergraduate degree). This meant that there were high expectations set for us that I really genuinely wanted to meet. Q1 was okay, Q2 was very difficult. Alex and I were embedded into the trans and queer community of Austin, and it’s really hard when you’re part of the LGBTQ community and also talking with members of that community about their needs to not feel like you want to take action right then and there. There were a lot of emotions I felt around the research that was just difficult to process as a queer person myself.

In Q2, I went to the Transgender Day of Remembrance (November 20th). The Transgender Day of Remembrance is an event held for the community to remember the lives of the transgender victims of homicide within that year and to communally grieve. So throughout all of our interaction with the trans and queer community, the underlying ribbon we found is that somebody usually knows someone who has died whether through murder or through suicide. It’s tragic, and it’s awful, but that is the day to day of our community. As I was listening to the many names called out of lives lost that year, I started sobbing. Watching one person grieve is harrowing, but watching an entire community grieve, and feel connected to people you haven’t even met, is something that is completely, deeply, and soulfully impactful. At the time we dove really deep into the research but it struck a very deep, dear, personal chord with me. I previously considered myself a member of the queer community but through that research, I realized that I hadn’t been a good ally of the trans community like I previously thought. I didn’t have enough information or empathy to properly support our trans community then. Now, I feel much more confident in being an ally, but I’m learning new things every day. It changed my worldview and allowed me to become a more supportive person. That’s how much the research can change you.

Q3 was really difficult, and Q4 was the most difficult. It’s challenging to take your insights from research and turn them into something with which people can empathize, but it is often extremely challenging when you’re doing something socially impactful to take that and put it into an idea that’s going to make money. Because sometimes you wonder if you’re doing the right thing for the community — there’s a societal rule that I believe if you’re making money and benefitting off a community, that that makes you a bad person. So I had a lot of conflicting feelings throughout that entire time. I still believe in social entrepreneurship, but especially with the income disparity of the queer community, I don’t know how that would work. I wouldn’t want to charge an already financially burdened community to use something that might help them find friends. So in hindsight, I had expected the rigor of the classwork, but I did not expect the emotional rigor that I would be going through with my work at AC4D.

How did this empathetic research end up inspiring your ultimate project idea?

We started with our focus being simply the trans and variant community of Austin. We broadened it slightly to the queer community of Austin, which is slightly different than the lesbian and gay community of Austin. The queer community tends to include bisexuals, folks who are trans, gender queer, gender variant, asexuals, anyone who doesn’t exactly fit the norm of heterosexual or homosexual.

We recognized that there were a lot of resources online for people to talk together in the queer community, but ultimately, a lot of the people in the queer community couldn’t find other people in the community even in Austin. There were some pockets here and there, but it was rare to see people who had formed a pocket of community around themselves. A fair amount of people we had talked to felt isolated from the community, often through a series of events, or the way that they had chosen to live their life. There are folks out there that identify as transgender but at some point, they pass as another gender, and at that point, there are some folks who feel like they would rather pass as a binary gender (male or female). While that’s a choice they make for themselves, I also don’t think the community should be isolating or vilifying them for making that choice or vice versa, where “passing” for a binary gender is idolized or looked up to in a hurtful way.

So, this opportunity manifested itself somehow into a mobile application? How did your initial research translate into content or feature requirements for the interface to make it approachable and build community in a way that might be distinct from, for example, joining a Facebook group?

Queery is the name of the application. We devised it specifically for the queer community to talk about targeted subjects that were very relevant to them. These targeted subjects would include coming out and other queer related issues; if people wanted to know, for example, what shops were trans and queer-friendly. Those discussions were already happening online, but more often than not, we saw that people — the people who felt most positively in the community — were the ones who had a physical mentor there with them, saying, “Hey! Here are the shops you go to,” or “I have this doctor, or therapist, they’re very trans and queer-friendly, here let me show you to them.” Someone to sort of walk them through the steps. So, we devised Queery as a way for people to become mentors within the queer community who could be physically there for their mentees as well as a way for people to receive mentorship within the queer community.

It works like this: You are invited to queery by a friend. You create a profile and select a topic that you want to talk about and then it will select for you someone who is nearby who also wants to talk about that topic. The application will pick a coffee shop that is located between the two of you (without showing you the location of the other person) and then the two of you meet at that coffee shop. This serves as a neutral location to talk about whatever you want to talk about — that conversation topic is just a starter — but the intent is for people who have not met each other before to meet in-person in a coffee shop and get to know each other. It helps people on the outskirts of the community feel more connected to people within the community and helps us meet one another in person when we might have only met someone online. It’s a safe, secure way to meet people within the queer community that you might not have otherwise known about.

queery wireframes.
queery wireframes.

After the coffee shop meeting, the system allows people to rate each other and designate whether it was a helpful session for them, if the person was nice, etc. The ratings were helpful to assist in moderating the online community; if, for instance, someone who was rude or trolling entered the community, the system would remove them from the community. The only way to get into the queery system is similar to Gmail’s beta launch, which is to give an invite to another person. People who are already part of a community will start inviting their friends and then their friends will start inviting their friends and at least one person might vaguely know another person, but it allows those large pockets of communities to be able to be connected together through a friend of a friend of a friend. If you have someone who is at the epicenter of a community they might be connected with someone who is sort of at the farther branches of the community and it allows them to pull that person at the edge back into the community. That to us was the biggest thing — and the biggest thing we found in the research — is that if you have a strong community and you have a group of people in-person who are supporting you, then you feel like you have a good place in the world. If you struggle with depression or gender dysphoria you are less likely to act on impulses when you have a physical presence of a community because you are thinking about your own impact. The biggest risk to someone who is struggling or marginalized is being isolated from their community.

How did prototyping this system change the system or your understanding of the community?

One of the things that I realized through prototyping is that when you present people with a binary electronic system for community, people react to this in unusual ways. For instance, in the pilots that we did, we were able to match people up with one another for conversations but we found out later that it was actually better if a third person introduced them. It mattered was that there was a third person there to moderate if things went sour. Because this is a high-risk community, the risk of “going sour” isn’t as mundane as having a disagreement. Sometimes fights like these end in a deadly way. Prototyping surfaced even more challenges we needed to meet so that participants felt safe and comfortable.

Prototyping queery.
Prototyping queery.

Through prototyping, we also realized that there is a discrepancy between people giving information to the system and the desire to get information from the system. When we talked to people about their profile questions vs. the questions they’d want to ask the other people, the questions they wanted to ask other people were questions that they themselves did not feel comfortable answering. Questions like, what their transitioning status is, if they have a partner, what their sexual orientation is, etc. This isn’t information that someone would be comfortable giving out to a stranger, and yet, they reported that they would feel more comfortable if a stranger offered this information to them.

Prototyping also validated the benefit of queery which was when people walked away from the conversations, they felt better, felt like there were more people in the community who understood them and felt connected to the Austin community. In one of our pilots, there was someone from the trans community and someone from the asexual community who met together and the person from the trans community realized that they genuinely did not understand what asexuality was and how it functioned because they themselves were not asexual. The person from the asexual community realized that although they considered themselves part of the queer community, they had only ever hung around people who were heterosexual-leaning or otherwise part of the majority and they understood what it felt to be in the queer community.

The last thing we learned from piloting was that we shouldn’t just pair like with like but also make unexpected pairings because it’s beneficial for people to get to understand the breadth and depth of the queer community and understand someone who they haven’t talked to before. It helps people understand their differences while rallying around the fact that the queer community is just as diverse as its many, many members.

Let’s talk a little about Post-AC4D. Tell us about your experience at Frog Design and your insight after reflecting back on your time at AC4D.

I currently work as an Interaction Designer at frog design. I began by contracting with them. They liked me and I liked them and we decided to stick with one another, which has been a wonderful partnership. The reason I decided to pursue becoming a better designer in lieu of pursuing doing social entrepreneurship is that when I left AC4D I genuinely felt like I had to be a better designer in order to serve the queer community better. So my focus at the time — and I think my focus even now — is to hone my skills so that I become more useful to others.

I don’t think that queery would have worked in the state it was in after AC4D because I wasn’t as embedded in the queer community as I am today. I am now a regular member of several queer community meet-ups and work with an internal group at frog that promotes diversity and inclusion. I realize in my specific case, in order be helpful and beneficial and really design for that community, you have to be embedded in it. In my current position within the community, I feel far more able to help people. It has also allowed me to pursue other things that I thought I would not be able to pursue. Some of the work that I am doing is designing physical spaces, and it’s very exciting to be part of the wide breadth of work we’re doing here at frog.

Chelsea leading a design workshop.
Chelsea leading a design workshop.
 

The other thing here is the people. At the very end of the day, I got into Austin Center for Design because of the people and the reason I’m at frog is because of the people, because there are a ton of incredibly talented and wonderful individuals with whom I have been able to share programs with, I have been able to share the stage with at interaction16, and that I’ve been able to share my work with and become better. I feel like the work that we’re doing at frog is definitely targeted towards a different audience — but all of this work that I’ve been doing, I feel has the end goal in mind of helping the queer community. Even if it’s one small thing at a time. I just had a really great conversation with a good friend of mine who knows someone who is coming out and I was so happy to provide them with advice and information to be supportive during that time. I’m honored that they think of me that way. I didn’t have that kind of support and a lot of the people in the community that we’ve talked to in Austin, don’t have that support. The more I’m involved in the community, the more that people know that I am involved in the community, the more questions that get asked, the more potential link ups that can happen and the more people can become connected.

Is there anything else you’d like to share?

Yeah! One of the things that AC4D taught me is that in the world of technology — and in the world of design affected by technology — things tend to be in absolutes. For instance, Snapchat uses shareable design and all of a sudden everyone wants to know how to integrate shareable design into their application, or Facebook excels at being a viral social platform and now everyone wants to bring social into their applications. All designers and researchers at some point in their career get to the point where they say, “I thought this was totally a certain thing, I thought this was black and white but maybe I was wrong.” So my philosophy as a designer is to force yourself to look at everything in shades of gray rather than black and white because black and white is sexy and it’s something people are naturally drawn to, but people have a hard time finding the balance.

I think some of the greatest designers were the ones who achieved balance in their work and who have achieved balance of form and function. I get tired of hearing people say that one buzz word is going to be the magic bullet, because life isn’t that simple, it’s really complex. Just like the queer community, you can’t put someone in a box and expect them to conform to everything in that box. It’s not possible. Everything will bleed out of the box. We should stop putting people in boxes and allow people to be the weird, wonderful amoebas that they are.

Austin Center for Design is a not-for-profit educational institution on the East Side of Austin, Texas that exists to transform society through design.

myAT&T Re-design

-Getting into evaluation and usability engineering methods-

A brief recap of what has happened to bring us to the evaluation conversation

Last quarter we took a head first dive into the myAT&T mobile application. We talked to people about their most painful interactions with this application and plotted our findings against each other.pain points chartThrough this ranking of difficulty, we came to understand the most common pain points. From there we went into the app itself and studied the ways those actions are executed in the current experience. It was a patchwork of an experience. There were multiple ways a simple ‘+’ button was used, to give 1 example. It truly seemed like developers had stitched together multiple different attributes created at different times.

We then went into sense making. Plotting the verbiage that was particularly important to this specific experience and the 6 tasks we had identified. We plotted these nouns in terms of their relationships with each other. These connections needed to be thought about critically. It was not just a site map, it was connections both tangible and intangible, what was the back and forth of attributes to accomplish common tasks? Noun matrix v2After this initial sense making, we made concept maps which I blogged about and you can find that here. This allowed us to map the connections within the app in a way that imprinted them into our minds. This activity is exponentially important so that moving forward with creation, ideas and redesign we could quickly reference the important details and how they connected to other key components to enable action. After fully understanding the ins and outs we consciously tried to strip away all constructs of what the experience currently looks like. Divergent thinking. Push your mind into new territory. What would simplify? How could this action be streamlined? How can we innovate? In this phase, we allowed ourselves to be unrealistic, no constraints. To translate this expansion back into the applicable context is difficult but needed, to be effective. Here is the blog that I wrote regarding the portion of the process walking you through divergent thinking and into initial paper prototype sketches.

Bringing this comprehension into digital space for the first time, I felt confident. I was quick to learn that I did not have the capability to see all of the details yet. There are things that one cannot be aware of until their attention is explicitly pointed towards the details that are imporant. And often the most important details are the hardest ones to see.

Evaluation Explanation

Which brings us to evaluation and product management. In this class, we are learning how to evaluate the learnability, usability and, essentially, effectiveness of a digital interface. The methodologies we are learning are the best-known combinations of effectiveness while also being inexpensive. The methods are called Cognitive Walkthrough, Heuristic Evaluation, and Think Aloud Protocol. These methods, in combination with eachother, provide a holistic view into the issues that prevent ease of use for a digital interface.

Cognitive walkthrough is a method for observing and assessing the learnability of a product. This method is based on a theory about the way that people analyze and solve problems. The way that I have started to think about it is like the signage of a grocery store. If our user wants some cheerios what words are they going to look for? What other things would they naturally associate as surrounding products? etc. It is performed by walking through the digital experience, screen by screen and asking the series of questions as follows:

  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 their goal?

From this, a designer gleans the knowledge needed to make sure that the experience invites the user into it in a way that makes sense to them.

Think Aloud Protocol and Heuristic Evaluation are for gauging the overall usability of the interface. Think aloud protocol is a process that a designer facilitates with actual users who have never seen the product before. This is to create an unbiased set of responses. The user is asked to run through a prototype and verbalize the actions they are taking and their thought process to get there. To give an example, if I was opening a door handle my thought process may go something like this “Alright, I am going through the door, I see the door handle, I know that I need to turn it, I turn it, go through it and close the door behind me.” The only words the evaluator uses are “Please keep talking” if the user falls silent. This verbiage is so that they don’t go into introspection, they continue to be focused on the interface rather than think about their answer or if it is good enough. The reason you want to avoid the introspective effect is that this activates a different part of the brain than operational, task oriented thoughts do. The way I think about this one is it is like the grocery store signage designer observing real shoppers walking through her/his systems. Is it being used the way the designer hypothesized? Everybody’s brain works differently, in different patterns, with different values. Then, on the contrary, there are those things that make sense to everyone and everyone can relate to, understand and abide by. Which leads us into Heuristic Evaluation. A metaphor to illustrate the way I think about viewing a digital product through this lens is its like the rules of the road. The heuristics of the road. You have your different kinds of lines (double solid yellow, dashed etc.) on the road that mean different things. There are guidelines for what to do and what not to do. Similarly, there is a common language, and a common list of best practices for mobile applications. Do’s and don’ts. You can build the most gorgeous car ever but if the size of the product is the width of two lanes of the road, your car will not be effective and will never be used. The same goes for heuristics in mobile applications. The heuristics to hold a creation up against are as follows:

  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

These are exponentially useful for understanding applications in general and the common language that is behind the creation of any digital products. These are the kind of details, again, that are the most important…. So important, in fact, that when they are well executed, the user doesn’t even notice they are a thing that someone has to think about.

The utilization of evaluation

As explained, the 3 kinds of evaluations are valuable for different reasons. I used them in a particular sequence that I found to be very effective.

During last quarter, we did multiple iterations of our screens and in between the last few iterations we used Think Aloud Protocol. This quarter, I knew that I had some screens missing. Such as, when something needs to be typed in with a keyboard, I had the keyboard appear fully expanded without a screen for the tapping action that precludes the keyboard being on the screen. The screen on the far left, below, is the iteration before evaluation. I then added the screen to the screen in the middle to preclude the screen on the right to mitigate this keyboard issue as well as protect users passwords because I realized that showing a users password from the get-go was a major security issue.

 Screen Shot 2017-01-19 at 9.11.04 PMScreen Shot 2017-01-19 at 9.10.04 PM

So, for this reason, and knowing that Cognitive Walkthrough is for checking the learnability of a product, I used this method to find the places in the experience where I needed to add less important, filler screens such as the keyboard example. This worked well because it opened my eyes to other details that felt abrupt. The things that I didn’t make the user ready for.

After adding these screens and noting learnability issues I moved on to heuristic evaluations. I had 5 evaluators look at my screens and log the feedback in a spreadsheet. As I got comfortable in using this evaluation I started to not have to reference the list of heuristics, I would just start to see the issues and why they manifested that way. I think learning these methods alongside actually building an app is such a valuable cadence for learning because on both sides of the equation; evaluation vs creation, the learning is applicable. I am excited to rebuild the rest of my screens for this AT&T redesign and am even more excited to begin on the creation of my own application from scratch with all of these “rules of the road” ingrained into the way I look at interfaces now.

Lastly, I did a few Think Aloud Protocols saw that in a lot of ways, users were doing what I thought they would do, and in a lot of ways, they weren’t. Work to be done! Improvements to be made!

Breaking down evaluation findings

I’m going to start at a high-level description of the synthesized take always and then break them down in terms of where they came from and how they inform redesign.

Takeaways:

The experience felt discombobulated. There is little to no feeling of continuity. The user always feels slightly unsure if they’re doing it right.

Attributes and/or features are not effectively communicating their purpose. The design does not provide clarity.

Visibility, control and freedom are huge overarching issues. Each screen is separate with separate actions and it is relatively arduous to go back a couple steps to change something.

Hierarchy and priority are not clearly visualized. Everything feels the same. The design does not draw the users’ attention to the next step.

From Cognitive Walkthrough I learned a lot about verbiage. The wording and phrasing is so important to afford the right actions findable. This also ties in with difficulties in navigating. Navigation flaws are very often linked with the wording that is used to inform movement. Navigation was also inhibited by screen length, mostly in regards to where the screens were getting cut off. I did not think about screen length or scrolling at all in my first phases of design so this was a huge learning. And lastly Cognitive Walkthrough was an excellent method for finding screens that were missing as I said before.

From the Heuristic Evaluations I began to see the gestault of failure in overall visibility of the app and where users were in completing tasks with multiple steps. I found that my users, often times, did not have full control of their experience. There were actions and buttons that were the end all, be all of a task and the user did not have full freedom, I was mandating them fitting into my ‘template’ of actions. And lastly from Heuristic Evaluation I more fully understood the importance of users being able to recognize something as opposed to recalling it from previous usage. This is especially significant in the context of the AT&T app because I assume that users don’t interact with the experience more than once per month. Compliment this with the fact they users probably want to get in and out fairly quickly, recognition should be highly valued.

Lastly, Think Aloud Protocol made me understand more thoroughly the power and importance of word choice. What is applicable to the greatest number of people? I was approaching the initial creation of the application with a  very minimalistic mindset. I felt, and to a large degree still feel, that at this day in age simplicity is largely important. However, when it comes to sensitive information, money, or actions that are difficult to reverse, customers are very tentative and protective of their space. Therefore, enough information needs to be handed to them so that they feel they have full comprehension of what is happening. And sometimes, in the right circumstances, that is a short text block. The combination of explanation and action is important.

Redesign based on evaluation

I will illustrate the redesigns I have made in the context of a flow of screens that are about the action of ‘Upgrading a device’. I chose this flow because it housed all of the issues identified above in some capacity.

First let me break down some of the changed attributes…

I changed the attribute that compares the data used by individual users on the account to the amount of data the account as a whole has. This was informed by a misunderstanding of the comparison of its initial, more boxy, vertical format, with the other ways that timelines and data were visualized.

This first visual is how the billing cycle and data are displayed:

Screen Shot 2017-01-18 at 6.26.55 PM

Take that into account when looking at how individual users data usage are compared with each other. The formatting is utterly not the same…

Screen Shot 2017-01-18 at 6.26.21 PM

Which brought me to the following design:

Screen Shot 2017-01-18 at 6.27.53 PM

I changed the boxy attribute to be the same shape as the other barometers to provide ease of mental digestion of the information.

In terms of wording, I changed quite a few things. To give a few examples, I changed:

Screen Shot 2017-01-18 at 6.24.43 PM

ToScreen Shot 2017-01-18 at 6.24.28 PM

Because I learned, in think aloud protocol that this could be perceived as a positive amount of money rather than an amount that needed to be paid.

Another wording change was from ‘Devices’ to ‘Devices & Users’ on the tab bar.

Screen Shot 2017-01-18 at 6.23.50 PM

To

Screen Shot 2017-01-18 at 6.24.08 PM

This was significant because people were going to the “plans and usage” tab for actions regarding individual users’ information in regards to data rather than to the ‘devices’ tab. Which is fine, but not intended and in 1 circumstance was detrimental to the desired action to be achieved.

To give you a full sense of the changes I made and how they manifest here are my old and revised flows back to back.

First is the old version of ‘Upgrading a device’:

Upgrade a device 1 - originalUpgrade a device 2 - original

Then here is the redesign:

Upgrade a device 1 - redesign Upgrade a device 2 - redesignThe umbrella goal of the revision is to provide ease of back tracking. Buying a phone is a complicated transaction with a lot of steps and a lot of details and it is satisfying being able to see all of the things you have chosen while you are making your next choice.

To summarize my takeaways; this is how I will be thinking about these methods of evaluation going into the future.

Cognitive walkthrough:

What invites users in the experience in a way that makes sense to them?

 

Think aloud protocol:

What doesn’t make sense at all?

 

Heuristic Evaluation:

Structure and guidelines – what are people used to?

 

In combination, these provide clarity and insight into how to make products that people love to use.

You can see my full presentation AT&T Evaluation Deck here.