Taking an agile approach to this I would not do as you suggest and build the mock interface prior to starting work. I would evolve the interface as you progress.
First of all focus on the most valuable stories (and it is VITAL that these meet INVEST
The tricky bit here is how you build your stories, and getting the definition right with both the team/s and the product owner is essential. This will make or break the project. There are two options I would consider for this, lets take for example the story 'As a user I want to log-in'. (I know this is a terribly formed user story, but it gets my point across simply). There are two options for defining this, and either approach could be better depending on how your team/teams are working on the project:
- The 'pure' Scrum option - how I would do it if you are a single Scrum team.
Specify technical requirements as acceptance criteria of the story. Eg. The login must be secure using XXX encryption, password strength etc.
As you build this story you design the aspects touched on by the story - eg. A users and passwords in the DB, and all the required fields. If another story in the future means this will need refactoring, this is included in the size of that story. Also, unit tests are essential to ensure that refactoring doesn't break existing functionality. This is probably the best approach if there is only 1 scrum team on the product, as it is best to get everything production quality as you go.
- The Commercial Scrum option - how I would have done this in a company with multiple Scrum teams, that are not purely cross functional.
Ignore the tecnhical requirements, and separate them into a separate story. Eg. a 'login' button is created that always passes, and lets you into the system to continue. This means the 'front end' team (or sprint) can continue working and delivering further value, and a separate story holds the technical requirements and DB design of logging in. It is vital that everyone knows the functionality doesn't exist yet.
The main advantages to the second option are:
- One team can build the UI while another team builds the DB. They can then carry on with other stories.
- Stakeholders can see progress much earlier and get a feel for what you are building, which can influence design from an early stage.
The big risk is people believing progress is further than anticipated, because you have something that looks 'nearly done' but doesn't actually deliver value. This is why the first option is more 'pure' Scrum.