Here I am, joining the conversation we have started with @simonv3 on Slack.
I have indeed been working on the user flow of Openfarm, from the perspective of a beginner in gardening to a more advanced one, which included to conduct some research on my end. The UX/UI deliverables I came up with are all shared under Openfarm Github repo. And aimed at reaching the goal of improving the usability as well as the user engagement to create and use more growing guides. In short, get the job done more accurately by Openfarm for folks using it.
Here is my take on the topic what’s designed vs. implemented, that could apply to Openfarm and any product developement I had worked on so far, whether it is Open Source or not, with a remote distributed team or not, non or for profit:
Are we talking about the designer ego? No.
One could think a designer want to shine with their interface, like a developer with their program. And if not implemented what the purpose of just working on it, right?
My view on it is mainly related to usability and testing: with no implementation, there is no one to use it, and therefore no way to validate or invalidate initial assumptions. It just remains as a pure theory. So in general, my main frustration when working on something is not seeing the product in action soon enough to be able to iterate on it.
Are we talking about the designer role that needs to become the jack-of-all-trades? Don’t think so.
One could easily say: “well you have this brilliant idea, but until it is executed, it worths nothing, so you got to do it yourself!”.
I’m an advocate of DIY, of building software programs as a designer, of launching projects on my own, and I am also a huge fan of team collaboration. If I join a project with an existing team, I thrive in sharing ideas with others, messing with my Github PR and being rescued, getting excited when there is a milestone achieved with my teammates. So what the point of a single person doing everything from end-to-end on a collaborative project?
Instead, I think they are two main topics that are deep anchored into the layer of this phenomenon we observe:
Does it get the job done vs. is it theoretically perfect?
A general tendency I have observed is to lead the product development with features fixing rather than usability. Disclaimer: this applies to all the projects I’ve been working on!
Features fixing is very satisfying as one often deals with bugs, emergencies, this pixel that doesn’t look right on the screen, this code that needs to be cleaned or made more scalable.
Usability forces to go out there and be exposed to the users and how they potentially dislike the product. It’s also when you get obsessed with how the product gets the job done.
My top priority and responsibility as a product builder (you see I’m stepping out of my designer role) is to make sure the job is getting done with the product.
In the case of Openfarm, it’s not yet there.
Recently, I’ve asked an ongoing project I’m working on if bugs prevent the users from using the app? Meh… probably no. Then the problem might be somewhere else ^^
Open Source/ Distributed team misconception
Open Source projects rely on the (often free) work and time of contributors. Which doesn’t mean because contributors are offering their time, there should be no clear direction, deadlines, milestones for the projects. Same for distributed teams. And I have advocated for that on Openfarm, by implementing a backlog of Github tickets based on their discussion stage and implementation needs.
Then this circle back to the tendency above: with no clear goal about getting the job done, any organization (open source or not, distributed or not…) is likely to lost momentum at gathering people around building a product.
What kind of concrete principles could we apply then?
- have a clear onboarding for contributors to get more visibility about what they can bring, for how long, how often, and which doesn’t rely only on cheering them on Slack or Github: can be a form, a twitter bot…
- point them in a single direction to get started: communicate with one voice about the single destination where to go to see the backlog vs. the unordered list of tickets, fork the repo…
- when writing a ticket cut down in 5min-task so that anyone available for few min can work on it
- set up a clear goal for the discussion channel: is it to welcome new contributors? And why? Is it to gather user’s feedbacks? for how long?
- set milestones, deadlines, draw and share a roadmap often
- balance time and energy in building the contributors community vs. building the product itself
I have a blast at continuously thinking about how to work more effectively with that set of constraints. We are not really reinventing the wheels, a lot of methodologies already work out there. What’s probably missing is some kind of crowdsourced Guidelines/ Code of Conduct to rely on, to follow, to complement with each other experiences and perspectives.
What kind of concrete principles have you envisioned and/ or tested on your side?
@ei8fdb Can we agree on a communal song instead? ^^