UI之旅－生活总是赏赐不浮躁的人们

本文原始地址：http://ui.blogbus.com/logs/5123727.html
UI之旅乃作者的随手笔记，请移步到用户体验研究blog--油茶研究会

*The first and most important impact is whether we helped / hindered in shipping our product.  We define “helped” as: 

• Helping to define whatever processes intersect with the UI, from documentation strategy to business requirements documents to performance.  If our group touches it / needs it we work proactively to make sure it’s being well defined and that our requirements are fed into it—even if it means we have to own it / influence it heavily.

* Another way we have impact is to communicate through visual representations of concepts, wherever we can “show what we mean” we try to.  Be is a proof-of-concept UI, or a new visual look, or an internal business process.  We try to find a way to tell the story with pictures, it’s much more easily understood.

* We provide design guidelines, and using the above notion of “helping” we proactively push for componentization of UI elements to ensure design consistency.

* On justifying budgets and headcount.  With regard to headcount, we simply paint a high level picture of what products are at risk (ie from a Quality) perspective with current resources.  We show the current person-years of worked requested, the current person-years of work we can deliver, and the gap. We also try to be responsive to industry trends in cost cutting, ie by hiring human factors and design professionals in India.  

For contractor budgets, this is pretty straightforward, we use industry standard ballparks for the cost of usability and UI design activities for contractors.

* On the usability engineering front we measure impact more formally by measuring basic performance of ‘showcase’ prototypes before coding (ie task success / failure, errors, assists).  We also benchmark these same ‘showcase’ products when they’ve been fully coded with the same measures, and we add a few more including time on task (using the ANSI CIF reporting format), SUMI, and some other satisfaction measures.