Disclaimer
As our field is still rather young, many of the terms we use are not stabilized enough for a discussion as generic as this one to converge.
Additionally, stabilized terms are regarded as outdated, like "usability", and are avoided in order to be modern.
I'm pretty sure that many of the answers here (I like all of them!) are referring to somehow different things using the same words, so I'm going to try to avoid all such words except "usability" which hasn't been mentioned until now.
In a software development process where does the user interface design fit?
Well, everywhere is an answer. Unless if by "user interface design" we mean the work of the graphics designer, then it fits ... where?
What is meant by "software development"?
Given the size of Songo's team, one can guess that they are working for a rather small web site or web application.
The size matters, and it matters a lot.
Most applications can be defined by a small set of wireframes (say, 10 or 20). The way the interaction contexts (ICs, screen or dialogs usually, but also physical button panels or whatever a user can use to communicate with the system) interact among them can be guessed, or be explicitly stated, in such wireframe set.
The wireframes serve as a complete software specification.
Instead, if the app was comprised of thousands of ICs then we would need another artifact to describe interaction.
In both instances the interaction between the ICs is the most significant part in the attempt to achieve usability, allowing the users to do whatever with efficacy, efficiency and satisfaction (as per the ISO/IEC's definition of usability).
How come? Yes, first we need the users to blaze through a path of interactions straight to their goal through our UI without losing the flow state of their minds.
So in order to answer what kind of a development process is the right one, some of these variables should be tethered.
Like, size of the applicaqtion, its complexity, the complexity of the domain, number of developers working on it, there must be more.
Anyway, everything has to be done
Things start with a requirement from a stakeholder (somebody with a vested interest in the app). This is not an instance of software requirements, this is at most a business requirement.
What comes next is some field research.
Interviews with users or with personas.
Many times small teams working on a permanent fashion for a stabilized application don't feel the urge to go out to try to figure out the reaction of their users to what they are going to implement, and they might be right, so the field research does not show in their radar but some how it has to be done, at least imagining one of their users using the new UI and figuring out (based on a long experience) how it will fit.
The knowledge about the users and their reaction to the new parts is used to imagine how would they use the new UIs. Ideally one would put the personas to operate it and try to find out if Joe Sixpack will be able to go trough it or not.
In this stage it's ideal to stay as abstract as possible. Functional analysts can do it, describing a user operating the UI without drawing it. Other people are more graphic and want to start drawing ASAP. Resisting this urge leads to better UIs, faster development and higher usability. In short, it's because once you go concrete you get trapped in concrete and the odds of trashing a design get too low. Being abstract lets you move freely between alternatives, like a butterfly in a garder full of flowers.
On the other hand, chances are that if you drew a high-fidelity mockup, chances are that you end up stuck with it, even if it was a crude firat idea, and that you start loving it. And if the manager saw it, then it's frozen.
Albeit being abstract, this part is a substantial component of the design of the UI and the way it works.
Over time (one hour or one month, it depends) the imagined and may be written descriptions of users using the UI (which I call "scenarios") get stabilized by intelligent consensus.
In a series of brainstorming sessions the team can write a list of what actions will the users need to perform to use the system in order to fulfill their goals.
A list of all the things the users will be able to do, like the app's menu, will be produced, and if the list consists of a single item or two then don't do it formally because it's implicit.
Now it's time to write down (still not draw, sorry) the description of how it works, in terms of the dialog of the users and the system.
For each of those goals a list of the steps needed to successfully go from start to end is written.
After doing that for most of the interaction tracks the team brainstorms most of the things that might fail, like in a login interaction that the password doesn't match.
Only the pitfalls that the system can manage are to be listed. For example an aerolite devastating the data center is out of scope.
Next you add interaction steps to handle the issues listed, and you have the core of a nice set of use cases.
These are informal, textual, rather structured, as-simple-as-possible documents.
By having brainstormed and decided how to handle all those conditions in advance you now have a rock-solid specification for the developers.
And, whether you like it or not, you have made substantial definitions about the behavior of your UI (thought you still don't know how will it look like).
But handle those UCs to the testing people and they will love you.
The developers will also love you, instead of calling you at 3AM to ask what to do if some condition happens.
All in all, the result will be better bur achieved with greater ease.
Before handling the UCs to the developers you should satisfy your graphical abstinence by doing two things, or three:
1- do a controls gallery
2- draw wireframes
3- define styles
The controls gallery thing is a definition about how to show each data piece, like an international address, or a phone number: how to label it, how to enter the value(s), what validations to do.
We always do it all
The funny thing with all these steps is that we always perform them, either consciously or not.
Either in the right order or not.
Many times we skip a step only to have to perform it later, at a much higher cost (in terms of effort) and achieving an inferior result.
All these steps lead to a UI that will work fine and that will look reasonable. Now you can give it the magic touch to make it excellent.
