Good question.
Yes, just do it and get feedback --don’t get bogged down.
That said, I would suggest models. Look at 2-3 Processing libraries that you like and appreciate and browse their documentation and source code, looking at how they do everything – what do you like and not like about what they did? You will discover than many libraries are quite different from each other – there isn’t one standard approach.
Also, keep in mind that good bundled examples are going to matter even more than good javadoc – that is what most of your users will look at first, and they will assume that the example set has reasonable coverage of what your library can do. If they don’t find ready examples to run and then adapt, they may move on.
For naming, keep in mind that your library co-exists with the Processing API – so you often want to either align it or disambiguate it. For example, if you were writing a kaleidoscope library that creates a Kaleidoscope ks object, you might decide that ks.tint() will tint it (just like the Processing canvas), but that ks.random() looks like returning a random number – and instead you want to call that ks.randomLayout() to distinguish it. Often writing non-trivial example sketches helps work these namespace issues out, because you will better notice things that are confusing or unclear and might be renamed when you class methods are being mixed in with normal sketch functions.