mseeber

Actually there are two points here:

1. The creative process 2. Archiving/documenting

The amount of paper used in 1. can be very high, but essentially the key point is to let go of all your sketches when you are done distilling them. They are material for the trashbin. This may sound hard but it makes sense when you have a separate step for archiving, which means step 2.

Step 2. means, I distill all the lump of paper into what is required for the project at hand or worth keeping. This depends on the circumstances. Sometimes it means just putting a sheet of paper next to the other bureaucratic stuff, most of the time it means writing a project documentation or "specification" document, sometimes writing an outline for a paper or an abstract. This may be grunt work and the tools may suck, but that's OK since it is separated from the creative process and for the purpose of documentation, not creation.

If you have multiple projects at the same time and find yourself switching around often, make some organized space. There are these stackable plastic things where you can put stacks of paper in, not sure how they are called in english but I do use them to have 3 or 4 separated stacks that I can just pull out or put away when needed.

Maybe the key point is to be able and let go of old stuff. Taking half a hour once a week and browsing through the notes, evaluating and rejecting old/obsolete stuff helps too. Also, the "archiving step" acts as a filter. If you find yourself not having time/incentive to archive a certain idea or sketch, it is probably not worth it and can go to the trash.

Keep in mind, that Ideas (when they are just Ideas) are worthless. They need to be realized and one can only realize so much in a finite amount of time.

If I make a concept or design and in the process of thinking, I only use pencil and paper, lots of paper.

Everything else is just too distracting. The available software tools just don't cut it for me as a software developer. They are bound to a device and have complicated user interfaces, they are distracting or at least run on a device that has potential to distract me. Even if they are the perfect software, the fact that they run on a PC/Laptop/tablet/Phone is just enough to distract me. Except maybe a whiteboard, but these are quite expensive compared to pencil and paper and a maintenance nightmare. Their use case is justified if this is an interactive Meeting.

And the best thing about pencil and paper: It works offline, will not install updates and display no ads.

If I am done thinking/tinkering/planning/designing/modeling whatevering, I either redraw it cleanly and scan it or use one of the tools, others will mention in their comments to be able to archive it digitally and share it with others.

Some notes:

No, the time you will need to redraw it when changing your concept it not wasted time. No, the fact, that there is limited space and resolution when working with pencil and paper is a feature, not a bug.

Now for the process:

use cases DO NOT SKIP THIS, never ever. Some may call them user stories but hey, that's just marketing. use cases can be put in diagrams and they even have a standard: UML They are the highest level abstraction of what you want to build and the help you and others to keep on track. Maybe read about them here: https://en.wikipedia.org/wiki/Use_case TL;DR The important part is to know, who will do what with the system you want to build, to achieve what? When creating diagrams, create them in a way, so that they fit on maximum half a page each. Everything else can't be grasped reasonably and is "just to smart™". Divide and conquer if necessary. As a result, it should be clear on a high level abstraction what the purpose of that thing you want to build is. A tip: You may sit for an hour on a diagram that has four bubbles and a stick man, that may feel awkward but is just the right thing!

If you have use cases, you can go on with how you imagine to fulfill these. That's usually the exciting part and the part people jump to forst, not realizing that they don't even know what they want to do because they skipped creating usecases... Depending on the project use anything that seems appropriate: mockups, architecture diagrams or some kind of sitemap in case of a web site.

If you think you have a rough draft you can explain, talk to your developer/designer, the rest will come naturally if they are professional. If they are professional, the should be able to offer you good communication as part of their job.