I’ll expand here on what I was talking about in class. Namely, that what you need to remember throughout much of the design process: only do things that you *need* to do in order to communicate what you’re *going* to do.
What do I mean by that? Well, take the examples we’ve heard about the problem meetings where the presenters are trying to get feedback on one part, but are hearing constantly about an image, or a color, or something entirely unrelated. Why not focus the wireframe down specifically to literally the navigation in that instance?
So sure, the overall presentation might be to go over the entire wireframe of one page, but you can still break it up into sections. Highlight and label as needed. Zoom in. Focus. And remember that you’re leading, you can take the flow into your own hands.
So that’s more of ‘presentation advice’, but it’s something that you need to take into account when creating the wireframe. Always ask yourself ‘what am I trying to show by making this?’ Is it just that you can put boxes together, or is there an overlying message you’re trying to get across? Direct your work. Do you need low or high fidelity? Do you need an interaction or an animation or will simple stills work? This is entirely dependent on what *you* need. Never feel constrained into one, this will only hamper your ability to communicate.