Difference between revisions of "UX Overview"
(→Design) |
|||
| Line 44: | Line 44: | ||
*[http://toyotadriverseat.com/community/tssc-childrens-hospitals.htm TPS for the Children 2017] | *[http://toyotadriverseat.com/community/tssc-childrens-hospitals.htm TPS for the Children 2017] | ||
Notice these are both dealing with the exact same problem a decade apart. Let's try to do better. | Notice these are both dealing with the exact same problem a decade apart. Let's try to do better. | ||
| + | |||
| + | ==Writing Requirements== | ||
| + | From [http://www.ganssle.com/tem/tem343.html The Embedded Muse 343] | ||
| + | Writing good requirements is vital, and should include the following characteristics: | ||
| + | *Atomic: it describes just one thing. | ||
| + | *Complete: it has everything you need to implement the requirement. | ||
| + | *Concise: It should be simple and clear to anyone reading it, what is to be accomplished. | ||
| + | *Consistent: Use the same terminology throughout the specification. | ||
| + | *Correct: It should be appropriate to the system not just a cut&paste from somewhere else. | ||
| + | *Implementation free: Define what should be done, not how. | ||
| + | *Necessary: Why is it important? | ||
| + | *Traceable: How will it be tracked so development, QA and support will know where the feature came from. | ||
| + | *Unambiguous: Is it clear enough that there is only one way it can be interpreted (this is very hard). | ||
| + | *Verifiable: What does success look like? | ||
| + | *Viable: Will it actually improve the system? | ||
Revision as of 17:09, 7 February 2018
The User Experience (UX) is more than just what it looks like but how it works.
We handle large amounts of customer data and losing the data can have severe business consequences for them and for us.
Contents |
Examples
If you think UX isn't important:
This is the screen that set off the ballistic missile alert on Saturday see also [1]
When Interfaces Kill: What Really Happened to John Denver
How One Las Vegas ED Saved Hundreds of Lives After the Worst Mass Shooting in U.S. History
Estimation
How To Estimate The Impact of Business Decisions
UX Mapping Methods
There are four kinds of User Experience mapping techniques:
- Empathy mapping
- Customer journey mapping
- Experience mapping
- Service blueprinting
Journey Maps
The Journey Maps process helps us clarify who wants the feature, what they are trying to do, why they are trying to do it.
Design
First Impressions Matter: How Designers Can Support Humans’ Automatic Cognitive Processing
Chrome User Experience Report A useful resource for user experience in the real world.
Dos and don'ts on designing for accessibility 6 posters to make designing for accessibility easy.
Checklists
Much of what we do is complex, done rarely or both. Something that helps is a checklist Some people are taking a long time to learn how powerful they are.
Notice these are both dealing with the exact same problem a decade apart. Let's try to do better.
Writing Requirements
From The Embedded Muse 343 Writing good requirements is vital, and should include the following characteristics:
- Atomic: it describes just one thing.
- Complete: it has everything you need to implement the requirement.
- Concise: It should be simple and clear to anyone reading it, what is to be accomplished.
- Consistent: Use the same terminology throughout the specification.
- Correct: It should be appropriate to the system not just a cut&paste from somewhere else.
- Implementation free: Define what should be done, not how.
- Necessary: Why is it important?
- Traceable: How will it be tracked so development, QA and support will know where the feature came from.
- Unambiguous: Is it clear enough that there is only one way it can be interpreted (this is very hard).
- Verifiable: What does success look like?
- Viable: Will it actually improve the system?
