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.
Next, Chap and I went through each flow screen by screen and feature by feature as I explained the system to him. This turned into a conversation about the system from a developer’s perspective, especially when it came to back-end functionality (where the app will get its information, such as how much data the user has used for the month). This brought to the surface how a seemingly simple feature can turn into a much larger feature, which can then be reevaluated on how important it is to the experience.
During this conversation Chap and I also logged how long he estimated each one of these features would take to develop into a spreadsheet. The spreadsheet included columns which consisted of screen ID, feature description, points, days estimated to create (with two developers working 8 hours each day), any notes that may be relevant, and the price associated with each feature. We also used a point system to establish the number of days it would take to create each feature. A point is representative of a “man day” which is a whole day of a developer working for 8 hours. This is normally documented using the Fibonacci sequence: 0, .5, 1, 2, 3, 5, 8, 13… The problem with this type of estimation is that is typically very inaccurate due to being very difficult to estimate this type of work, unless you have years and years of experience. Typically the work is underestimated. Despite Chap having plenty of experience, he acknowledges this by subtracting .25 points per developer per day, as well as adding an additional 30 percent to each estimation.
For this project we estimated the time based on two developers working full time (40 hours a week). Overall, Chap estimated my app to take about 53 days with two developers working full time. The benefit that came from this included being able to quickly glance and see which features take up the most resources, which can then be passed to a product manager for prioritization.
Here is what part of the spreadsheet looks like. Click here to see all of it.
We didn’t have a designated product manager for this project like we did a developer, so we are taking on that role. The challenge for the product manager comes from the fact that we only have 20 days before we need to ship the product!
This is where the skillset of a product manager becomes extremely valuable. They will help prioritize which features are the most important to the user to establish a v1 release, followed up by a roadmap and timelines in which the rest of the features will be added to the app. Part of this exercise will be to modify the existing flows based on this prioritization to meet that deadline, while still retaining as much value as possible. Stay tuned for the next blog post to see how this looks.