A good friend, Enric Senabre, together with Ricard Espelt (who I don’t know) wrote and published an interesting article on designing for platform cooperativism. They set out to define “platform cooperativism UX”, which seems to be to be a very concrete task on one level (UX is nothing if not concrete) for a general state, approach, or category of ‘platform’.
I’m not going to go into detail here about Platform Cooperativism, because I don’t really get it. I do know Trebor Sholz and figure whatever he does is probably right and makes sense. So I’m buying the book to find out more.
Enric and Ricard are approaching software design by intersecting strategies to overcome technically disenfranchising stakeholders while ‘learning as you go’. These are laudable aims, especially in the NFP sector where there is a great need to develop solutions that actually solve problems. As I read somewhere recently, the technology community has no shortage of solutions, what they are in need of are solutions that solve problems. Zara Rahman has also pointed this out recently and is conducting research into just this area.
The issue here is that often technologists see all problems through the eyes of code. Further, they are prone to see the intended beneficiaries of their work as avatars. There are, in fact, many strategies to turn real people with real needs into avatars.
If you try to solve real world problems with code, and your participants are avatars, you are really setting yourself up to be a great game developer. You are possibly not in a good position to solve real problems.
So, Enric and Ricard are starting off with the right premise and in the article they document their experiment, exploring fundamentals to come up with a new facilitation methodology for this context.
we began with a reflection on which specific functionalities and features (other than those available on existing online platforms and social web interfaces in general), if any, could be explored
They seem to have given themselves an extremely difficult task – designing for an open-ended ‘imaginative’ state. Although they couch this as ‘specific functionalities,’ I take it they are trying to define specific functionalities for a generalized approach to platforms. That is tricky. I admire that they took this on. Innovating with design methodologies takes some gusto, and it is a vital process for defining and refining tools for a new method. However, in my experience, open-ended problems like this seldom lead anywhere useful. You need to start smaller, with real, concrete problems. These might add up to, and constitute, larger issues, but the road to those issues is from the bottom, not the top.
...we finally arrived at the key element of online reputation systems for every social web application.
It seems that the result was still productive, but perhaps not in the way expected. They appear to have elevated the group’s awareness to issues of trust in the social web. A hot topic at the moment. As such, the process is successful as a barometer of the times, identifying issues that concern people here and now. Enric and Ricard appear to have understood this too and continued on to refine this starting point, moving it towards actual UX design with the well-known method of user stories.
However, user stories are best deployed as a function of software design and I don’t think their process was there yet. User stories require a concrete problem. They are intended to drive people toward designing a concrete solution. Bringing this framework to a general question of reputation is confusing methods and will cause cognitive drag and a mixed understanding of intended results. It would be better to keep this part of the process outside of software design paradigms, and instead, employ general ‘sense making’ methods.
It seems that Enric and Ricard diverted from the goal to produce concrete UX and ended up driving towards requirements. I would say this is a better direction. However, requirements-gathering for a general issue is not well placed to lead to much of use to software development other than a ‘general direction’ – which is what they seem to have achieved but not what they set out to achieve.
As such, I think the results of Enric and Ricard’s experiment are interesting, but the results are not interesting in the way they outline. In the summary they state:
The next steps in addressing “platform cooperativism UX” should continue along these lines: new user stories that generate both potential platform coop requirements and design-driven research outputs.
This overstates the value of their findings as generated by the participants. The real value of this session is that they tried to assemble a methodology for an ambitious context – in essence, they are actually trying to help the ‘platform cooperative’ community to understand itself, to understand the implications of their philosophy. I think that is really interesting and admirable. What they need to do, however, is not to override this aim with the pretense of generating actual user stories, software requirement, and UX for platforms. They need to name and design a method that starts in another place – a place where the articulation of values is the outcome, not the construction of code.
Hi Adam,
Thank you very much for your detailed response to the experiment we started! I completely agree with you in terms of how complex or even unrealistic could be to ask “design questions” for open ended problems, but as you also mention we finally focused on a specific need (trust among peers, and reputation mechanisms for generating it). This was a first result of constructive and discursive iteration generated by sharing some possible new icons, modularly composed user stories and (very basic) drafted requirements.
Our aim was to keep refining a methodological tactic that follows this logic, connected to the tradition of participatory design, but also the implicit-explicit loops behind agile and lean: designerly ways of generating solutions to community-oriented problems (usually with some digital tool/context involved, like in this case), while at the same time generating data and insights that can be incorporated to research / knowledge outputs.
In times when software has taken command (quoting Lev Manovich book, or in other words when “software is eating the world”, as I read somewhere else), user stories as a structure for agreeing on who, how and why solving all kind of problems makes a lot of sense to me, even moving behind the main focus of software development. With Platoniq there’s a line of work doing this with other partners in the incubation of civic-oriented projects via “idea camps”, for example
I mean user stories as “a generative game” not only for identifying software requirements (in my opinion a requirement is a more refined, detailed and developer-oriented user story, that emancipates from such a common language). User stories can help to bring in some stages of a research different perspectives and integrate diversity. If you add then some participant observation in parallel, and try to extract from the discussions what’s behind assumptions, limits, context, views etc, while a group advances in making the user story a more concrete design afterwards, then both ways combined are in my opinion not much different from the practices of action research.
I think that connects also to what you consider at the end was the real value of our little experiment (which was concentrated in less than one hour, so not optimal conditions at all, when the ideal context for these things as you know are dedicated retreats and “slow sprints” 🙂
In my opinion, it represents some validation that this dual ambition is viable: research through design (my main source here is still the book “Universal methods of design” https://searchworks.stanford.edu/view/9706083 full of nice documented tricks) for generating useful or practical results (in this area, documented user requirements) while also contributing to areas of knowledge or discussion in a given domain. Like we are doing here, at some meta level!
Enric
hey Enric,
I think here is some useful outcomes of the experiment. I would categorize them as two distinct parts:
1. the ‘findings’ from the participants
2. an exploration of a process
Number one is what it is, and you can see it as more or less useful. It seems it was useful for helping the community start to understand the utility implications of a political critique of platforms. That’s a useful thing in itself.
However I think the results of (1) are a direct outcome of the process, and I believe the process was a good start but I would recommend you take the opportunity to rethink things a little. This will help you with (1), ie. get better results.
Its for this reason that I challenge the tools you chose to use. I don’t think the intent or even framing of user stories is very useful. It will get you something but you could get a lot better if you threw user stories away and came up with something new, even if it is just to change the language. ‘Users’, for example is also a politically loaded term when it comes to platforms. It suggests a form of subservience (in my opinion) to both the developers of the platform, and the technology itself.
Platform Cooperativism, as far as I can understand, is trying to escape exactly this paradigm. So I would challenge at the very base level the use of language of ‘user stories’.
But actually, I think there is a greater problem – the problem of using a process for designing user interfaces in a process that is never going t give you a design for user interfaces. Your explorations are at a far more important higher level and you deserve a process that maximises the outcomes of that exploration. Why use a software design paradigm when that is not what you appear to be doing. Don’t force this process into a software design process yet. It is too early. Design another, more appropriate process with more appropriate language, and use that. Then when you are actually designing UX, throw away that tool and use user stories (or something similar).