5 ms·

Or, start from the user experience. Both are good places to start, and both should be given serious consideration early in the project. Code is usually the wo

Or, start from the user experience. Both are good places to start, and both should be given serious consideration early in the project. Code is usually the worst place to start. If you do need code early on, I think it's fine to write it as quickly as possible, even ignoring edge cases and simplifying algorithms. If you have good data structure design (and understand the invariants) and you understand the problem space well from a functional standpoint (including functional edge cases), you can get the code into shape later. The bugs you encounter will be mostly the trivial kind. But if you misunderstand the user experience, or the data structures are a mess, then it's difficult to recover. That's one of the reasons SQL databases are so great: they help you get the data design up and going quickly, and will enforce a lot of your invariants (through schema normalization, PK/FKs, and CHECK constraints). If anything goes wrong, rollback returns you to a known-good state. I don't know anything equivalent at the user experience level, though.

deleted 11y ago
[deleted]
nostrademons 11y ago
This is one reason why prototyping is often so necessary. When you start from the user experience, you usually end up working your way back from the front-end: first you visualize what the user should see, then you mock up screens to give them that, then you figure out what they should be able to interact with and how, then you write code to make that happen, then you define data structures that make the code possible. When you start from data, you identify what data the user will need to manipulate, then you identify relationships between that data, then you write code to manipulate it, then you slap a UI in front, one which usually mimics the relationships you identified a priori. There's a bit of an impedance mismatch here. Start from the UX, and you end up with a bunch of ad-hoc data structures that are very difficult to rationalize and inefficient to access. Start from the data, and you end up with a UI that mimics the data you were given and not how the user thinks about achieving their task. The solution is to write a quick & dirty prototype focusing on UX, nailing it but focusing on only the happy-path that's core to the user experience. Then take careful note of the data structures that you ended up with, and throw away the prototype. Then you start with a carefully planned data architecture that captures everything you learned in the prototyping phase, but eliminates redundancies and awkward access paths that you wrote in the quick & dirty prototype.
- applecore 11y ago
  The better solution is to start by designing the API, and to leave the design of the data model (to support the API) and myriad of user interfaces (as clients of the API) for later.
  - nostrademons 11y ago
    You don't know what should be in the API until you've had a couple clients built on top of it. Users will surprise you; oftentimes that little UI detail (the one that's really hard to fit into your API) is what will make them buy.
    - Chris_Newton 11y ago
      A similar argument also applies in the opposite direction. That is, it’s all very well beginning with a beautiful, idealised API, but if there is no efficient way to implement that interface then you’ve backed yourself into a corner before you even start.
      - XorNot 11y ago
        Also UIs which don't have to support an actual data manipulation tend to underestimate dealing with the edge cases of that manipulation - which I tend to think is why you never get too far from the shell in Unix-likes.
        nostrademons 11y ago
        And why so many database-backed webapps look like a frontend over a database, and virtually all mobile messaging apps are frontends over TCP/IP, and web directories before Google were just webpages with a whole lot of links. It turns out it can be pretty profitable to break with the machine model of the underlying data and instead present things the way your users want to see them, even if it makes the code necessary look complicated and gross. The danger with building the data model or API first is that you'll build the easy, obvious API, which is the same easy, obvious data model & API that all your competitors build. Start with the user instead and you can end up with some really powerful differentiators, at the cost of it being a bitch to transform into working, sane computer code.
onion2k 11y ago
The data constraints in an application will inform the user experience. Until you know what your application has to do with data any UX design will be guesswork. I agree that the user experience development should come before any code, but it can't come before designing the data structures.
liotier 11y ago
> Or, start from the user experience. > Both are good places to start Reminds me of Merise - a modeling method where the data model and the process model co-evolve in parallel. After many years I still have a fondness for it - but maybe that is just the French 80's kid in me...

deleted 11y ago

[deleted]

nostrademons 11y ago

This is one reason why prototyping is often so necessary. When you start from the user experience, you usually end up working your way back from the front-end: first you visualize what the user should see, then you mock up screens to give them that, then you figure out what they should be able to interact with and how, then you write code to make that happen, then you define data structures that make the code possible. When you start from data, you identify what data the user will need to manipulate, then you identify relationships between that data, then you write code to manipulate it, then you slap a UI in front, one which usually mimics the relationships you identified a priori. There's a bit of an impedance mismatch here. Start from the UX, and you end up with a bunch of ad-hoc data structures that are very difficult to rationalize and inefficient to access. Start from the data, and you end up with a UI that mimics the data you were given and not how the user thinks about achieving their task. The solution is to write a quick & dirty prototype focusing on UX, nailing it but focusing on only the happy-path that's core to the user experience. Then take careful note of the data structures that you ended up with, and throw away the prototype. Then you start with a carefully planned data architecture that captures everything you learned in the prototyping phase, but eliminates redundancies and awkward access paths that you wrote in the quick & dirty prototype.

applecore 11y ago
The better solution is to start by designing the API, and to leave the design of the data model (to support the API) and myriad of user interfaces (as clients of the API) for later.
- nostrademons 11y ago
  You don't know what should be in the API until you've had a couple clients built on top of it. Users will surprise you; oftentimes that little UI detail (the one that's really hard to fit into your API) is what will make them buy.
  - Chris_Newton 11y ago
    A similar argument also applies in the opposite direction. That is, it’s all very well beginning with a beautiful, idealised API, but if there is no efficient way to implement that interface then you’ve backed yourself into a corner before you even start.
    - XorNot 11y ago
      Also UIs which don't have to support an actual data manipulation tend to underestimate dealing with the edge cases of that manipulation - which I tend to think is why you never get too far from the shell in Unix-likes.
      - nostrademons 11y ago
        And why so many database-backed webapps look like a frontend over a database, and virtually all mobile messaging apps are frontends over TCP/IP, and web directories before Google were just webpages with a whole lot of links. It turns out it can be pretty profitable to break with the machine model of the underlying data and instead present things the way your users want to see them, even if it makes the code necessary look complicated and gross. The danger with building the data model or API first is that you'll build the easy, obvious API, which is the same easy, obvious data model & API that all your competitors build. Start with the user instead and you can end up with some really powerful differentiators, at the cost of it being a bitch to transform into working, sane computer code.

onion2k 11y ago

The data constraints in an application will inform the user experience. Until you know what your application has to do with data any UX design will be guesswork. I agree that the user experience development should come before any code, but it can't come before designing the data structures.

liotier 11y ago

> Or, start from the user experience. > Both are good places to start Reminds me of Merise - a modeling method where the data model and the process model co-evolve in parallel. After many years I still have a fondness for it - but maybe that is just the French 80's kid in me...