Designing Technology for Major Life Events Workshop

High emotional impact and the value of the journey are two big aspects of designing tech for major life events.

High emotional impact and the value of the journey are two big aspects of designing tech for major life events.

While at CHI, I got the wonderful opportunity to help organize the workshop on Designing Technology for Major Life Events along with Mike Massimi, Madeline Smith, and Jofish Kaye. We had a great group of HCI researchers with a diverse range of topics: gender transition, becoming a parent, dealing with a major diagnosis, bereavement, and more. My own interest in the topic grew from my experience designing technology for divorce and technology for recovery from addiction. In one of the breakout groups, we discussed the challenges of designing technology in this space and some of the ways we’ve dealt with these challenges in our work. In this post, I want to highlight a few of these:

Building Tech is Risky. Building a system requires the designer to commit to specific choices and it’s easy to find something that wasn’t adequately considered after the fact. In tech for major life events, this challenge can be exacerbated because the consequences of a failed design might have big emotional repercussions (e.g., tech messing up some aspect of a wedding). Sometimes, it is a big question of whether we even should try to bring tech into a given context.

Ethics of Limited Access. Building technology to support a major life event may mean excluding those without the financial means, skills, motivation, language, etc. to use the provided intervention. Additionally, we frequently stop supporting a prototype technology at the end of the study which can be really problematic if it was providing ongoing benefits to the participants. Again, because of the high stakes involved, issues of ethics of access to technology may be exacerbated when designing for major life events.

Tension Between Building Your Own and Leveraging Existing. Many systems we build require some critical mass of adoption before they are really useful. This is particularly important with tech for major life events because there may be relatively few people facing a particular relevant context at any point in time. One of the ways to deal with this is to piggyback on existing systems (e.g., building a Facebook app instead of a new SNS), but this may cause problems when the underlying technology makes changes outside of the researcher’s control (e.g., privacy policies change, APIs stop being supported, etc.).

Asking the Right Questions about the System You Built. The final challenge is understanding what kinds of questions to ask during the system evaluation. On one hand, it is important to go into the evaluation with some understanding of what it would mean for the system to be successful and the claims you hope to make about its use. On the other hand, it is valuable to be open to seeing and measuring unintended side effects and appropriations of the technology.

I think my two major take-aways from this discussion were a greater appreciation of how difficult it is to actually build something helpful in this space and the insight that many of these problems can be partially addressed by getting away for the type of study that focuses on evaluating a single system design using a small number of metrics. The risks of committing to a specific design solution can be mitigated by providing multiple versions of the intervention, either to be tested side-by-side or to let participants play around until they decide which solution is a better option for them. The ethics of access can be ameliorated by providing low-tech and no-tech means of achieving the same goals that your high-tech approach may support (e.g., Robin Brewer built a system to let the elderly check email using their landline phones). Planning for multiple solutions when building using others’ APIs can lead to a much more stable final system (e.g., the ShareTable we could easily switch from the Skype API to the TokBox API for the face-to-face video). And lastly, the problem of figuring out what to ask during and after a system deployment can be addressed by combining quantitative methods that measure specific predicted changes with qualitative methods of interviewing and observation that are more open to on-the-fly redirection during the course of the study. Overall, diversity of offered solutions, flexibility under the hood of your systems, and diversity of methods used in the evaluation lead to a stronger study and understanding of the target space.

What’s In a Word

9409141159_66fbabd750_z

There were a lot of sticky notes involved in figuring out my next research agenda. Luckily, I got great help at DSST!

Recently, I had an amazing opportunity to attend the DSST (Digital Societies and Social Technologies) Summer Institute in College Park, MD. DSST brings together junior (e.g., postdoc, pre-tenure faculty) and established researchers from fields like Computer Science, HCI, Social Informatics, Information Science, Sociology, Anthropology, STS, and more. While there, I participated in workshops, got more familiar with methods used in other fields, and got a lot of great tips on articulating my research agenda (this is frequently a struggle for me because I have such broad research interests).

In small groups, we mapped out the research space of DSST, focusing on how we fit into the picture of a research area that encompasses so many different communities and venues. Interdisciplinarity is not for the weak!

There is so much I could write about this event, but there is one particular issue that resonated in multiple presentations, workshops, and offline discussions — the issue of vocabulary. It seems to me, that the biggest problems in interdisciplinary work arise not when we don’t know the words the other person is using but when we use the same words in different way. Here are a few examples:

  •  Problem: In Computer Science, this term often means “research challenge,” as in “I’m working on the problem of how to connect parents and children who live apart.” However, in some Social Science domains the word “problem” may be reserved for situations that are broken or non-normative. In other words, “connecting parents and children” is not a problem to solve — I might be supporting families in facing the challenge of separation, but I’m not fixing something that is broken. In some ways, using the word “problem” takes agency away from the people we am trying to support, instead positioning the designer as “the fixer.” Usually, this is not what people who build systems actually mean. This is a loaded term and might be better avoided or replaced with “challenge.”
  • Theory: In Computer Science, this term often refers to the study of abstract constructs like Algorithms and Data Structures and frequently developed through mathematical proofs. In the Social Sciences, there are many types of theories serving different functions (my favorite reading on this is Halverston’s “What Does CSCW Need to DO with Theories?”). Theories are frequently heuristics used to understand and discuss empirical data and may or may not need to have strong predictive power. My personal observation is that theorists of both sorts have keen minds and a love for an elegant explanation and can become great friends once the vocabulary issues can be resolved.
  • System: In Computer Science, “system” usually refers to a set of software and hardware that performs a specific function. At DSST, it was more frequently expanded and used to refer not just to the software and hardware but also to the people, practices, and ecosystems around the use of that particular tool.
  • Ethnography: I’ve heard builders use this terms to refer to any sort of formative work that involves observing and talking to users. Not surprisingly, people who are trained as ethnographers might see this as an over-simplification. It’s hard to put the same label on a single week of observation versus two years of being embedded in a particular setting. Perhaps, rather than using the loaded term, it might make more sense to refer to specific methods used such as “two weeks of participatory observation” and “contextualized interviews.”
  • Social Computing: This is a slippery terms, because we are all still trying to figure out what it means. This area is at the intersection of social science and computational systems, but what is included or excluded? As I spoke to people at the workshop, many equated Social Computing with either large-scale social network analysis (e.g., “we looked at 3 mill Tweets”) or Crowdsourcing (e.g., “we leveraged the crowd to do citizen science”). I was happy to provide a third possibility that I believe should be included in the definition: mediated communication for supporting one-to-one and small-group relationships. I hope that we continue to include things like videochat, ShareTable, haptic connectedness devices, small online support groups, etc. in our definitions and investigations of Social Computing.

In industry, most of our work happens in interdisciplinary groups. This kind of reflection has helped me understand why at times I have had trouble explaining my work or outlook to somebody from a different background, like formal methods or software engineering. DSST reminded me the importance of establishing a common ground and a common vocabulary in any work that brings together diverse disciplines.

Cross-Cultural Parenting Advice

At CHI 2013, I attended and helped organize a workshop on Designing for Diverse Families. I’ve been meaning to blog about it for the past two months and recently reconnecting with one of the other organizers has given me the push that I needed. I want to tell you about one discussion that we are hoping to turn into an actual project. I also want to invite both workshop participants and readers who find this to be a compelling idea to potentially join in on this project.

The goal of the workshop was to better understand our own assumptions about what constitutes a “family,” understand the gaps in our own work, and see how we can be more inclusive as a community. The variety of projects presented really highlighted how different families can be in terms of structure, practices, values, and culture. While this diversity can make it very difficult to design for families, it is also an incredible resource. At a time when many parents experience a great deal of anxiety about “parenting right” and face conflicting seemingly authoritative sources on doing it this way or that way, it can be valuable to show that there are many ways to be a parent. Things that are assumed to be true in one culture, can be unheard of in another, but nonetheless children grow up and succeed. My favorite idea that came out this workshop is that getting a perspective from a different culture on specific parenting questions can be of benefit to many families. Basically, we want a parent to be able to ask “how do other families do this?” when faced with everyday worries such as when to introduce particular foods, how to sleep train a child, how to deal with an unruly teenager, etc. Presenting these answers in the context of their originating geography can help bring home the idea that there is no single right way of dealing with most of these questions, but rather many approaches that can be successful.

So, a few of us would actually like to make this happen! Here’s the basic sketch of a plan:

  • We populate the initial list of questions and answers using Yahoo answers
  • We continue getting answers to common questions by selectively using Mechanical Turk, tracking the geographic locations of the Turkers
  • We allow users to ask questions of the community and see a selection of answers from different parts of the world displayed on a map
  • Users are encouraged to give their own answer to another question when they see answers to their own

Obviously, it’s fairly rough at this stage, which is why I’m reaching out to y’all. So for the parents out there, would this be useful for you? For the builders out there, would you be interested in getting involved in making this happen? For the researchers out there, would you be interested in getting on board or just giving advice? If you are interested in being a co-investigator, please fill out this survey to let us know what you’d like to do and we can start getting a plan together!

Continue reading