Quite often you will see things like NOLOCK to improve performance however the massive disadvantage of using it is that queries could well see inconsistent (lets say incorrect) data. Look up isolation levels: dirty reads, non-repeatable reads etc etc
I've often seen deadlocks caused by catch 22 situations in poorly designed code, user X wants to read A and has B locked, user Z wants to read B and has A locked. I'd be more inclined to track the deadlock code down and optimise (look at the indexing too) and take from there rather than use NOLOCK or READ UNCOMMITED.
A bit of avoiding blocking from the text book:
Be aware that design patterns can lead to blocking. Techniques that can help avoid blocking
¦¦ Keeping the transaction scope as short as possible and in the same batch.
¦¦ Not allowing user interaction during transactions. Don’t display data to a user and wait
for the user to perform an action before completing your transaction; the user might
have just left for lunch!
¦¦ Practicing proper indexing to help limit locks acquired and reduce the chance of
¦¦ Elevating the transaction isolation level above the default only for a good reason.
¦¦ Examining the T-SQL code to see whether developers have added locking hints, index
hints, or join hints.
'Only he who wanders finds new paths'