Three’s A Crowd: Designers, Developers, and Clients
So far in our Product Management class at AC4D, we’ve re-built and tested a banking app with wireframes (mockups of how a screen will look). Subsequently we met with software developers to gauge the feasibility of our new features.
Over the last two weeks we’ve slowly added another perspective in our design mix- the client. Unfortunately, the good folks at Ally Bank (the online-only bank I’ve chosen) haven’t been able to visit our Austin, Texas studio, but as designers we’ve begun to create artifacts that speak to precisely how our apps will meet client needs.
How We Deliver
Each of our banking products requires a product roadmap to show who, when, and how our banking app will be delivered. A flow is a set of steps a user needs to take to accomplish a goal. Let’s take my Log-In flow as an example:
My developer mentor estimated that this flow would take three working days for one developer to complete. Our assignment had us operate under the assumption that we have two developers working 40 hours a week to build our app.
Product Roadmap: Ideal State
My product map is structured on two axes: time (in days); and resources (in this case, two developers to do the work.) Log-In, a mandatory task for any banking app, should come early in the process. Notice Log-In is first in Developer A’s queue. I tend to make first versions on paper and whiteboard for efficiency.
I then digitized this version of a product roadmap:
This is where an inefficiency appeared. Developer B had a lot less work, so I moved around some flows in order to balance the workload:
Now the workload is more even between developers.
App development (and interaction designers) generally work in “agile” workflow systems. This means that multiple tasks can be accomplished at once. In other words, it’s the opposite of an assembly line where “A” must happen before “B.”
While I could have even moved flows around further and end up with one “open day” per developer; the flows have a general sequence logic. I wanted Developer A’s “Log In/Log Out” flow to occur in parallel with Developer B’s “Security, Privacy, Forget Username & Password” flow. They may have similar issues, and can collaborate if problems arise.
In this “ideal state” roadmap where we take as long as we need; in total the core app development will take 42 days workdays, or 22 actual working days for developers.
Product Roadmap: 20-Day Releases
Often, designers and product managers don’t finish an app in one attempt. More often, firms publish a base functionality, and continually add and update features. In our assignment’s second scenario, I imagined publishing app features in 20-day increments. In my particular case, my whole app took 22 total days, so I inserted extra features and functionalities (like Live Chat help) to make my banking app more robust.
This how my product roadmap changes with this 20-day constraint:
Here we see significant features added at the 40-day and 60-day mark. I also changed “open” days to “QA/open” so our clients will know we’re completing a quality assurance process at the end of our 20-day sprints, rather than taking a day off.
A Roadmap for All Audiences
The roadmap above is not client-ready. While a draft roadmap is instrumental in getting developers, designers, and product managers on the same page; it’s too grey and dull to be put in front of a client. In order to gain the client’s trust in the process, a little bit of clarity and color can lessen a client’s worry.
Here’s a more polished version:
With this roadmap, all audiences can feel that there are clear and legitimate benchmarks that will be meant. Some journeys are better without maps, but for adventures in app development, a product map is a must.
You can view all of the above artifacts in one PDF sequence here: https://drive.google.com/file/d/1HyraIUGcH4Q5xmwW12zvk5XnNB-zaLvn/view?usp=sharing