If I was asked in an interview to provide a 'written spec' for a form, how would I reply?

Question

I initially left an interview assuming I was going to have to sketch mockups for a registration form that was requested as a test, but when probing for more information I was told that a 'written spec' was all that was requested.

Therefore I assume I would be making the spec in a text based medium (no diagrams, graphics, etc). I would indicate what any text on the entry/confirmation pages would say, form field names/lengths/types and how validation would work, etc.

So, I have my own ideas on how I'd go about doing this - however I just want to clarify what is being requested here. I am trying to validate my idea on how I'd accomplish this against any industry standards (if any).

Is there is a standard name for what is being requested here? A link to an example document somewhere on the web would be even better.

Answer 1

Personally I think there would be no issue with you contacting the interviewer directly and clarifying exactly what is required. We can speculate on here all you like but there were two people involved in the interview and only one of them can tell you what is required.

Your diligence in ensuring that both parties (you and them) are speaking the same language and have a common understanding should add kudos to your credibility, not detract from it. However, you are getting this advice from here - and not taking your own initiative in contacting them, so any subsequent kudos would be kind of mis-appropriated.

Now I have a dilemma - do I give advice - or not? Well, yes - asking on here is still better than not asking anyone and blindly going forward amid a bunch of open-ended assumptions.

I would add that if they are unhappy to be questioned for the purposes of clarifying information, then they aren't much of an employer anyway!

There - now I've gone and given an answer that is totally not related to UX at all.

Answer 2

This is more of a program management question than UX but since I end up doing both on a daily basis here is what I would do:

• List out the purpose of the form
• List out the user flow or wizard if any (assuming you have a multi-step registration process
• List out all the fields in each step along with the length allowed for those fields, the validation and the associated error cases
• Detail out the confirmation and failure messages that might arise with registration
• Detail out the user flow which happens outside the form (such as the verification email sent and where the user is redirected to once he clicks on the verification email)
• If required, highlight the technology being used and the system infrastructure which would support the registration process (You could throw in the data model in here if you want)