- Why do a prototype?
- Create a tangible example and get everyone on the same page about
the project
- within the production team and between designer and client
- define the scope of the project, visual direction, navigation,
interface issues, technology, etc.
- Create a discussion about the project
- Test assumptions - technical, design, etc.
- Test relationship with client
- how long does it take for them to deliver assets?
- what is their decision making process?
- how well do they understand: the web, design, production,
etc.?
- are the good conceptualizers?
- do they micro-manage
- The prototype should be a sketch, not a fully developed application
- Not all links need to be "hooked-up"
- Graphics can be rough
- Whole sections of the site can be empty
- There are at least two types of prototypes:
- design prototype that tests the visual and layout design
- usually a few pages
- often has 2-3 different visual directions
- wireframe prototype which tests the information design
and content approach
- more pages so the info design can be fleshed out
- does not have visual design
- has active links to navigate around the site
- Define the goals of the prototype
- Test the graphic direction
- Test user interface questions/approaches
- Test the navigation and site layout
- Test the screen size and layout
- Test download times, plug-ins, or other technology issues
- Define the audience for the prototype
- Is it just for in-house people?
- Will it be shown to the client? If so, you may want to wait for
the second version of the prototype. Be very careful what
you show the client. They often don't understand what "sketch" means,
and don't have the imagination to extrapolate from a rough version
to the real version.
|
|