I'm a ASP.NET developer so don't know much about WinForms coupling, but know a little from N-Tier web apps, assuming a 3 tier application architecture of UI, Domain, Data Access Layer (DAL).

As @MKO states if you can replace an assembly with another (e.g. a new UI project that uses your Domain project, a new DAL that saves to a spreadsheet rather than a database) then there is loose coupling. If your Domain and DAL depend on projects further down the chain, then the coupling could be looser.

One aspect of something being loosely coupled is whether you can replace an object with another that implements the same interface.
Loose coupling, interfaces and Dependency Injectors (DI) and Inversion of Control (IoC) are useful for the isolation aspect of designing for testability.

E.g. An object in the UI project calls a Repository object in the Domain project.
You can create a fake object that implements the same interface as the repository that the code under test uses, then write special behaviour for tests (stubs for preventing production code that saves/deletes/gets being called and mocks that act as stubs and keep track of the state of the fake object for testing purposes).
The means the only production code being called is now only in your UI object, your test will be against that method only and any test failures will isolate the defect to that method.

Also, in the Analyse menu in VS (depending on the version you have) there are tools to Calculate Code Metrics for your project, one of which is Class Coupling, there will be more information on this in the MSDN documentation.

Don't get TOO bogged down in the minutae of loose coupling though, if there's NO chance that things are to get reused (e.g. a domain project with more than one UI) and the life of the product is small, then loose coupling becomes less of priority (it will still be taken into account), but it will still be the responsibilty of architects/tech leads who will be reviewing your code.

I'm a ASP.NET developer so don't know much about WinForms coupling, but know a little from N-Tier web apps, assuming a 3 tier application architecture of UI, Domain, Data Access Layer (DAL).

Loose coupling is about abstractions.

As @MKO states if you can replace an assembly with another (e.g. a new UI project that uses your Domain project, a new DAL that saves to a spreadsheet rather than a database) then there is loose coupling. If your Domain and DAL depend on projects further down the chain, then the coupling could be looser.

One aspect of something being loosely coupled is whether you can replace an object with another that implements the same interface. It doesn't depend on the actual object, but the abstract description of what it does (its interface).
Loose coupling, interfaces and Dependency Injectors (DI) and Inversion of Control (IoC) are useful for the isolation aspect of designing for testability.

E.g. An object in the UI project calls a Repository object in the Domain project.
You can create a fake object that implements the same interface as the repository that the code under test uses, then write special behaviour for tests (stubs for preventing production code that saves/deletes/gets being called and mocks that act as stubs and keep track of the state of the fake object for testing purposes).
The means the only production code being called is now only in your UI object, your test will be against that method only and any test failures will isolate the defect to that method.

Also, in the Analyse menu in VS (depending on the version you have) there are tools to Calculate Code Metrics for your project, one of which is Class Coupling, there will be more information on this in the MSDN documentation.

Don't get TOO bogged down in the minutae of loose coupling though, if there's NO chance that things are to get reused (e.g. a domain project with more than one UI) and the life of the product is small, then loose coupling becomes less of priority (it will still be taken into account), but it will still be the responsibilty of architects/tech leads who will be reviewing your code.