Are You Building Apps with Waterfall – without realizing it?

Thirty years ago, software was commonly developed using the Waterfall model: software was built in distinct and rigidly planned phases (requirements, architecture, programming, integration, testing). Fat, important deliverables allowed the project to pass from one phase to the next — high-level and detailed specifications, requirement documents, QA report documents.

Waterfall has proven massively ineffective for software projects. It was gradually supplanted (except perhaps in corporate behemoths and government contracts) by the agile methodology, a way of building good software that builds on collaboration and cooperation, iterative learning, and constantly delivering working products.

These days, all respectable mobile app teams profess to be agile. Yours surely is, right? Wrong. Sure, your developers do scrum and you have weekly sprint releases and continuous integration. But how do the developers know what to build?

All too often, apps are actually built like this:

1. a requirements or product owner person integrates stakeholders’ ideas into a tangible set of formulated problems;

2. an interaction designer then solves this problem with a UX concept and documents it with wireframes;

3. a visual designer then creates a design language and the corresponding assets;

4. the developers takes all of the above, writes the code and brings the app to life (using agile methods and all);

5. and you may even have a QA team making sure the living app actually implements the UX concept and that the graphical assets have been integrated correctly.

And there you have your waterfall model. If this sounds familiar, it’s because too many app teams still work this way.

I have seen developers refuse to start implementing a feature before all localized strings and assets are “final-final”. A simple helper app is not going to fix this cultural problem.

A more parallelized workflow

But what Placeholders, my new little $1.99 Mac app, can do is to make it easier to work more collaboratively and let developers start implementing a screen without all assets being ready.

Placeholders allows for a more parallelized workflow:

1. Ava wants to start coding a feature, but the assets for it haven’t been created.
2. She uses Placeholders to create stand-in assets that she uses to prepare her layouts.
3. When Bob, her designer, finds time to craft the actual assets, he simply replaces the placeholders with the pretty assets. (You know, there’s this nifty Mac app called Gemba that makes it super-easy for designers like Bob to update the images all by themselves, without needing to ask and wait on Ava to integrate them.)
4. In the meantime, Ava finished building the feature’s functionality. Now that Bob has integrated the final images, they can ship the feature. *Hooray!*

Made for iOS & Android projects

Placeholders was created with iOS and Android product teams in mind, so it creates all the right image variants and puts them in the right places:

• For Xcode projects, it adds an Asset Catalog imageset with @1x/@2x/@3x resolutions.
• For Android projects, it creates placeholder images for all your densities (ldpi, mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi) and puts them in the respective res/drawable-{density} folder.

Running lean by working collaboratively

In Lean UX, Jeff Gothelf writes that the most innovative teams work together closely on the product. Instead of delivering stuff to each other (requirements, wireframes, assets), they feel collective ownership over the product and improve it incrementally.

By putting walls (i.e. phases with deliverables) between different parts of the product creation, we are wasting a tremendous amount of resources. Instead, let us work together more tightly, let us be open to exploration and iteration, and let us ship features and improvements faster to learn from actual user behavior.

It is my hope that Placeholders may be a humble contribution to this change.

Placeholders is available on the Mac App Store.