I'm really interested in this. How might a user-centered data model be created? What kind of requirements capture process is involved?
User-centered design starts at the data model
It kind of goes without saying that you are building for the users of your product and not yourself (unless they are one and the same thing).
This requires a level of empathy and discipline (mostly to resist death by config option when trying to please everybody all the time).
This process starts with the data model.
Stories help. Keeping things abstract helps a lot (it was no accident that Elgg makes extensive use of object->metadata for storage). Basically, be lazy in making decisions & push them forward.
I find it helpful to start with the thing that's at the heart of the system. So, for example if you're building a calendar app, then the first thing to model is the calendar, and what people can do with it.
Basically all the stuff we learned in CS with UML, but obviously without drawing UML or following a rigid Methodology. Both of which I abhor.
Ben Werdmuller added Keith Robinson and Caroline Keem.
I start with a focus statement that is broad (e.g. I'm looking to improve the user experience of our calendar feature) and then I go observe users. What's important is to view the "real work" of users within their own environment. They will say they do one thing but then when I actually watch their process and see them in context I find out more details about their steps. So I may find that they augment my calendar feature with the one on their mobile phone and a paper calendar AND sticky note reminders on their monitor.
Consolidating these observations across users gives me solid stories of the real work & user intention to be supported. I start out with these stories when brainstorming, building requirements & storyboarding.
I don't exactly start with a data model, but I think I get where this is coming from. When kicking of a brand new project (say for a mobile app or a feature for an existing app like Desk.com) I'll do some research (customer development, interviews, etc.) until I've got a good idea of problems/opportunities, etc.
Once I've got that I begin to list out potential user activities, or stories. At this point I also find it useful to begin to explore the structure; of the data, of the views, etc. It helps to have engineers (assuming I have some) involved here as well.
Structure/activity together give me a pretty good picture of what we need for a prototype, as well as a nice tie back to the problems/opportunities I've got.
