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.
I go to MIT and have taken graduate courses in OS design, database design, and distributed systems. I am more than aware of the issues of byzantine errors, fault tolerance, and replication, etc; however, my post is not about that. My post is about how to approach "hacking" a minimal viable product together and guidelines for making that process efficient. The issues that you present are not relevant to this post and can be abstracted away for this context.
If I had to guess why your response was downvoted (wasn't me) I'd say that it's because you didn't make this clear in your post. That said though:
In my opinion(!!) hacking out a minimum viable product (MVP) should still go through an up-front design phase. Before any UI work or data modelling is done.
Anwering those questions will help determine what that MVP will look like, and whether it will annoy users or have them wanting more. Apart from the obvious technical benefits it provides direction, motivation, and (one scenario) if you're looking for funding will help you articulate not just the product vision, but the technical roadmap, risks and, above all, provide a reasonably-informed estimate that will drive your financial models.
Comments
There's a third scenario.
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.
I go to MIT and have taken graduate courses in OS design, database design, and distributed systems. I am more than aware of the issues of byzantine errors, fault tolerance, and replication, etc; however, my post is not about that. My post is about how to approach "hacking" a minimal viable product together and guidelines for making that process efficient. The issues that you present are not relevant to this post and can be abstracted away for this context.
If I had to guess why your response was downvoted (wasn't me) I'd say that it's because you didn't make this clear in your post. That said though:
In my opinion(!!) hacking out a minimum viable product (MVP) should still go through an up-front design phase. Before any UI work or data modelling is done.
Anwering those questions will help determine what that MVP will look like, and whether it will annoy users or have them wanting more. Apart from the obvious technical benefits it provides direction, motivation, and (one scenario) if you're looking for funding will help you articulate not just the product vision, but the technical roadmap, risks and, above all, provide a reasonably-informed estimate that will drive your financial models.
It's awesome that you go MIT.