These are in no particular order…
- It is good to discuss the pros and cons of your designs.
- Don’t expect to have a perfect design (there probably isn’t one) – but do articulate the rationale, and the pros and cons.
- No design is good for all tasks. Describe what it is good for (and why), and what it isn’t good for (and why)
- Use examples that illustrate things that you can see with your design.
- Explain the decisions you made – give rationale.
- Some designs may cover many tasks – some designs may cover few tasks.
- You may want to have many designs that cover a range of tasks. These might be integrated into a single program and coordinated. Or you might keep them separate.
- Your designs might require some “non-visualization” components – such as statistical analyses or standard searches. But this shouldn’t be the main thing. There should be some visualization component.
- Designs shouldn’t be needlessly complex – simple tasks can have simple designs.
- Tasks that are too easy will not get good grades. “What are the products with the most reviews” (answered by a simple list – a bar chart isn’t that much better), is not that hard. But it could lead to other things…
- Putting multiple simple tasks together (a simple question leads to a deeper exploration) can be interesting.
- Use good encodings and detail choices. Fancy implementations don’t make up for bad design choices.
- Describe interactions and use cases.
- Explain tasks and “anti-tasks” (tasks it would not be good at)
- Talk about scalability – of the design mainly, but also the implementation.
- If there is an obvious “baseline” design, you might explain why you chose your design instead of it.
- There are different ways to do well. If you have simpler designs, you can make up for it with more thoughtful discussion and having a wider range of designs (to cover a range of tasks).