I have been using an extra step what I'd to call "Interactive wire frames". The entire process goes something like this:
1) Write down in a few paragraphs the objective of your project. what it is you want to do and what this project needs to achieve. If you work for a client, discuss this text with your client until you're both happy about it. It's this text that's going to define the scope of your project.
2) Set up a requirements and scope document. This document will describes in greater detail what you discussed in the document at step 1 and it's this document that will become your official Scope of Work document. If you have a client, discuss this document with your client and get sign off.
3) Based on the requirements and scope I create wire frames using Balsamiq. If you have a client then discuss the wire frames with your client and get sign of before moving on.
4) Based on the wire frames I now create "Interactive wire frames" using Bootstrap. I basically recreate the Balsamiq wire frames in Bootstrap. This allows you and your client to click through it. The difference between a paper wire frame and an interactive one is that the interactive wire frame will bring out issues early on. Again, if you have a client get sign off.
5) Build. Uh? That's right. At this point I build as much of the core functionality as possible and I use the interactive wire frames for the front end of it. This allows me to fine tune the functionality and to test if all the objectives are met. Discuss with your client whenever you have something significant to demonstrate.
6) Design. Often design can be started during step 5. Very important here, discuss the designs with your client (if you have one) and get sign off.
7) Implement designs and cross browser test. Again, with a client, get sign off.
There is always a debate about how best to move from idea to finished product. This is just my method. Would love to hear yours.
Ryan Singer (37signals) actually jumps straight from sketch to code, but then takes screenshots and brings them into Photoshop when he needs to work on more details.
From the looks of it I stay on paper a bit longer than you do. I find I can iterate on paper, and do paper prototyping, faster than I can mess with Photoshop or Balsamiq.
From there I usually jump straight to code (I come from a dev background and I find I'm more productive there than I am with tools like Axure).
I wouldn't bother buying (overpriced) design sketch books. Just find a couple free design templates online that work with your project and print them at Kinko's. I also get them 3-hole punched so they can be easily moved around.
Stickies are also a great way of making notes you can move around on each page and do take advantage of setting meaning to color.
Filling in with matching highlighters can also help you mark actions and flow. Plus who doesn't love a good coloring book moment. :-)
My process helps me clearly understand what the user is trying to do and plays to my strengths, which aren't designing. For each user flow I do the following.
1) State the use case (who is doing what and why)
2) Write each stage of the flow in terms of user request, decision and information they need
3) Very rough sketches
This will throw up a lot of questions, mainly about edge cases, so I write those down separately. When all the main flows are done I start coding.
I like your idea of keeping a "features" list and "questions" list separate. Otherwise, it gets confusing when the two get jumbled together.
One tool that most hardcore engineers chuckle at - but that I love for the higher fidelity mockups - is using Keynote/Powerpoint. It is extremely fast to make things like buttons, move text around, etc.
Most importantly, these tools make super easy to make a duplicate of any view and completely overhaul the layout...giving the ability to show users A/B options for the same slide.
Finally, it's easy to export the entire "app" mockup as one PDF file (made of many slides) and share all the mockups with users. I like it as a last step before diving into actual CSS/HTML. I like this more than Balsmiq because it lets me get closer to pixel perfect before I start coding - emphasis on actual look & feel, vs functionality (which balsamiq is probably faster at depicting).
I've known about this method for a long while (back as early as 2004), but I've always found it easier to actually mock it up in HTML/CSS and then make changes on the fly. It might be my personal skill level that makes the difference, but it worked out better for me.
(My favorite design sessions remain the ones where I sat in a room, projecting my laptop onto a screen, and speed-editing CSS and PHP while my boss made suggestions at the front of the room. And then I'd go, "So, like this?" and refresh.)
Not really recommending it so much as saying it's a thing that can be done.
After sketching, I usually design a wireframe with gray boxes, visually flat (like Nathan's wireframes). I've been thinking of replacing this method with HTML wireframes using a simple CSS framework. That would allow me to link between wireframes, and would make it easier to deal with changes.
I've been postponing this for fear that it might add too much complexity and make things harder, but on second thought, it's worse that I have to basically remake my own framework every time I make a wireframe in Photoshop. Creating rectangles in Photoshop is so easy it's mind numbing, but as you work on a wireframe with multiple versions, it gets annoying.
I'm particularly interested in how Bootstrap 3 will look like when it's released, because the preview looks more or less like what I need: flat and responsive. It's not that I want to create visually flat websites, I just want a framework to create visually flat wireframes.
1) Write down in a few paragraphs the objective of your project. what it is you want to do and what this project needs to achieve. If you work for a client, discuss this text with your client until you're both happy about it. It's this text that's going to define the scope of your project.
2) Set up a requirements and scope document. This document will describes in greater detail what you discussed in the document at step 1 and it's this document that will become your official Scope of Work document. If you have a client, discuss this document with your client and get sign off.
3) Based on the requirements and scope I create wire frames using Balsamiq. If you have a client then discuss the wire frames with your client and get sign of before moving on.
4) Based on the wire frames I now create "Interactive wire frames" using Bootstrap. I basically recreate the Balsamiq wire frames in Bootstrap. This allows you and your client to click through it. The difference between a paper wire frame and an interactive one is that the interactive wire frame will bring out issues early on. Again, if you have a client get sign off.
5) Build. Uh? That's right. At this point I build as much of the core functionality as possible and I use the interactive wire frames for the front end of it. This allows me to fine tune the functionality and to test if all the objectives are met. Discuss with your client whenever you have something significant to demonstrate.
6) Design. Often design can be started during step 5. Very important here, discuss the designs with your client (if you have one) and get sign off.
7) Implement designs and cross browser test. Again, with a client, get sign off.