In the true spirit of Kanban applied to Scrum, I'd say you should -
- Start with what you do now (or what you did before applying Kanban/ Scrumban)
- Visualize your work/ workflow
- Manage the flow of work
- Improve gradually, as opportunities for improvement present themselves.
What makes sense for the team and for the stakeholders for whom the team is working should help you decide how the work should be managed on the Kanban board. For example, do stakeholders look at the board during the day and wonder "Is my work done?"? If so, perhaps it makes sense for the team member to move the ticket to Done as soon as they ARE done with it. During the standup the next morning, the team member can simply provide an update on it - or whatever else they need to do.
On the other hand, does the team-members or the stakeholders wait for the outcome of the standup to get their updates? If so, (continue with the practice and) update the card status during the standup.
Is getting an accurate measure of your cycle time important? If so, perhaps best to move the ticket to the Done column the moment it is done instead of letting it wait overnight in the Doing column. Depending on the nature of your work, tickets might move to a "Customer Acceptance" column or a staging/ demo column where the customer/ product owner can be given a demo.
Sometime back, I'd written a blog post on a related topic - "Does your Kanban Board reflect the process you actually have?" You might find it interesting.
Ultimately, it just really depends on your processes and what you are trying to measure and improve.