-- Calculates average stalls per read, per write, and per total input/output for each database file (Query 20) (IO Stalls by File)
SELECT DB_NAME(fs.database_id) AS [Database Name], CAST(fs.io_stall_read_ms/(1.0 + fs.num_of_reads) AS NUMERIC(10,1)) AS [avg_read_stall_ms],
CAST(fs.io_stall_write_ms/(1.0 + fs.num_of_writes) AS NUMERIC(10,1)) AS [avg_write_stall_ms],
CAST((fs.io_stall_read_ms + fs.io_stall_write_ms)/(1.0 + fs.num_of_reads + fs.num_of_writes) AS NUMERIC(10,1)) AS [avg_io_stall_ms],
CONVERT(DECIMAL(18,2), mf.size/128.0) AS [File Size (MB)], mf.physical_name, mf.type_desc, fs.io_stall_read_ms, fs.num_of_reads,
fs.io_stall_write_ms, fs.num_of_writes, fs.io_stall_read_ms + fs.io_stall_write_ms AS [io_stalls], fs.num_of_reads + fs.num_of_writes AS [total_io]
FROM sys.dm_io_virtual_file_stats(null,null) AS fs
INNER JOIN sys.master_files AS mf WITH (NOLOCK)
ON fs.database_id = mf.database_id
AND fs.[file_id] = mf.[file_id]
ORDER BY avg_io_stall_ms DESC OPTION (RECOMPILE);

For now, just worry about those first few columns with average read stall, write stall, io stall.
Pay attention to any of those that are greater than 30 - 50 range. If it's a lot, just worry about those over 50.
Then the right it will tell you which database and which file/file type (log file or data file). So that will give you an idea of what databases and what type of activity have the most latency. From there it really depends what all you find and you probably won't get what you need through a forum post so you will need to do some research too.
That second link earlier to Monitor Read/Write Latency article has some steps of things to look for.
If I saw a user database being the worst and mostly in just one database, I'd start looking at the queries, the indexes, the statistics for that database. You can check the query stats for that database, look for the queries with the most executions, reads and writes. A query can be high on some things like reads or writes but if it's not called to often and has low execution count, it might not be as important as one that has a large execution count. You may have queries run once a day during slow hours and those typically won't hurt as much as one that is called 100 times an hour every day.
If the numbers are bad for tempdb, you want to check if you have the files configured correctly and if it's used a lot. You can tell which files are used more by looking to the right of the results of that query and look at the number of reads and number of writes (num_reads and num_writes).
As I said, that Monitor Read/Write Latency article has steps of other things to look for. When he mention hot spots, that would be looking at what disks or databases are involved for the most latency, the most reads and writes. You sometimes you need to adjust things with what files are where or the I/O path could be an issue somewhere but usually it's due to poor query performance. You usually want to make sure to check memory when you are seeing disk latency as memory pressure can mean you go to disk more often.
You can search for some scripts you can use to look at the query performance. The guy who wrote the code I pasted above for you has a set of diagnostic queries that are great to have. The link to his site for the scripts is in the comments of the code I pasted above. There are also scripts available to search the query plans which are good for looking for scans.
So there is a lot involved and a lot to learn about. As I said, you won't be able to get everything you need from a forum post. Hopefully I gave you enough information to get started. 

Sue