Cost of design versus cost of implementation

Design Lounge Communication and collaboration
1

In OpenFarm we’re facing something that I don’t quite know how to deal with, and I would love people’s inputs. It might be pretty unique in open source, but I think the effect of it is not.

One of the volunteers on our project is a ux / ui designer and has done some incredible work with scoping the project and putting in some great designs for us.

However, we don’t have the developer power to implement these new designs as development on openfarm happens in small spurts whenever one or two of the developers have time. And then often it’s on bug fixes and library updates (which can take up a large amount of time - it’s pretty much all I do on OpenFarm these days :frowning:)

This, of course, doesn’t make the designer feel super jazzed about the work they’re putting in, because they’re not seeing it realized.

Has anyone else encountered this? Have thoughts on ways to balance these two things out.

2

Do you (the current developers) seek to create more time for implementation, without getting more developers on board?

Or – collaboration – would you welcome more developers?

Are you at liberty to share one of the designs? Plus, ideally, a scoping document.

Context:

For anyone who would like to retweet:

3

Hi Simon, I think this happens more often than you think. Or at least it happened to me too :slight_smile:
I am involved with XWiki community for 8-9 year now. This means a very long time :slight_smile: I have created more than 500 extended design/improvements proposals and I don’t mention other mockups/ideas/notes that are on the issue tracker. Since we don’t track the design proposal status is hard to say what is the implementation percentage, but some years ago I remember we had the same dilemma. There were too many ideas / proposal / design work and too less developers to implement them.

I think the main factor is the designer’s motivation. It depends if he likes the project more or doing design more :slight_smile: and this is a very personal question. Also depends on his abilities and desires.

So I can see 2 options:
A. Since you have design proposal for the next year+ and no development power, I guess he might become demotivated and will seek other challenges / projects to contribute to. This is perfectly normal and quite healthy. As long as you keep him as a contact and member of the community, I’m sure he will contribute later and fix other design problems (it will be easy since the context is known). The only issue is if the time will permit it.

B. He might need to do other things than design. This was my choice. Now depends what each person wants and finds interesting. Since I am a Computer Science graduate, for me everything related to software is interesting. He can do from testing to product management, to development, to user research on the proposal he made in order to further iterate them. It also depends if the designer is funded or not (in order to not be needed to focus on sustaining himself).

I don’t want to go in the Specialist vs. Generalist discussion or if the designer should also implement or not.

Being involved for a long time with a project gives you a very unique perspective. You can learn so much by seeing your designs stand the test of time. The ability to propose a design that takes care of the majority of development and project history aspects means some proposals that are fast to implement and introduce less bugs.

Not this means, as a designer you don’t get that much diversity and expose to different types of users and problems.

Now a note, if the design is not implemented in maximum 1 year it becomes deprecated. Again depends on what design type of work we talk about. Some usability issues remain no matter of style changes or features interaction.

Also if the designer sticks when the time comes he might not like the proposal he made that much. As designer we always evolve and think of newer / better solutions (again depends on the type of design).

So I don’t think there is much you can do. It’s the designer’s decision. What you can do is make sure you’ve covered all the areas you needed design help with.

I guess depends also on the design proposals. The designer could also try to adapt to propose things that are easier / simpler to implement and take consideration of the development capabilities. Some design issues can be fixed in multiple ways. Also sometimes the designer can just try to fix the usability problem and leave the styling for a later redesign (again depends on the type of design we talk about :slight_smile:

2 Likes
4

@simonv3 I agree with @evalica and I suspect this happens all the time, and not just in FOSS, in all software. I produced much more for Yocto Project and OpenEmbedded than the team had capacity to develop.

In my case, that didn’t upset me at all: I think it comes with the job. I learn from every single design piece I do, so although it was nice to see things built, the learning made it all worthwhile independently of implementation.

I filled any gaps as @evalica did: taking on other complementary activities. I did a lot of research with users, and also got involved in development, documentation and community work. The latter was my way of trying to solve the capacity issue: if I wanted my designs to be built, a way of working towards that was encouraging more developers to contribute.

I think research activities could be a very productive way of keeping the designer engaged, while doing work that will be useful to the project.

Good luck!

1 Like
5

I’m going to take a different view from the other comments and argue that your poor designer is wasting his/her time. They could be making other projects better. There is some statistic floating around about the percentage of code that never sees the light of day, and research and design is meant to reduce that. I would hate to see design fall in to the same trap as unused code. So, what prevents wasted design? Research and project management.

Knowing the relative value of your tickets/issues, you can be more efficient with your resources. Also, by considering all your stakeholders (devs, end users, designers) when prioritising tasks, you may find that the new interface adds more value than a library update. If not, then at least show your designer how the library update is adding value to the user, even if it is in the long term. Better yet, get your UXer to impartially balance the benefit of bug fixes etc with their shiny new interface and they will realise for themselves why their interface is on hold.

1 Like
6

Are there parts of the designs that actually can be easily implemented without huge resources? While I’m all in favor to see design holistically, incremental changes are often the practical way to go, and something like 10% dev time can be 50% design improvement.

7

Thanks for the thoughts all!

Of course, it’s open source after all :). And yeah, the context is OpenFarm. Here’s an example of the awesome designs made by Sophia.

I’d be happy for more developers, but it’s a bit of a niche project. We regularly get some contributions, but it’s hard to attract developers to dive in and work on a large thing right off.

I figured I wasn’t unique in this! This is why I wanted to hear people’s opinions about this :slight_smile:

For your two options @evalica I think we’ve exhausted option A, and hopefully option B is not off the table. I’m going to see if I can get Sophia to join this forum and add her thoughts to this thread.

We integrate our design proposal tracking with our general issues, so it makes it fairly easy to get an overview of it.

I appreciate hearing this! I personally use contributing to open source to learn a lot, coding and ux-wise, so I think it’s great to hear that doesn’t end for other, more design-heavy, participants.

:100:

But, what if you don’t have a project manager, or someone with that skillset (or, again, time)? Maybe this is something @RichardLitt can weigh in on with his recently launched maintainer.io.

This is super valid. I think a lot of it - personally - has to do with “What can I get done in the 1 hour chunk of time I have available this evening”. Updating library might seem easier than taking on a design overhaul. Better planning, organizing and incremental design would go a long way to fixing this, which is what you’re getting at @jdittrich. I think we’ve done an okay with that, but might need to get a bit better at it.

1 Like
8

I’m actutely aware of cultural differences, I fear someone taking things out of context …

Native English speaker, I immediately understood that to mean a designer in a saddening situation. “Poor thing”, as might be said by someone who is about to burst into tears at the sadness of it; single word requests - What do you call the facial expression or the state just before bursting into tears? - English Language & Usage Stack Exchange

(Not: a person who produces a poor design.)

1 Like
9

But, what if you don’t have a project manager, or someone with that skillset (or, again, time)?

I would say that communication can help here - but that takes time. Good communication can make it clear what external contributors can do. Project managers are often just coders who have more time to write these sorts of things, though, so I’m not sure that “communication” is actually a valid answer there.

I’m also not sure Maintainer.io is relevant. :smiley: But maybe I am wrong there.

10

@simonv3 would it be appropriate to invite Sophia to join? When I’ve had similar problems (as others have mentioned here) it’s always helpful to hear the “yep, me too” and to have a bit of a moan with design and research colleagues.

Maybe she might welcome a bit of a communal moan with us. :smiley:

1 Like
11

I did invite her :slight_smile:

3 Likes
12

Hi All,

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? ^^

2 Likes