Design Data? (follow-up from today's HCD breakout)

I was mulling over today’s Human Centered Design breakout meeting and it occurred to me that one possible lens for looking at all the issues we discussed is to think about design data; by that I mean, the data which is required to formulate and execute on a given design. Whether we’re talking about user feedback, feature requirements, budget numbers, or even our own mockups, I realize it can be helpful (at least, for me) to think of it all as different forms of data, which can inform the decision making process. And so like any kind of data, we can ask certain questions about it:

  • How do we capture that data and guarantee its completeness?
  • How do we organize and structure that data?
  • How do we clean, filter and process that data?
  • How do we make that data accessible and actionable to the user (ie, ourselves)?
  • Or, to get totally meta, how do we design a system for handling this design data in its own right?

I’m not sure if this is helpful to anyone else, and I guess it’s just a re-phrasing of the same idea(s) we’ve already tread upon, but perhaps we could work towards answering some of those questions within the specific context of OpenTEAM, with special attention to how all that can be achieved in coordination with the hub farms (keeping in mind the idea of “survey fatigue” that Kita or Greg mentioned).

Anyways, that’s my 2 cents. Looking forward to picking up the conversation tomorrow!

3 Likes

Without knowing anything about the HCD breakout, I quite like the list. I need to write something about an ISOBlue project that we ran in the Netherlands, the list actually helps me in structuring the content I would like to offer in the report.

1 Like

@AnneFarmHack, that’s awesome! Glad someone else found this line of thought applicable to their process. :slight_smile:

Hi. My background is economic and business. I have been working to develop open collaboration to beat ¨the blind competition behaviors (system)¨, and to your list I would add some other questions to frame the whole collaboration:

  • what is the need that we want to solve and how do we ensure, in advance, that ¨the innovation¨ will serve future users?
  • Who are giving and working to create value and contributing to solve ¨the need¨?
  • How do we measure openly the value of each contribution?
  • Who are capturing the value or how do we reward to the contributors.?

Many of us talk a lot about openness and transparence, but the simple basic questions above are very diffuse.
One proposal to face these questions is here. But of course it has to be improved and proved. Would you like to work on this open collaboration set of rules. The rules are very simple. The complex issue is unmask ourselves about our real motivations and desires… I am pretty sure that if we solve these issues, the collaboration will flourish…

Hey Jamie, I was reviewing the mural from the meeting back in March and realized that the tech team’s work in shared ontologies maybe helps hit on that.

It’s more on the tech side of what’s already structured, rather than focusing on the farmers, which I feel might be a good thing at this point.

I like this question and think it’s an important one to answer: How do we make that data accessible and actionable to the user (ie, ourselves)?

1 Like

Oh awesome! The ontology spreadsheet is great, and I could see it having direct usefulness to design. Names, and the relationships between those names, matter so much in interface design, as much as in data science. I can’t tell you how much time I’ve spent with users on the semantics of the word “crop” (does it refer to the actual stuff planted in my field, or is it more like Platonic form of that stuff growing in the field?).

This also reminded of this good discussion we had over on the farmOS forum:

The crux of that discussion was: what patterns do we find useful when structuring information for our data models, and how are they different from the patterns we find useful when structuring the same information in our interface designs? I think it’s important to identify a process for mapping information from our data models to our interface designs, without forcing the interface to take on the same structures and patterns of the underlying data model.

Perhaps an interesting exercise for the HCD group would be to shadow the work being done by tech team on ontologies, and try to map those concepts to a useful design model. Again, drawing on the farmOS forum discussion, I would ask what are the relationships that cut across these hierarchical models? For instance, I see a lot of the ontologies already in the spreadsheet are very strictly bracketed into categories such as “crop list” and “fertilizers”, but what if we look at the seasonality and consider what crops and fertilizers are used in the month of August, versus April? How does this relationship cut across all the ontologies, and what new insights might this relationship reveal to the user?

1 Like

Absolutely - that same transition (from a hierarchy organized by one group’s norms to a hierarchy organized by another groups norms) is what motivated the need for this in the first place. @sudokita showed me existing crop lists which are all built around genetics, phenomics, and/or breeding.

I’ve love to even come up with a very large list of ‘organize by month’ type ideas as test cases to ensure that we can serve that up. Even if on day 1 we’re still talking crop ontology in the ‘normal’ format, we should plan that our API can spit out crop by month ontology (or whatever similar variant) later in the game.

2 Likes

Excellent! And perhaps, getting back to the initial idea of this post, such a list could be the germ for a larger library of design data, as we test the usability of these ontologies against user expectations and document those results.

Now I’m imagining we create a sort of “shortest path” algorithm for how a user can navigate from one node to another in a hierarchical ontology, or trie, without having to traverse back up the root of the trie, by instead superimposing a graph-like ontology on top of the trie-like ontology, allowing for more lateral, direct movements. Something like this:

Or at least this is how my brain is working currently. :upside_down_face: