From myAT&T to yourAT&T – Design Strategy Feature Brief

AT&T is a complex product that needs to do a lot of things. Things like pay bills. Buy devices. Observe different types and levels of data etc. An application that spans across commerce, finances and data usage holds a lot of complexity and therefore is inherently difficult to make in a simple fashion while still scoring high on usability tests.

The steps bringing our designs to this final stage have been arduous and many. They include conducting research with people who currently use the myAT&T product where we gain a comprehensive understanding of how it feels to be a person in direct relation with the various attributes of the product.

From there we mapped the connections between attributes and tasks. Understanding what features and components were and/or could be related to each other was key to making an experience that makes sense. Then came development of the wireframes from sketching to digital.

It then got exciting going to meet with a developer and get the creation sized up for a development timeline and then thinking critically and strategically to put those timelines into a roadmap and action plan.

In creating the Feature brief, or final document, the process is to pull the most essential and impactful pieces out from all of those processes and aggregate them into a story. This was the most clear example of always having more information than you can articulate concisely.

It was cool to see how fluent I was in this product. When you’re in the thick of a certain part of the process, its often hard to see the full value of what you gleaned from each step. Creating a Design Strategy Feature Brief is a sure way of making sure that you have dumped each portion of your knowledge on the project at hand, onto the paper or screen in front of you.

In research I was noticing 3 main things:

 

  • The AT&T mobile application is not a place where users go to “hangout” for pleasure.
  • The existing in-app experience feels like a conglomerate of different development efforts that have been “patchworked” together.
  • Users are confused by the multiple routes there are to the completion of a task.

 

The first one is pointing towards the PURPOSE of the application. How do people naturally use the thing?

The second one is regarding CONTINUITY. The current state of the application feels like it was trying to cram all of the needed attributes in the experience without thinking about things like flow, continuity, number of steps, recognition vs recall etc.

The 3rd one is regarding the actual FUNCTION of the app. How does it relate with itself? For example: There are 5 different ways a ‘+’ sign is used in the current experience.

These observations informed my design decisions. The abstraction of these observations told me what I should do…

  1. The product should provide the ability to quickly complete actions
  2. The product should feel like a cohesive, trusted experience
  3. The product should provide clear pathways to the tasks users want to complete

All of these behavioral insights and design principles are pointing towards an overarching theme of efficiency and trust being held as the highest values. Therefore with all of my thoughts I was trying to condense information. Provide more streamlined ways of moving through the experience.

The value that I promised to deliver came to this:

I promise to help AT&T customers rapidly accomplish tasks with ease while feeling in control of their account.

This massively influenced my UX and UI decisions. Especially because of the discombobulation of the current experience I was set on making it fluid and easy to be fluent in, as well as quick to develop. I was looking at this project as relatively start-up style. If I was on a guerilla team trying to get this product out to the AT&T customers because the current experience is so “broken”. Therefore I changed much of my navigation to standard iOS components to be able to get it out the door more swiftly.

In considering this drastic of a change. What, really, is a change of company posture and approach. I started to think about how a company would launch a change like this. A Feature brief could be the perfect spot to initiate that kind of conceptual, company perspective change.

Context

yourAT&T Feature Brief V3

AT&T Redesign Brief

Welcome to the final installment of the AT&T Mobile Application Redesign. For the past eight weeks we’ve been refining our designs, tested with users, sliced through features to fit into a release timelines and now we can deliver a final strategic design brief. This blog post contains a description of the final iteration of the application, the collection of the Insights & Value Promise, the construction of the strategic road map, and finally the culmination of combining all the elements into the brief itself. The final version of the brief can be found at the end of this post.

The first task that needed to be tackled was another redesign of the application. The additional challenge was that this iteration needed to be completed in Sketch instead of Illustrator. In order to complete this I first needed to get an IOS toolkit & some icons build for Sketch and watch a few quick tutorials. After that, I was ready to go. It thankfully wasn’t a complete redesign of my application. For example, my flows that had been established and the features I had created, both of these were keep in the redesign. It was more like I was redesign the layout of my application. Sketch also makes the creating of an application extremely simple once you’ve already gotten a toolkit. All total the redesign took me a significantly less amount of time. Below is an image of the Billing Page from the last iteration (left) and the most current version (right), to give you a sense of what was leveraged from the last iteration and what this final version looks like.

AT&TRedesign-01

Once I had finished redesigning my application, I could move forward with other concrete pieces of the Design Brief. The next portion I chose to complete was to collect and revise my insights and value promise. Again I didn’t have to completely rewrite the insights or the value promise, but both of these elements were a bit rusty since they hadn’t been reviewed in a while. The final insights I decided to include within the brief were:

 

  1. Customers only spend an extended period of time in the application if there is an issue with their account.
  2. The lack of standardization of visual design within the application cause users to feel disjointed when navigating a flow.
  3. The diverse capabilities of the application are overshadowed by feelings of confusion and frustration.

 

With each of these I added an explanation containing their significant and evidence from research. These would be integral for an individual reading the design brief to understand what prompted my reason for every design decision.

I also had to review the Value Promise, so that individuals reading the brief would understand what was the goal of my application. During class Jon had said the Value Promise had a structure to it. The first part is a quantifiable goal for the application to strive for, the second is a reason for that thing. For my AT&T application redesign “We promise to expand customers’ knowledge and use of the application, so that they can feel a sense of control over their account and service”. The quantifiable part is a user’s knowledge and the reason is so they have more control over their account. Each of these elements began to feel more concrete and substantial enough to put them into the brief.

The next piece I began to focus on was the Strategic Road map. This was introduced to me with the initial assignment. Jon had shown us an example on one, and explained how it’s very similar to a Product Road map. The key difference is that this map does not contain dates or resource allocation. Before I began my own creative exploration of this map, I did some preliminary research around what these typically look like. Once I had gotten a better idea of what the layout and structure should look like, I began concepting my own. Below is an image of that first sketches I did before moving into Sketch.

 

IMG_0382

 

I decided to move forward with the bottom right design. The gradual decrease of the triangles perfectly represented the decreasing workload for the team. It also made breaking out the different phases of the release easy to represented. Once I transitioned the file into Sketch I keep messing around with the various elements: the capabilities’ location, the colors, the shape of the triangles. I never felt it was communicating its intention. I decided to show it to Sally and Conner who pressed me with questions about the design. This conversation though short, gave me insight into what elements the design wasn’t communicating properly. For example, Conner asked about the color choice and after explaining the reasoning, I understood that for him the current color options weren’t conveying the idea of a continuing development. So I went back to Sketch with their questions and feedback fresh in my mind and I tweaked the map to be more inline with what I wanted the audience to understand. Below is a PDF of the final image that is included in my design brief.

 

Roadmap.

 

Since we had already defined the features and controls when meeting with our developers, I know I didn’t need to redefine them again for the Feature Brief. Instead I now needed to build out my actual brief. Knowing from the beginning that the brief would be printed out, it was recommended to build it out in Indesign. This way I could control the layout and size of different elements more easily. Jon gave Elijah and I a quick tutorial as a starting point, and then I began my brief. I was finally ready to begin compiling all the elements into the one document. As I went along adding the Insights and Value Promise I realized the transition was a bit rocky. To provide a smoother transition I decided to add in Design Ambitions, which I considered to be large overarching aspirations that support the Value Promise, but are also parallels to the insights. These gave a direct connection to the Insights and helped support the Value Promise.

Once I had completed the Overview, Insights, Ambitions, Value Promise and Strategic Road Map; the Capabilities came next. This section contained each of the different features with a description so that anyone can see the feature and its value for the application. To help prompt my description of the features, I merely posed the question “what does this do and what does the user get out of this?” Then I also tried to tie each feature and its abilities back to the North Star of user control. That way the reason is clearly defined for the feature.

I ended up doing three other iterations of the full book. Throughout each iteration I would print out a few of the sheets to decide on a layout. Below is an image of two different layouts I tried while reviewing, I ended up going with the option on the right.

 

IMG_0385

 

The review process, both editing written content and reviewing layouts, helped me to narrow down and polish the final design brief. I especially found it was useful to flip through the final PDF’d brief to catch any misplaced texts or images.

Ultimately the process of combining information and polishing a brief was arduous, but the effect of feeling a printed out piece of my own efforts was rewarding. Below is a link to the final PDF Design Strategy Brief.
AT&T, Design Strategy Brief

Product Management Part 3: Feature Brief

Over the past two quarters, the class has gone through a process of redesigning AT&T’s mobile application. This process has included:

  1. Brief research to find pain-points within the current app and to uncover what’s most important to the user when managing her mobile account.
  2. Concept modeling to understand the key functionalities of the app.
  3. Ideation to design new flows.
  4. Evaluating, testing, and iterating on those flows.
  5. Estimating how long each design would take to develop.
  6. Creating a product roadmap, detailing how and in what sequence each flow would be built.

Our latest undertaking is the Feature Brief. A Feature Brief is a document that presents a simple, cohesive vision of what you should build and why you should build it. It acts as a north star for the product and its development.

The Feature Brief communicates insights found through research, design pillars inspired by the insights, what value the product will deliver (the value promise), a high-level description of the app’s key features and capabilities, and a roadmap of how a team will build the app.

Insights
Through a brief stint of research, I observed the following:

  1. People have an emotional attachment to their phones, acting as an access point to their social networks.
    love
  2. Customer’s usage varies throughout the billing cycle, leaving them wondering if they will exceed their limit.
    unknown
  3. AT&T offers an overwhelming amount of features and add-ons, distracting the customer from their primary needs.

overwhelm

Design Principles

Based on the above insights, I crafted my design to follow the below principles:

  1. Our product should make customers feel secure that they will always have access to their phones and their usage will never be threatened.
  2. Our product should give customers a clear understanding of their data usage and protect them from overage fees.
  3. Our product should prioritize what customers want to see, and progressively reveal more advanced features as the customer indicates interest.

The Value Promise

The value promise encapsulates the three design principles: Our promise is to give customers complete control and clarity around their mobile phone usage.

Key Features & Capabilities

Our research determined that the following capabilities were most important to customers:

  1. Make a bill payment
  2. Set up autopayment
  3. Manage data usage
  4. Change plan
  5. Upgrade phone
  6. Edit Account Settings

These determined the features & capabilities outlined below.

myAT&T Redesign Feature Brief - Sally images.011 myAT&T Redesign Feature Brief - Sally images.012 myAT&T Redesign Feature Brief - Sally images.013 myAT&T Redesign Feature Brief - Sally images.014 myAT&T Redesign Feature Brief - Sally images.015 myAT&T Redesign Feature Brief - Sally images.016 myAT&T Redesign Feature Brief - Sally images.017 myAT&T Redesign Feature Brief - Sally images.018 myAT&T Redesign Feature Brief - Sally images.019 myAT&T Redesign Feature Brief - Sally images.020 myAT&T Redesign Feature Brief - Sally images.021 myAT&T Redesign Feature Brief - Sally images.022 myAT&T Redesign Feature Brief - Sally images.023 myAT&T Redesign Feature Brief - Sally images.024 myAT&T Redesign Feature Brief - Sally images.025 myAT&T Redesign Feature Brief - Sally images.026 myAT&T Redesign Feature Brief - Sally images.027 myAT&T Redesign Feature Brief - Sally images.028 myAT&T Redesign Feature Brief - Sally images.029 myAT&T Redesign Feature Brief - Sally images.030Strategic Roadmap

To build this app, I created a high-level strategic roadmap, outlining the order in which each capability would be built.

myATT Strategic Roadmap - Hall

myAT&T Strategic RoadmapmyAT&T Strategic Roadmap

AT&T Redesign Features and Functionality

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

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

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

Which brings us to our next insight into user needs:

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

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

What do all of these mean?

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

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

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

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

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

Full Account Control

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

3.10      6.11       8.4

Users Need Simple Familiar Navigation, and Obvious Wayfinding

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

6.5      6.8       8.3

Users Want to See Their Progress to Monthly Limits

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

2.1       2.2

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

Timeline.2

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

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

 

Product Management Part 2: Product Roadmap

Over the past number of months, we’ve worked to redesign AT&T’s mobile app. This app allows customers to pay their bill, change their plan, manage their data, and upgrade their phone.

Roadmap

After designing the ideal flows, we worked with developers to estimate how long it would take to build each capability. Based off of this information, we created a product roadmap, a horizontal timeline demonstrating how and in what sequence we would create each flow.

Although we designed for an ideal state, without time or financial constraints, the product road map demonstrates how we would ship the app using two developers, releasing a minimum viable product in one month, and two updates released over the following month.

myAT&T Roadmap v3

The road map isn’t meant to track the project hour by hour, or feature by feature. It’s simply to give a general priority and visual timeline for the build out.

Thin Slicing

To fit the first release into one month, we went through a process of “thin slicing.” This means removing capabilities that are not essential to the functionality of the app, while maintaining the app’s core value.

In this instance, we cut out some features within flows, as well as removing whole flows altogether. For example, within the Make a Payment flow, we cut out PayPal and Apple Pay from the minimum viable product and included them in the second release. As paying with a credit card or checking account are available in the first release, these methods were convenient, but not essential.

We also simplified the interaction, exchanging radio buttons and a button for a table. Lastly, we also removed the customized line within the tab bar, as again, it was not essential to the app’s functionality.
Payment 2 Thin Slice Payment 2 Version 1

Whole flows such as Changing your Plan and Upgrading your Phone were also left out of the first release, as, again, they are not core to a customer’s management needs. I will note, however, that although Changing your Plan was not in the first release, we still allowed the customer to control her usage by including the ability to activate “slow mode” (preventing data overage fees), purchase more data for the month, and suspend/deactivate your phone.

For the first release, we prioritized structural components such as the tab bar and the page titles, as well as the following capabilities:

  1. Log in & out
  2. Make a Payment via credit card & checking
  3. Set up Autopay
  4. Data Management: Activate “Slow Mode”
  5. Suspend Device
  6. Get more data for the month

Here is a complete view of the minimum viable product:

Make A Payment for print

Autopay for print Data Slow Mode for print Data: Top off data for print Devices: Suspend for print  Login & Homescreen for print

Log out for print

The following will be included in the second release:

  1. Make a Payment via PayPal & Apple Pay
  2. Account Management
  3. Change Plan

The third release will include:

  1. Upgrade phone

Road mapping from Design to Development

In my last blog post I discussed the process of going to an application developer and estimating how long a build would take. Specifically, the redesign of the mobile experience that myAT&T offers for iOS.

Since then I have mapped out the road map to bringing the design into reality based on the estimations that came out of the developer meeting.

I approached this task through 2 lenses simultaneously. The first was assessing what unique capabilities and benefits does using your AT&T application on mobile have as opposed to a brick and mortar store or the online web application. The mobile application is unique in that you can access it anywhere, at anytime. Filtering through the tasks deemed most important from our user research:

  • Make a payment and set up Automatic payments
  • Suspend or remove a device
  • Change a plan
  • Set and update account security
  • Compare usage to available plans

And

  • Upgrade a device.

What is most important? How does the mobile app make any of these more valuable?

Changing a plan

The reasoning behind a user changing their plan comes down to how much they are using their phone. Usually people use more data than they have allocated for themselves. Therefore when you are nearing your data limit, if your phone reminded you of that unfortunate event and you had the myAT&T application you could change your plan right then and avoid future charges.

The second lense that I assessed things through in parallel to the first was the fact that this is a mobile application. It being a mobile application that houses sensitive data and potentially vulnerable actions means it needs to be secure. For this reason, partnered with developing the Change a plan flow I developed the Login, Add Card, and Add billing address  flows simultaneously.

This development method of moving forward the functionality that was pertinent to the mobile medium as well as functionality that was pertinent to the user felt like an effective plan for providing value to the parties that really matter.

17

myAT&T Product Roadmap

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.