I'm in software development for 15 years and I can tell you one thing for sure: misunderstandings are costly in software development. I'll show you how to properly apply screen prototypes and avoid this trap, while having fun in the process.
There are many tools commonly used for software prototypes and GUI prototyping. Now with Mockup Screens I'm satisfied with both, and I can focus on the real problem: to quickly engineer clear requirements for a software application.
Note that Mockup Screens is very capable of solving whole category of tasks quickly and efficiently.
1. Recognize Scenarios to Build a Wireframe for Requirements
Think what the users want from your application. Choose and create scenarios that people will use most often. Don't aim for perfection, right now prototypes are more important things to do. Try to work together with your customer. If this works out fine, continue teamed up this way: it's very effective. 2. Sketch Screen Prototypes for Important Scenarios
Decide which the most important scenario is and sketch screens for it. Imagine these are paper sketches and focus on speed, not on design or perfection. Populate screens with data that will provoke reaction. Remember what Wikipedia says on software prototyping: "[Prototyping] is not a tool to prove that we are right. Copy screens from existing templates or finished scenarios wherever you can. Choose two or three scenarios you want to discuss with the customer.
Before the workshop, skim through scenarios yourself, they are your prototype. If you want to make changes interactively and experiment together with the customer, present the prototypes with the “slideshow” option on your notebook (just remember to save the file under different name first). Otherwise just export scenarios and discuss them in your web browser or over a printed hard-copy
Of course, the same process applies to web pages and web application prototypes. Liberate use of predefined dummy pictures really speeds things up here.
3. Discuss the Requirements Implied by Screen Prototypes
On the workshop with customer; present your ideas for each screen: what particular elements mean and why they are there, what happens when user clicks a button, etc. For example if the table has a “Date” column, which date is it: the creation date, date of the last update or something entirely different. These are real software requirements, nail them.
Be prepared to listen, and get the customer do the talking. Your goal is to get feedback, just moderate a bit to stay on the topic and always get back to screen prototypes.
4. Improve Screen Prototypes with New Requirements
when you get the feedback, improve your screen prototypes and requirements accordingly, and always send them to customer for confirmation. If you got through to the customer, her mind could still be processing those screen prototypes and could come up with quite a few surprises.
5. Specify Requirements to Complement the GUI Prototype
when a scenario is finished, invest five more minutes and "empty your head", go through screen prototypes and document screens one by one. Don't analyze or structure anything, let the associations flow and take quick notes. One particular way is to export the scenario, print it (web page will open automatically) and write notes on the paper copy. Then copy screens to Microsoft Word and structure these notes while typing.
When you are finished, you will have a large part of both software requirements and user interface specifications. For smaller applications that might even be all you'll ever need.
In short, experiment, find what works for you and have fun!
3. Discuss the Requirements Implied by Screen Prototypes
On the workshop with customer; present your ideas for each screen: what particular elements mean and why they are there, what happens when user clicks a button, etc. For example if the table has a “Date” column, which date is it: the creation date, date of the last update or something entirely different. These are real software requirements, nail them.
Be prepared to listen, and get the customer do the talking. Your goal is to get feedback, just moderate a bit to stay on the topic and always get back to screen prototypes.
4. Improve Screen Prototypes with New Requirements
when you get the feedback, improve your screen prototypes and requirements accordingly, and always send them to customer for confirmation. If you got through to the customer, her mind could still be processing those screen prototypes and could come up with quite a few surprises.
5. Specify Requirements to Complement the GUI Prototype
when a scenario is finished, invest five more minutes and "empty your head", go through screen prototypes and document screens one by one. Don't analyze or structure anything, let the associations flow and take quick notes. One particular way is to export the scenario, print it (web page will open automatically) and write notes on the paper copy. Then copy screens to Microsoft Word and structure these notes while typing.
When you are finished, you will have a large part of both software requirements and user interface specifications. For smaller applications that might even be all you'll ever need.
In short, experiment, find what works for you and have fun!
No comments:
Post a Comment