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.