Month: January 2020

Contexts and Practicalities, by Christopher Stein

In his blog post “Context and practicalities,” Christopher Stein offers his students (and us) a clearly structured, easy-to-read overview to approaches to product design, and especially software design. The post provides guidance that I found practical (as promised in the title), relevant and useful in understanding the software and digital platform design process, and thinking ahead to possible and certain future projects. Equally helpful is his historical (or at least narrative and sequential) description of the iterative developments of of the Waterfall Method, Instructional Systems Design, User-Centered Design, “agile,” all terms from the design world that I have heard often, but had not seen defined and explained so clearly. (I believe this post was written before the further development of Human Centered Design that arguably has evolved from User-Centered Design; for anyone interested here’s a quick explanation of the difference and relationship between the two).

Having never designed software, and imagining that the same is true of most of us, I thought it might be useful to relate Stein’s post to at least one areas that is more familiar to all of us, namely, research.

In this regard I was I interested to compare the guiding questions that Stein recommends in the “Five W’s and one H,” as well his description of the Waterfall and User-Centered Design processes, with the questions and steps we each may typically take in initiating and planning a research project. As a thought experiment, I considered how an educational research study might work – and possibly be enriched? –  if it were carried out as if it were a software design project.

Several of the questions and steps Stein describes (“What are the goals of the project? What need or problem Will it satisfy?”; Analysis, Design, and Testing, respectively) seem more or less analogous to those built into a typical research process. The most significant difference in the two types of processes that jumped out at me was the emphasis on purpose and usability (or just usefulness) that is integral to the software design process, and not always given weight or even present in educational research. I find the idea of an educational research project and process that tests whether findings are purposeful, usable and useful (or even used) compelling – especially if that testing process were guided by the perspectives and experiences of people who are meant to benefit from that research. This line of thinking also brought to my mind Leigh Patel’s guidance for researchers to decolonize the research process by beginning with the questions, “Why this? Why me? Why now?” (Patel 2016) – and the hopeful possibility that some of these questions might be answered not only through our own reflection as researchers, but through practical assessment by the people whom we intend to serve through our research.

Could Stein’s “Five W’s and one H,” and/or the Waterfall or User-Centered Design processes be applied and/or adapted to a research project in your respective disciplines? How would those differ from or alter your typical research process? How might applying or adapting these questions or steps to  your research process affect the relative validity and quality of the results and/or product of your research?

If the results of one of your studies were tested by an “end user” of your research – who would you want that end user to be, and how and for what would you want them to test the results and products of your study?

37 Signs You’re Doing Too Much

Getting Real is a “quick and dirty” read on doing things in a “quick and dirty” way. The tenets remind me of Voltaire’s Candide in his advice to tend to one’s own garden rather than fixate on the world at large, and of the seeming tautology: Good judgment comes from experience, and experience comes from bad judgment. Yet works such as this provide a valuable loophole: gaining the vicarious experience of others bad judgment so that we may grow wiser while obviating first-hand failure. With perhaps more don’ts than dos, this book can help all of us emerge a bit from the self-regarding torment the words “new,” “technological,” and “project,” haphazardly strung together like Christmas lights at a frat house, brings to the junior academic soul.

Pick something, is it bigger than a breadbox? Do you even know how to build a breadbox? See, already we’re mired in considering yeast, gluten, temperature, humidity, materials and locations; the trap easily makes itself. While the advice in this book is specifically targeted to tech startups, it has some salient lessons for us (as we further embark on our ITCP projects), a few of which I will paraphrase. 1- Don’t try to “reinvent the wheel;” 2- Focus on a real thing or issue; 3- Don’t invest heavily in niche solutions (don’t learn java for one button;) 4- Don’t try to anticipate all possibilities, just be ready to respond; 5-get something done: ugly, wonky and working is better than a beautiful theory; 6-Don’t add features before you develop function. 7- Try to work in chunks; 8-keep working until you have something for others to test and critique; 9- If you can’t break the concept down to doable tasks, it’s still just a concept; 10-get feedback from those who may actually use your project.

My only issues with this “manifesto” are with points 8 and 10 in the previous paragraph. The truth is that academics work woefully alone. Academia is silos within silos, a nesting doll of departments and offices.  As a rule, academics (emerging or otherwise) do not work in teams, this can make it very difficult to put realistic constraints on projects that often live too long and grow too large in the mind. This isolation has one retreating time and again to the grand recesses of our own overexcited minds. The esoteric nature of most academic content areas means that it is unlikely we will build teams to share in the workload and day-to-day decision making. Yet, I think academics can help each other “get real,” maybe this course will enable some such pairings. Having accountability buddies could help us all get out of our heads and on with our work. How wonderful and refreshing would it be to have someone also engaged in a technology project, though perhaps from another discipline, check in and tell you: “Don’t do that, that’s stupid.” I myself would be infinitely grateful.