Some general hints on doing well with the Design Challenges

by Mike Gleicher on November 1, 2019

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).

Previous post:

Next post: