The Prototype

Once you know what the user interface (GUI, CLI, or API) is going to look like, go ahead and try to build a “shell” of the user interface as quickly as possible. This is called a prototype. You don’t have to implement the core functionality – you just code the interface to see 1) if it’s possible and 2) how it appears to the user. Ideally, you should end up throwing this prototype away. The prototype should be shown to the user to see if it’s what the user had in mind. That’s why you really shouldn’t put too much effort into it because chances are the user is going to say, “No, I wanted it to look like this” or “I like this screen, but that one sucks”, etc. You want to ensure that the user sees what they want to see – and this applies to GUI, CLI, and API. It’s much easier to change a prototype than it is to do all the work on the internals first and then have to change things. The prototype helps you design things in such a way that the interface is independent of the underlying implementation of the actual problem. The interface is not the solution to the problem. But the interface is the user’s window to that functionality. That functionality, or solution to the problem, begins with the next step.