Leave the data model alone, and stop thinking about the UI. Do some real design.
Consider a simple example - registering a user account.
Assume the product vision statement calls for a thick client desktop application that synchronises data to other desktop clients via a server. To use the sync service you need an account. On the client, you put up a form that asks the user for a user name and password. Easy. What happens when the call to the server is made to register that account?
Does the UI just lock up until the call returns? Does the UI remain responsive? Does a responsive UI allow the user to cancel the request? Is the technology chosen to build this thing even capable of asynchronous service calls?
When the data is sent over the wire, how is it protected? When it hits the server, how and where is the password stored? Is the request logged? Will server logs be of use to anyone? What error conditions are checked on the server, what corresponding messages are sent back to the client, and how are these communicated to the client? Is there a retry button the user can hit when it bombs? Should the client use a database/temporal cache/config file to store the user name and password in case the server is unreachable?
That was a very simple use case. [Edit] My point is that those questions demonstrate that the data model as well as the UI might radically change based on other design decisions you should be making first. To answer those questions you need to do some design work.
Design work means analysis to get business, user, system, and operational requirements.
Then you need to think about availability, backup and recovery, capacity, communications, deployment, end user support, data migration, monitoring, performance, pilot program, security, system support.
It's called an architecture.
[Second edit] The agile police is probably going to jump on me for what I wrote. Let me pre-empt that by adding that even little web apps have what may appear to be very simple use cases that can bite you in the ass.
