Bureaucrats, emailconfirmed
1,221
edits
→Iterative Design Process
| Line 36: | Line 36: | ||
The steps are: | The steps are: | ||
# '''Research:''' in which you gather informations about user goals, existing problems and already existing solutions. | |||
#'''Formulating you goals:''' Helps you to know what you actually want to archive with your design (and what not!). This can be seen as belonging to research but it is crucial to make the research useful, so it's got its own bullet-point! | |||
#'''Design:''' Is creating solutions for what you want to archive. You start with a broad design of that is fairly abstract and make your ideas more concrete over time. | |||
#'''Testing:''' After you designed you need to test if your ideas work as you expected. This is can be a hard thing to do because some things that seem to be great turn out to be unsuitable for your users. Otherwise you will get all sorts of interesting insights that will help you in improving your ideas. | |||
The model is called iterative because you will go through the all steps several time. Doing all steps one after the other one time is known as an " | The model is called iterative because you will go through the all steps several time. Doing all steps one after the other one time is known as an "iteration". Each time you do so, you improve your product and former abstract things will become more concrete. | ||
So what is it good for? Following the steps helps you to understand your users by doing research. So you don't design for non-existing needs or interfaces nobody can use. It helps as well to be more creative at the end: by dealing with your users, you will see your designs from a new perspective and so develop new ideas. | So what is it good for? Following the steps helps you to understand your users by doing research. So you don't design for non-existing needs or interfaces nobody can use. It helps as well to be more creative at the end: by dealing with your users, you will see your designs from a new perspective and so develop new ideas. | ||
The model can be applied for designing the general product as well as for designing a small feature. Imagine you design a new mobile phone. You can use the process that is suggested here to design the general product: You will research how people will use the phone, you will determine which features you need for meeting the users needs. Than you will design how all features work together in the phone and how it will look like. At the end you test it. | |||
During this process you will see that you need to answer smaller questions like how to implement sending messages: Is it better to have different facilities for SMS, MMS and e-mail, or shall they be combined in one view so that the user can ignore the differences between the different techniques? | |||
For getting to know how to deal with this you can again use the cycle model: | |||
1) Find out how the users think about messages and how they use them. | |||
Example:''You may find out that users think of their messages all in the same way when they get them but in technical terms when they write them'' | |||
2) Write down what you need to keep in mind when you design | |||
Example:''I want to design a unified view for incoming messages while still providing explicit control over self initiated or reply-messages'' | |||
3)Than you design... | |||
4)...and test. | |||
Example:''It turns out that your design was overall easy to use but that some users had trouble with selecting the message type while sending'' | |||
===Usability Goals=== | ===Usability Goals=== | ||