Knowing your use-case actors is a primary requirement before anything else is done. You should have atleast 2 or 3 just having come up with the idea to build software (by that I mean you will have an implicit actor just by deciding someone needs a bit of software), but UI wise you need much more granular detail.
The implicit actor for your software is usually as simple as "a freelance developer needs to be able keep track of the time they devote to projects so they can effectively bill their clients while minimising time wasted on their own admin".
When you want to create use-case actors for the UI side you want to really think about people and not functions. The Joomla admin system is, in my opinion, an example of something that was written as a set of functional requirements without anyone attempting any user empathy.
A starting point here might be:
"Tom is going into his second year as a freelance developer, having had a more successful first year than he had anticipated. Tom doesn't keep detailed time records and ends up partially guessing at the end based on emails but as he works with clients he likes he's been happily underestimating because his income is really good compared to his old job, and what is an hour or 2 anyway?
He has just taken on some work with a really well known agency who want work break-downs to 15 minute accuracy included with invoices, and while he doesn't really see what the point is, this is a big opportunity for him and wants it to go smoothly. He is also a little intimidated by his contacts at the agency and doesn't want to cause any conflict.
Tom is willing to run the time software for working with this agency, but at the moment doesn't really imagine the benefits to using it for his existing clients because it seems like more effort every day than it is just to do what he usually does at the end of the month."
From here you can extract lots of valuable information that will inform your UI cases. You know instantly for example that if you need to read a PDF to understand how to even start tracking project time this user will no doubt ditch the product because right now he is not really buying into the concept.
Case 1:
The user must be able to record time information on a per-project basis to specified precisions, broken down by task.
Now look at Case 1 and ask yourself how you would go about building the task tracking UI for your actor. Would you build something like a tray app that he can quickly select the project, add a row into with a name, and then run a start/stop timer on that task? Would you add a way to show visual reminders that a task is still running every x minutes? Why?
Or would you make it a system that you had to log into where you click into a project, then create a new task, then on the next page you can put in the time you spend on that task, save that and go back to the project panel, then swap projects and put in some new time against another task?
Both effectively do the same thing, but which one is Tom more likely to use for his current requirement, and more importantly for your business, which one might affect his opinion that it's more hassle than it's worth and would look to expand his use of your product to all his business (and this possibly be up-sold to)?
Writing clear and precise actors that have some empathy to them makes a huge difference to IA and UX as a complement to a good set of functional requirements.
(Note: I've cheated a little by basing my example to expand on as developers, as this makes it very easy to remove actors who don't understand technology that well).
And that is really a starting point, I've not touched on using real users to inform your decisions (though things like card sorting) and I would really suggest that if you use people to test wireframes or early designs you don't sit over their shoulder but screen-share with them instead, as people definitely tend to act differently when they are in a "test" environment with someone watching them.