On a side note: in my experience it's not *too* difficult to craft an effective, learnable and pleasant interface in an agile context when you know the domain well.
So, if you know the domain well, the most effective approach is often to sit next to a front-end developer and sketch the interface on paper. This approach avoids the normal conflicts between how your sketch looked and what the coded result looked like, and lets you focus on what's on the screen now, and what needs to get in there.
Obviously you have to test things and you'll hopefully have an agile infrastructure that will allow lots of split testing and analytics. Still, don't forget the observation/interview/probing part of your process.
If you *don't* know the domain well, then make sure you carve out enough time for research and explorative prototyping. Here, the goal is not to make a interface but to learn:
- who are the users, and in what contexts do they use our offering?
- what kinds of tools are they using (mobile, WIMP, gesture-based, etc)?
- what are the competing tools like?
- are there business rules that limit our design freedom, and can we circumvent them?
- should we follow inefficient conventions that users are familiar with or introduce foreign but more effective mechanisms?
… and so on.
As always, you must be prepared to kill your darlings. If the produced interface isn't delivering the desired results, break it apart and find a way fix it. Working software is great, business value is even better.