On how to drive and 'manage' volunteers for your Open Source project
On how to drive and 'manage' volunteers for your Open Source project
> With software it’s clear: when you don’t have programmers, you don’t get a computer program. But when a team is employed to develop a product without designers, a design gets made nonetheless. Accidental design. Bad design, most likely. But with no designer around and no one listening to users, the client is not going to notice.
(...)
> Great design isn’t done by picking up a tiny issue and creating a solution for it. It’s done by gaining deep understanding for the problems people have, the context in which they use products and by testing solutions with people. It’s labor-intensive and requires people who are engaged with their users over long periods of time.
(...)
> In volunteer-to-volunteer situation, they just have to hope someone feels like doing it. If the frontend developer is like, ‘Yeah, but I like it the other way’, designers are shit out of luck.
> With software it’s clear: when you don’t have programmers, you don’t get a computer program. But when a team is employed to develop a product without designers, a design gets made nonetheless. Accidental design. Bad design, most likely. But with no designer around and no one listening to users, the client is not going to notice.
> (...)
> Great design isn’t done by picking up a tiny issue and creating a solution for it. It’s done by gaining deep understanding for the problems people have, the context in which they use products and by testing solutions with people. It’s labor-intensive and requires people who are engaged with their users over long periods of time.
> (...)
> In volunteer-to-volunteer situation, they just have to hope someone feels like doing it. If the frontend developer is like, ‘Yeah, but I like it the other way’, designers are shit out of luck.
> With software it’s clear: when you don’t have programmers, you don’t get a computer program. But when a team is employed to develop a product without designers, a design gets made nonetheless. Accidental design. Bad design, most likely. But with no designer around and no one listening to users, the client is not going to notice.
> Great design isn’t done by picking up a tiny issue and creating a solution for it. It’s done by gaining deep understanding for the problems people have, the context in which they use products and by testing solutions with people. It’s labor-intensive and requires people who are engaged with their users over long periods of time.
> In volunteer-to-volunteer situation, they just have to hope someone feels like doing it. If the frontend developer is like, ‘Yeah, but I like it the other way’, designers are shit out of luck.
>Software doesn’t become user-friendly by accident. So before you have code written, you need a plan.
> 1. You need to think beyond your own needs.
> 2. You need methods to get good feedback, because describing a project to people new to your project is hard and probably requires several iterations.
> 3. You’re not going to get this right on your own: you need people to provide feedback and you need people who can write well, translate and present it visually.
> Even if the hands-on design work would be covered by volunteers, we need someone to make sure that it all comes together. That all that work has unity and consistency within and between products. And that there’s a bit of quality assurance.
> Often software starts with dogfooding founders, with features that solve their personal problems.
> Define your vision and mission. Write a manifesto! Inspire people with exciting words.
>Software doesn’t become user-friendly by accident. So before you have code written, you need a plan.
> 1. You need to think beyond your own needs.
> 2. You need methods to get good feedback, because describing a project to people new to your project is hard and probably requires several iterations.
> 3. You’re not going to get this right on your own: you need people to provide feedback and you need people who can write well, translate and present it visually.
> Even if the hands-on design work would be covered by volunteers, we need someone to make sure that it all comes together. That all that work has unity and consistency within and between products. And that there’s a bit of quality assurance.
> Often software starts with dogfooding founders, with features that solve their personal problems.
> Define your vision and mission. Write a manifesto! Inspire people with exciting words.
>Software doesn’t become user-friendly by accident. So before you have code written, you need a plan.
> 1. You need to think beyond your own needs.
> 2. You need methods to get good feedback, because describing a project to people new to your project is hard and probably requires several iterations.
> 3. You’re not going to get this right on your own: you need people to provide feedback and you need people who can write well, translate and present it visually.
> Even if the hands-on design work would be covered by volunteers, we need someone to make sure that it all comes together. That all that work has unity and consistency within and between products. And that there’s a bit of quality assurance.
> Often software starts with dogfooding founders, with features that solve their personal problems.
> Define your vision and mission. Write a manifesto! Inspire people with exciting words.
>Software doesn’t become user-friendly by accident. So before you have code written, you need a plan.
> 1. You need to think beyond your own needs.
> 2. You need methods to get good feedback, because describing a project to people new to your project is hard and probably requires several iterations.
> 3. You’re not going to get this right on your own: you need people to provide feedback and you need people who can write well, translate and present it visually.
> Even if the hands-on design work would be covered by volunteers, we need someone to make sure that it all comes together. That all that work has unity and consistency within and between products. And that there’s a bit of quality assurance.
> Often software starts with dogfooding founders, with features that solve their personal problems.
> Define your vision and mission. Write a manifesto! Inspire people with exciting words.
>Software doesn’t become user-friendly by accident. So before you have code written, you need a plan.
> 1. You need to think beyond your own needs.
> 2. You need methods to get good feedback, because describing a project to people new to your project is hard and probably requires several iterations.
> 3. You’re not going to get this right on your own: you need people to provide feedback and you need people who can write well, translate and present it visually.
> Even if the hands-on design work would be covered by volunteers, we need someone to make sure that it all comes together. That all that work has unity and consistency within and between products. And that there’s a bit of quality assurance.
>(...)
> Often software starts with dogfooding founders, with features that solve their personal problems.
>(...)
> Define your vision and mission. Write a manifesto! Inspire people with exciting words.