Purpose of this Blog

Hello! The purpose of this Blog is to chronicle my learning in EDER 679 - User Centered Design 1 and II. . It is my hope that blogging about my thoughts will help me to form deeper understandings and make more connections in my learning. In large part, this Blog is personal in nature. However, I also hope that by participating in the community of the class that others will benefit from my thinking, as I will no doubt benefit from theirs as I visit their blogs. By engaging in this blog I hope to "construct and augment my own understanding of the content socially through conversations" (Seely Brown, 2002). This blog constitutes a learning medium through which I hope understandings will be not only socially constructed, but also shared ... knowledge creation in action!

Be sure to see the "Purpose/Mission Statement in Detail" page of this blog for a more detailed description.

Monday, March 7, 2011

Preece, Sharp, & Rogers - Chapters 10 & 11 - ePortfolio Chunk #8

What are requirements?

"A requirement is a statement about an intended product that specifies what is should do or how it should perform" (Preece, Sharp, & Rogers, p. 476).

And an interesting description of requirements from the Philosophe website: http://philosophe.com/design/requirements/

"Any coherent and reasonable project must have requirements that define what the project is ultimately supposed to do."

It was interesting to read that "every product will have requirements under each of these headings" (p. 520):

functional - what a system should do - in our case, it should provide a succinct description of the process of creating a new story and adding a picture ...

data - "capture the type, volatility, size/amount, persistence, accuracy, and value of the required data" (p. 479) - I'm not certain that this fits for our tutorial example.  The data flows in one direction, with users controlling the pace of the flow - is this our data requirement?
environmental (context of use) - "circumstances in which the interactive product will be expected to operate"(p. 479) - I think we have this covered - including physical environment (no special considerations, except an acceptable level of background noise (i.e. not too loud), social environment - perhaps this refers to the presence or absence of children?  Organizational environment - doesn't fit? technical environment - covered - will run on handheld devices ... limitations??

user characteristics - familiar with handheld devices and basic operations; key attributes - those who would use our tutorials are likely more novice and require step-by-step instructions - more proficient users would likely be able to navigate through the application (Virti-Cue) without relying on the tutorials for instructions

usability goals & user experience goals - efficient, effective, easy to use; easily learned and memorable



I am not convinced that we have addressed the requirements for our application (production phase) in each of these areas.  In fact, as I think of what the requirements may be in each of these areas, I am not able to come up with a list - for some, yes, it's easy, yet for others it's very difficult.  Then I think about the suggestions the Preece et al. give for determining or rather "establishing" requirements and see that it needs to be done through "data gathering, analysis, and interpretation activities that have been established from a sound understanding of the users' needs" (p. 476). I suppose we did this with our last usability testing in the fall session - we gathered and analyzed data, the interpretation of which informed us of our users' needs.  Perhaps for this stage of our design we need to focus more specifically on the tutorial format and review the particular requirements of this specific application - as I have attempted to do above.

In the evaluation stage, we will engage in further usability testing employing observations, interviews, and questionnaires in an attempt to both gather data and triangulate results.




No comments:

Post a Comment