Here's a mockup of what I envision for the essay question page. These are the three main features, and my thought processes behind them:
1. Submission Criteria
You can't make a submission with absolutely nothing in it, but you can submit with only an attachment and no text. This way, if students prefer, they can write their essay in a word processor of their choice, and simply upload the file. They could even upload a scanned photo of a pen-and-paper essay. I don't expect that we have the technical ability to ensure that a submitted document meets the word count requirement — especially not if it's a scanned photo — but I think that's a small price to pay for the flexibility it would give students.
I have mixed feelings about the word counter. I hate the idea of constantly having your words counted while you're writing (which is why I made it tiny and put it in the corner), but unfortunately, I think it needs to be there: If we're asking students to write a certain number of words, we should be counting the words for them. It doesn't seem reasonable to ask students to Google "word counter" and copy and paste their essay every time they want to see how close they are to the requirement. We could conceivably build a system to reject or accept submissions based on word count, but that would have to be configured differently from one course to another, and I can see plenty of ways that a programmatic word count requirement might frustrate students or teachers. I'm definitely open to discussion about this, but it's a very important choice that we shouldn't make lightly.
2. Persistent Saving
When you enter text or attach a file, you can navigate back to the topic selection without losing anything. Sketch makes it difficult to design dynamic interfaces with lots of branching paths, so although I couldn't mock this up fully, my idea is that as soon as you enter any text, it's automatically saved for that topic. That way, you can safely navigate between the three without losing what you've written.
So a student could conceivably start writing in topic 1, get stuck, go back and select topic 2, write a little bit, decide he liked topic 1 better, and then go back to 1 and continue where he left off. I know this might not be a very common use case, but since losing work is like the worst thing ever, I think it's a good goal.
I tried my best to design this interface with a clear top-down user flow. Although I couldn't mock this up in Sketch, I imagine that when a topic selection is confirmed, the list of topics would slide off the top of the screen, getting "pushed out" by the description as it moves up. Then the Back button would make the topics slide back in, pushing everything down. If we end up settling on this, I can animate a quick mockup of it for the tech team to use as reference.
Of course, this is just a first draft, and I anticipate a good deal of iteration. Please let me know what you think.