What UX guidelines should one keep in mind when designing the GUI for a automobile center stack/console?
Desgining the UI for a center stack (100% touchscreen), still in the wireframe stages. However, when mocking up the home screen, it dawned on me I don't know much about UX (I do mostly backend work, and am slowly breaching my way to design). So, that leaves me two options:
Blindly follow the OEM's design just because it's the OEM's design, while changing simple things like icons and backgrounds.
Create a new design from the ground up, while taking into account hig (if any exist for this sector).
I would like to go with #2, to set my UI apart from the rest, but still be easy to use. I have a few guidelines in mind, but want a 'sanity check' and also if any documentation exists on this somewhere then also have that as a resource (I'm still googling for this at the time of this writing).
Here is what I have so far:
Anything potentially used by the driver while driving should be easily identifiable at a glance, and easy to use/change (i.e. BIG BUTTONS with familar pictures
Settings/Options most likely used should be not be more than 1-2 levels deep, if at all possible.
Important/Relevant Information should be displayed on every screen such as the clock, important diagnostic/service information such as battery charge for electric vehicles, etc.
Fast response time, meaning no (or very little) cheesy screen transitions. My theory is that on this platform it wastes time, and the longer it takes to refresh the screen with new content, the longer the driver's eyes are off the road (potentially). Not a big deal at a red light, but obviously almost everyone has changed the heat or radio on a freeway, where taking one's eyes off the road for 4 seconds @ 60mph is equivalent to traveling the length of an entire American Football field blind.
I'm sure I have more, but those are the high points of course. Any more info is welcomed.
Update
To be crystal clear, I am asking what (if any) UX guidelines exist for the automotive platform, or what one should keep in mind. This is not a 'port' of an existing application to a platform that has publicly established hig. user1757436's link provided valuable documentation on some of the research done in this domain.