Projects

The following sentence will sound like a cryptic puzzle, but hear me out:

The way we advise approaching Projects is to firstly create Projects for each of our product’s user flows, and then split these further into work that has been ‘shipped’ and work that is a ‘feature,’ currently in progress.

In practice, this could look like the following:

Building for specific user flows

We can split our sample Web project into each logical user flow—log in, registration, search, purchasing, user settings, etc.

By splitting up our design work into specific flows, we can ensure that our files are compact enough to ensure value, but broad enough to allow bigger picture thinking. This also allows for designers to perform user testing on, and contribute to, end to end processes within your application without being too concerned with irrelevant user flows.

Bonus: by splitting up your files, you’re ensuring that files are kept to an optimum size; your team can focus on solving the relevant problems without the distractions that a bigger document could bring.

For more cross functional projects, splitting your work into more manageable chunks allows for the broader team—think localization experts or copywriters—to focus on individual releases, rather than trying to solve entire user flows in one swoop.

Organizing by product

I also recommend creating a project that houses your full end-to-end user flow of each product.

Why? Whether it’s from your VP of Product, developer, sales manager, or CEO, someone will always require an up to date flow to demo the product externally. Keeping a current full user flow for each section of your product (or the entire product if small enough) will enable the wider business to see at a glance the current state of the product.