If I <i>make</i> a concept or design and in the process of thinking, I only use pencil and paper, lots of paper.<p>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.<p>And the best thing about pencil and paper: It works offline, will not install updates and display no ads.<p>If I am <i>done</i> 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.<p>Some notes:<p>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.<p>Now for the process:<p>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: <a href="https://en.wikipedia.org/wiki/Use_case" rel="nofollow">https://en.wikipedia.org/wiki/Use_case</a>
TL;DR
The important part is to know, <i>who</i> will do <i>what</i> with the <i>system</i> you want to build, to <i>achieve what</i>?
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!<p>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.<p>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.