In the past we have developed a matrix of "needs" and compared those to the product. - like a comparative feature list. Then done informal usability testing on the demo's.
Whilst that's useful for comparing features/cost etc it doesn't necessary reveal if there are fundamental assumptions within the product design about workflow or other important limitations built into the design. (I.e the product assumes that you have to do x before y, but it turns out your company never knows x till the last minute - or something). It does help you narrow down to a smaller list though. A possible way to get to some of other aspects is to treat the products as you might a prototype, and test them against personas and scenarios developed to represent the needs of your team and the characteristic of how they work. (This suggestion comes from chatting about this topic with my supervisor Dr Toni Robertson whose past research covered "shopping" for COTS" at one time though the focus was different). By developing personas and scenarios you develop a clearer idea of the work that the software has to do, and a better understanding of the way that people work - then you can evaluate the different products using those resources in decision making. Apologies if this is kind of stating the obvious, but I thought it worth sharing nonetheless. Cheers Penny . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Posted from the new ixda.org http://www.ixda.org/discuss?post=42857 ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... [email protected] Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help
