Your final project is a usability study, presented during the final lab. Your presentation should run 5-8 minutes. You will be required to present the findings of your test in person.
A slide presentation is acceptable, as is a longform document. Either way though, your report needs to present what you did, why you did it, what the results are, and what your recommendations are based on those results. You must also include all the data that backs up your conclusions (although you don't necessarily need to talk through every single data point, as that would be pretty boring).
| Criteria | Presentation | Written |
|---|---|---|
| Speaking to the goals | 5 | 10 |
| Talking about the methods | 5 | 10 |
| Walking through the results | 10 | 5 |
| Strong conclusions | 5 | 10 |
| Reasonable recommendations | 10 | 5 |
| Documentation | N/A | 20 |
| Responding to questions | 10 | N/A |
| Total | 40% | 60% |
UAT and usability testing are both kinds of testing. As are regression testing, unit testing and integration testing. Tests have plans, requirements and scenarios.
| Usability | UAT |
| Meant to determine whether users can learn, understand and use the product efficiently to achieve theirgoals. | Meant to determine whether the client is satisfied that the product meets their requirements. |
| Can happen before or during development, before or after launch. | Happens after development, but before launch. |
| Tests whether users can achieve the result they want. | Tests whether the product produces the expected result. |
| Meant to generate continuous improvements. | Meant to achieve final sign-off. |
| Run by the software team. | Run by the client. |
The WCAG has multiple documents on how accessibility standards translate to mobile.
It's mostly along the lines of 'don't try to cram your whole desktop site onto mobile', and 'just make sure that you're doing what you do on desktop', but with a few extra cautions.
Page title should be unique and descriptive. If it's page 2 of 3, say so.
Headings should structure your document. Think of the way your information is structured - it's very rarely appropriate to have just an h1 and then p tags all the way down. Headings should provide meaning and context.
Alternative text should be your best effort to convey all of the relevant information in the image - no more, no less. This gets tricky when you get into things like graphs. Think of how WebAIM approached it in our reading this week.
Audio and video need transcriptions and/or captions. Keep an ear out for sounds that convey relevant information, and make sure they're included - not just the words.
Be very clear about what's expected of a user, and how errors should be resolved. A red asterisk appearing suddenly adjacent to an input isn't helpful to everyone.
Be on the lookout for images with embedded text, or worse - OCR-resistant PDFs.
Think about what this sounds like: ¯\_(ツ)_/¯.
For the same reason, write "16 to 17 years old" instead of "16-17 years old".
Via sitepoint