Sizing a Design
A couple of months ago I was working on redesigning the Wells Fargo banking app. I restructured it, simplified it, and created wire frames for all the essential flows a banking app should include (in my opinion), as well as some additional capability that Wells Fargo currently doesn’t offer.
Now it’s time to talk to a developer and size the design.
Sizing is the process of understanding how long it will take to build out different components and features of the app. A component would be something like a dynamic list, such as this transactions list below:
A feature would be what that dynamic list does. In this case, the transactions list populates and displays the latest transactions from a designated account. For each screen created, I marked the component, gave it a name, and described the feature below the component name.
When I met with a developer to discuss the design I printed out all of the screens and taped them down onto big sheets of brown paper. This way we could write on them and look at them all at a glance. I put a small pink sticky note next to each component and a small blue one described the feature.
Mark, the developer, made his estimations according to flows. He thinks in days and carefully nodded along as I walked him through each screen. We marked up how long things would take on orange stickies along with new things to think about for different components.
Mark was great, and I had been particularly interested to learn what it’s like to work with a developer. He pointed out several holes in my design, things that hadn’t been thought through. I knew he was going to try and do this. In fact, right before I went to meet with him, I threw together some quick ‘error state’ screens, and patted myself on the back for being well prepared.
“But what if they lose connection in the middle of a transaction? If they just refresh, will it send the transaction twice?” Mark asked. Clearly it wasn’t his first time thinking through these things, and it was enormously helpful to hear his insights.
From Mark, I also learned how much I didn’t understand about how certain systems work. Like how when adding a new bank account that’s outside the system, I had set the system up to search by name of the financial institution. But really we just need the routing number and account number to confirm the account.
Perhaps most importantly, he got me thinking about how using similar conventions and components that repeat throughout the system save the developer a lot of time. I noticed I often changed things later on as I designed, and didn’t go back to make sure I was utilizing the same conventions. It got me thinking about how I was not only giving more work to a developer, but I was also making the user’s experience more confusing and less cohesive.
The next step in sizing is to document all the components in a spread sheet and list how long it will take to build each part out. I did this in two ways. First I created a sheet with columns for the types of components that could be found.
Then, on a separate sheet I listed all the flows and put all of the components into each flow along with their feature, and screen. Here is where I listed how long each flow would take, and I added comments from my discussion with Mark on certain components.
Over all, he estimated that it will take about 93 days, or 4.5 months to build everything out. If there were two developers working full time on this project, I could have this version of the app done in 2.5 months. This seems really quick!
But how do we know this estimation is correct? Sizing estimation (so I’ve been told) is extremely inaccurate. However it’s good to get some type of scope for what it would take to build something.