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.

 

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 20 man days. Stay tuned for Part 2: Thin Slicing & Road Mapping.