Almost all WordPress plugins have two distinct UIs to present to users and their asynchronous relation makes it easy to think of them as separate pieces of software communicating via an API; this perspective helps me in isolating components of the plugins one from another and attribute roles and responsibilities easier.
I’ve made some iterations over the build of the sign-up plugin and put together two flow diagrams, front-end and back-end, of users' interactions with the plugin. 
The word “user” I use to indicate someone visiting the site while the word “administrator” I use to indicate someone visiting the site back-end with some kind of administrator rights. Among the plugin requirements is the possibility to show the plugin and subscribers administration area to enabled users that are not required to be site administrators: these users I will refer to as “subscription administrators”.
Since the site is, by definition, open to the public I made sure that the eventual removal on unwanted subscribers from the database is not going to be a problem and hence am not going to manage that in the plugin. 
In both the drawings I use the words “screen” and “view”. A “screen” is the WordPress default one, an administration or front-end page and its layout, a “view” is either a plugin input or output that could be inside a page content, in its own page or presented via AJAX. The diagrams hide some business logic of the plugin behind expressions like “validate input” and in this phase I do care more about laying out breaking points, conditions and stepping points and not planning the UI or deciding which components go where or which specific aspect of available technology to use.
The diagrams serve three main functions to me:
- they help me laying out the components of the plugin and build the flow of it thus forcing me to structure it
- they line out the APIs the plugin will need and use (in this case I think none but WordPress' standard ones) and evaluate its dependence upon other plugins, libraries and pre-conditions.
- they outline ends of the plugin, both entry and exit points, that I will test using Selenium IDE and PHPUnit
In the book Growing Object-Oriented Software guided by tests the authors encourage developers to set up a working deployment environment from day one creating the premises for frequent delivery of working iterations. I’ve never taken this approach before concentrating in a more bottom-up approach and am curious to try it.
Next step is to create a first end-to-end test, using Selenium IDE, make it fail (“red light” phase of TDD) and then code the barest possible code to make it pass (“green light” phase of TDD).