12,297
edits
m
→Iterative Design Process
| Line 57: | Line 57: | ||
So what is all that 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 all that 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. | ||
==== A small Example ==== | |||
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. | 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. | ||
| Line 65: | Line 64: | ||
For getting to know how to deal with this you can again use the cycle model: | For getting to know how to deal with this you can again use the cycle model: | ||
# Find out how the users think about messages and how they use them.<br />''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'' | |||
''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'' | # Write down what you need to keep in mind when you design<br />''I want to design a unified view for incoming messages while still providing explicit control over self initiated or reply-messages'' | ||
#Than you design... | |||
#...and test.<br />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'' | |||
''I want to design a unified view for incoming messages while still providing explicit control over self initiated or reply-messages'' | |||
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'' | |||
What you do now is trying out different ways to make the type-selection easier, so you just repeat the "mini-cycle" of testing and design. | What you do now is trying out different ways to make the type-selection easier, so you just repeat the "mini-cycle" of testing and design. | ||