We have created a mental model for a large website redesign project. We are in the process of mapping content and functionality to task towers.
While I understand how it gives an indication of what behaviours are supported, I'm not sure how the mental model can be used to inform the site's information architecture. The UX lead seems to believe the model will?
The mental model attempts to define a map of the user cognitive processes. Depending on how it's done it can help define what is the user looking for, what kind of decisions is she taking etc.
In my experience mental models serve more as a framework to refer to as one explores different possibilities. The mental model itself does not deliver specific design choices.
For navigation you still need to do exercises like card sorting, or do task flow diagrams etc. Once you have done those, the understanding of the mental model would help you evaluate the results and make better decisions.
In my experience, once you know which tasks your user must complete, you can then define your task flows.
With task flows you can figure out which pages you need on your site. You also figure out what goes on each page & how everything is grouped together on the page.
Then you can start to define how the various pages are linked together, which informs your interaction areas & navigation areas. From there, you create your wireframes.
I think a lot of it depends on how you developed and verified this mental model. If you derived it and tested it with users, it will give the user a framework with which to understand and predict your system instead of requiring the user to wrap their head around your system, on your system's terms. This can be especially true if your system's information architecture is based off technical requirements or business rules.
A mental model is a cognitive construct of how a system works. It may or may not be accurate but it can be useful if it helps a users interact with the system successfully. A good mental model is one that seems natural to users and gives them enough of an understanding of the system to be able to predict how it will work. They are usually simplified or abstracted versions of the actual system model.
A more common term for a mental model is a "working understanding". Someone might not know exactly how their home heating and cooling system works, but he might have enough of a working understanding to be able to set it and maybe even troubleshoot minor issues.
I'm not too experienced with this but here goes. Also, my understanding is going from a mental model ( business models ) to website architecture ( database model ). But a have a tickling feeling that I'm wrong about that.
First, unless the UX guy has some experience working in the middle tier/back end, I think you should take their advice with a grain of salt. Depending on how the service layer is build, it can very highly reflect the database with 1-1 relationship of model to table or it might not.
My usual process is
What are the things that can exist without any other things? These become their own table/entity.
Which entities have relationships with each other and how do I build those relationships into the database? ( try to normalize the data as much as possible while keeping related attributes together )
Use it and see where it breaks and fix it
