One of the first things I would do is try to isolate where the report of 'slow' database is coming from.
- Is it slow in the application, if so - in a particular module of the application?
- Can it be reproduced by another user?
- Is it on a web farm - if so, is it slow across all web servers?
- Is it from only one location - or multiple locations? Might indicate a problem at a site or building.
- If not in the application - is it a direct connection to SSMS? If so, can the user provide the queries they are running where they see this slowness?
- Is it something else? An interface engine, integration services, reporting services?
Once you have an idea of where the issue is occurring - then you can start looking at the system to see if there is any correlation. For example, if the users report a 'slow' database and the application uses a web farm - but it is only slow from one web server - it would seem to indicate a problem with that web server. If it is from all web servers it might indicate a problem with SQL Server - so check from SSMS and see if you can reproduce the slowness. If nothing shows up in SQL Server - then it might be the load balancer or the network.
Maybe the slowness only occurs at a certain time of day - if so, monitor for other processes running at that time that could cause performance issues.
What I have found is that when performance related issues are reported to the application support team - they often assume it is the database first thing without looking at other possibilities. Unless this is an ongoing issue that has already been isolated as database performance - it often isn't the database causing the problem.