Scrum is an iterative and incremental model based on agile values. That means you don't have a separate design phase. The idea is that you should constantly be dealing with design, just as you constantly are dealing with analysis, implementation, testing and integration throughout the project.
You need a bit of planning for this to work. Enter the sprint planning meeting, where the team estimates tasks for the sprint ahead. Most people don't realize this is not only an estimation meeting, but a design effort as well. For example, a task might be "Add code for new car model". You cannot estimate this yet, you need to know a bit more. So the team discusses the design and comes up with a broad solution ("subclass Car?") and adds that as a reminder to the task. You rarely need more formality than that. You now have an idea how to solve the problem. You don't have all details yet and that is fine, you know enough of the design to be able to make a comfortable estimate. Without having to create any diagrams at all (at this point).
For actual physical documentation, I recommend creating a systems overview diagram up on a wall for all to see. The overview only needs to have the most important classes and modules included and should rarely have to be updated. Also, creating a few state diagrams for the most important classes in the system is very helpful. Sprinkle with a few select sequence diagrams of typical use cases to make it easy for people to quickly see how things are connected. I assume you can generate class hierarchy diagrams from your code, so that problem is easily solved.
Note that all diagrams are created after the actual implementation. This is keeping with the "working software over comprehensive documentation" and just-in-time design.
And yes, readable code is definitely documentation.