-
Notifications
You must be signed in to change notification settings - Fork 45
design
Hello designer! We're excited to have your help envisioning changes or new features to Wordplay.
Here's the flow of design work we expect you to follow:
Before you do anything, complete everything in the contributor guide before starting design work. Don't skip any steps, don't skim. Read every word and make sure you do every task. (Many designers skip things, and then we have to tell them to go back and read more carefully.
Wordplay has an ever growing set of issues. All of the issues tagged needs design are ones that need design work. (There may also be some missing that tag, but also in need of design work. Some are tagged enhancement, which means they are new features that could be added to Wordplay. Others are tagged defect, which means there's something broken that needs a redesign. Issues that are in the 1.0 backlog are the highest priority. Of course, there many design opportunities in Wordplay that aren't yet issues. If you have an idea for a new feature or an improvement, create a new defect or enhancement issue, and we'll review it to see if we should include it.
One you've chosen a needs design issue that you'd like to be responsible for (or created one yourself), assign yourself and comment on it the issue, explaining that you'd like to work on it, so everyone knows why you're assigned. Note who else is assigned and coordinate with them on the issue. If you're not also acting as the issue's developer, you may want to find a developer to collaborate with, so you can design around engineering constraints.
Find the other people who've contributed to it, or even the person who suggested it, and start doing research. What problem is it addressing? Should the problem scope be larger, smaller? Who's needs would it address? Capture all of this in the main body of the issue (not a comment), and revise it as you learn, so there's clear documentation about the need. Make sure you understand how any existing Wordplay functionality works in depth before you redesign anything.
One reasonable part of research is engaging with stakeholders (e.g., youth, teachers). If you want to do this (and for most design issues, you should), do not go rogue: consult with the leadership team about how. Talking to youth requires careful planning, talking to teachers requires careful consideration of their limited time, and talking to partners such as not-for-profit organizations requires long-term planning of professional communication and engagement. Do not take any of these kinds of outreach lightly; even a single poor interaction with a person, community, or organization and permanently harm our ability to learn with communities. That's why we manage these relationships centrally.
If you are enable to talk to stakeholders directly, study other existing research on the topic, learn from online communities that discuss the issue, and consult with the leadership team for suggested resources. There's a lot of knowledge in the world that can be gained about a problem. (If you're an Informatics student, INFO 300 Research Methods is the best preparation for this work.)
As you research need, you're going to generate concrete ideas. Your job is to envision concrete designs or redesigns that address the problem, and capture them in the GitHub issue's main body text (not a comment). Include any sketches as images with descriptions.
Do not link PDF. PDFs are not accessible to people who use screen readers without significant effort, and so anyone trying to read your design with a screen reader will not be able to. Do not link to external web links, as links bit rot and have permissions barriers. Everything must be embedded as accessible text and images in the main body of the issue.
When you have a design sketch, consult with developers (including Amy) on the feasibility of the design. They may have perspectives on what is and isn't possible, or questions that your sketch does not yet answer.
When you have a design ready for review, tag Amy for design review.
Iterate with her until you get her blessing; once she approves, she will remove needs design and add the tag buildable, which signals to developers that it's ready for engineering.
See if you can recruit someone to collaborate on it with, and if you succeed, collaborate with them to ensure that it meets your vision. This should be a collaborative process, not something that you toss over to engineering; regular communication and testing is key, as you may need to revise your design as constraints and feasibility become more visible. A successful design project will ship the feature, and end with a high five between designers and developers.
Your job is done when either 1) you and a developer have submitted a pull request that is successfully merged into the main branch, or 2) you can't find a developer to work on it yet.
Once you're done, move onto another issue!
Do you find something confusing on this page? Submit a maintenance issue, so we can improve it.