Bureaucrats, emailconfirmed
1,221
edits
mockups
No edit summary |
(mockups) |
||
| Line 194: | Line 194: | ||
A stuctured aproach of this is defining "Requirements". This is defining the things your product needs to do at the end – in early phases the very essential ones. | A stuctured aproach of this is defining "Requirements". This is defining the things your product needs to do at the end – in early phases the very essential ones. | ||
==Sketches== | ==Sketches== | ||
for | Sketches are helpful in generating different ideas. They help you to structure your thoughts and keep good ideas for later refinement or combination with other ideas. Don't worry about your sketches as long as you can understand them yourself! They are just for dealing with your own ideas and especially used in early project phases directly after research and whenever you have and idea you want to remember. | ||
[[File:UI-Sketch-Flickr-Kyle_McDonald.jpg|thumb|300]] | [[File:UI-Sketch-Flickr-Kyle_McDonald.jpg|thumb|300]] | ||
==Mockups== | ==Mockups== | ||
Mockups are more advanced than sketches: often cleaner and more carefully crafted. Mockups are used for communicating in a team and to see how the elements of your interface play together in the screen layout. They are a graphic representation of what will be visible on the computers screen. So you can communicate your ideas about an application to your team-mates. It is usually decent to just draw the element's outlines - this type of mockup is known as "wireframe" as well. | |||
Like sketches mockups can be drawn on paper. Chequered sheets are useful here cause they provide a grid so your wireframe will look better and organized. | |||
There are a couple of tools for creating Mockups like Balsamique. Many people use Visio or OmniGraffle (two popular diagramming applications) as well. | |||
For Mockups you use in your team or for trying out screen layouts you don't want to waste time on shiny graphics. In contrast to this you may want to do a Mockup to present it to somebody who does not know about the design process and is just interested in how the finished project looks like. In this case you need to spend more time on graphics. Often you can use "Stencils", pre-created Interface-Element collections that are used with the diagramming applications above or an image-editor like Photoshop. | |||
[[File:Wireframe_Flickr-JoeCrawford.png|thumb|300]] | [[File:Wireframe_Flickr-JoeCrawford.png|thumb|300]] | ||
[[File:Mockup_Fennec.jpg|thumb|300]] | [[File:Mockup_Fennec.jpg|thumb|300]] | ||
==Prototypes== | ==Prototypes== | ||
| Line 267: | Line 273: | ||
* If the user really gets stuck you can gradually help. First with something with ''"where do you think could the [whatever] function be?"'' if this not helps in any way you can point to the solution so you can move further: '' "what do you think does this button do?" '' | * If the user really gets stuck you can gradually help. First with something with ''"where do you think could the [whatever] function be?"'' if this not helps in any way you can point to the solution so you can move further: '' "what do you think does this button do?" '' | ||
* If the user forgets about thinking aloud just ask ''"What do you think at the moment" '' | * If the user forgets about thinking aloud just ask ''"What do you think at the moment" '' | ||
==Formulate your findings== | ==Formulate your findings== | ||
After the | After the tesing you will have a bunch of protocols. You review them to see how you can improve your product. So have a look where people got stuck or where they thought about a feature, menu entry et. differently than you expected. | ||
If you are in an early phase of your project you probably need to decide about very basic things e.g. if your users understand a new way of approaching a common task. In this case you need to decide which of some solutions you will choose. If you hear or see anything intersting and/or inspiering, write it down, because it can help you in your further desgn process. | If you are in an early phase of your project you probably need to decide about very basic things e.g. if your users understand a new way of approaching a common task. In this case you need to decide which of some solutions you will choose. If you hear or see anything intersting and/or inspiering, write it down, because it can help you in your further desgn process. | ||
| Line 277: | Line 284: | ||
Having a list with what causes the user problems you know can refine your work. In early satges you will have seen which of some different ways will be dismissed and which will be further explored. | Having a list with what causes the user problems you know can refine your work. In early satges you will have seen which of some different ways will be dismissed and which will be further explored. | ||
In later phases of your project you will have a list with ranked problems that need to be resolved. Start with the ones you consider the most serious and solve the problems. In doing so you often can build on the think-aloud-protocol you wrote. It give insight in the way the users think about the actions they took and about the responses of the software. This will help you to find a decent solution that will work better. | In later phases of your project you will have a list with ranked problems that need to be resolved. Start with the ones you consider the most serious and solve the problems. In doing so you often can build on the think-aloud-protocol you wrote. It give insight in the way the users think about the actions they took and about the responses of the software. This will help you to find a decent solution that will work better. | ||
--> | --> | ||