After yesterdays post from team 2 on their thoughts about an ideal crowdsourcing program, we conclude this phase with the combined post of team 1 & 3 of our crowdsourcing project teams.
Introduction
This is our suggestion for a future Design Challenge program. With our proposal we aim for supporting people who want to create new and exiting designs for applications or web services. We support bringing in high quality input, concentration on the design of interactions. We help to give each other valuable feedback.
Process
During the whole process Mozilla staff supports the participants via regular chat sessions and by giving comments and help. Special events like webinars are highly valued by participants. If we have the possibility to do them they make the most sense in the research phase.
Pre-Challenge
The process starts with project suggestions by Mozilla: A list with possible topics for the next challenge is posted on the Mozilla webpage a sufficient time before the actual challenge starts. Everybody who comes by can vote for the topic selection. The best scoring project is selected to be the next challenges topic. We do this in order to involve the community early in the process to create commitment and prevent challenges to be selected that don’t attract participants. It is also important to do this step to guarantee that the topics proposed are truly relevant to the development of different projects in Mozilla.
General Setup
The registered participants can participate in the challenge. The work’s results during all process phases will be collected and worked with via our future design challenge website. We decided to structure the process into phases. This gives structure and encourages continuous involvement. Also creates a mental-model of how the whole process works (from 0% to 100% completion). Each phase has a deadline. After its passing, the possibility to upload material for the next phase is unlocked.
Research
The first phase in the challenges will be research. In the step the participants gather resources on the challenge topic: Weblinks, own findings from interviews, other products that have a similar purpose etc. It can be voted on the usefulness of resources. This first step gives a good base for the design process and makes the final proposal to be developed more professional. Mozilla can even create its own repository for design material or a design guide (similar to the Nokia Forum resources).
Idea Gathering
The next phase will be idea gathering: The community gathers ideas and inspiration on how the problem can be solved and user goals met. Like in the research phase everything goes into a common pool that is available to everybody on the platform. Teams are best formed in this phase. We support this by providing the possibility to assign ones name to a idea. So if a group of people likes the same idea(s) they can form a team if they want.
Design Phase
After the idea gathering ended, the work on the final designs will start. People can do this either alone or in teams. Each team or person will have their own space for working on their ideas. Other people still can view the uploaded mockups and can comments on these. Besides of comments there is the possibility to vote on different aspects of the designs like efficiency of use, utility and ease of learning.
A common problem is that polished graphics displace the focus on interaction. (see Don Normans Essay on Design Competitions). Since simple sketches like balsamique-mockups are effective for demonstrating the interaction-design ideas, the sketch-style will be the form in which contributions will be submitted. This could be encouraged by making a descent mockup-tool available for participants.
Evaluation
The best concepts are selected by a jury formed by Mozilla staff and “external” people e.g. from organizations or universities. A short and objective profile about these people are posted from the very beginning of the challenge. The evaluation needs to be written in a way that allows participants future improvements if they want to carry on with their ideas.
Between Challenges
In between the challenges ideas from the previous challenges can be realized. For people who want to do so, contact to the add-on community would be provided. The platform can still be used for further improvement of the ideas.
As the community carries on between the challenges winning awards is not the only possibility to get recognized: if a team archives great results after the challenge has passed there is still the possibility that their project could be e.g. featured on the Labs blog, and it is possible to get the staffs’ feedback on these concepts.
In case it makes sense for the UX-Team the community could participate in some “real-world” tasks like finding out a way around minor certain problems in the GUI. People will feel valued and the team could get new solutions.
Voting and Rewards
It can be commented and voted on all submissions in all phases. A common problem is that voting up/down does not give any help for future improvements. Because of that our wording will be more specifically and voting possibilities differentiated: comments can be marked as “helpful” and ideas and concepts are valued with up-votes on “ease of learning”, “efficiency” and “utility”. The wording prevents voting without meaning. The different categories for the concepts allow to see whether oneself meets the usability goals one wants to archive.
We want to encourage collaborative work, not a strong competition. So the participants don’t get a score on how good they are. Instead they get a kind of pie-chart, showing what they are good in. This prevents people getting asked all the time (high score) or never (low score) for feedback or being in a team. Others can look as well for somebody who is good in a certain thing to form a balanced team or get feedback on a certain topic.
Participants are rewarded with badges. They are mainly a motivator for individuals and not replacing the points in a kind of way that “many badges people” are perceived as “better people”.