Curriculum Art Guidelines
We work with a small team of designers to produce art to supplement our curriculum. This art can take many forms, from detailed diagrams of a complicated algorithm, to a cartoonish image of a hacker trying to break into a computer like Zoolander. The one thing we want to keep consistent is that all art we add to our curriculum serves a pedagogical purpose. That is, the art should play an important role in explaining the concept to the learner.
Curriculum Developers and Project Managers can request art assets via our ART Board in JIRA. If you are a content contributor, you will need to work through the internal team to get your art requests processed.
This page is meant to give an overview of how the ART board is intended to function. It will outline:
- How to fill out a ticket
- How to move that ticket through the board
- Best practices for working with our designers to get the best possible art assets for your content.
This diagram (click the link to view more closely) shows the life of an ART request as it is moved through the ART board. Use it as a reference to know who is responsible for moving the request forward at each stage of the process.
Epics and Production Projects
Each ticket will be assigned an Epic. These epics map to the production project that the art asset is for. The designers will typically work on a single epic at a time.
Your project manager will work with the Curriculum Operations team to schedule a block of your designer's time to dedicate to your production project. You can find these in the Roadmap section of the ART Board. The length of time each project gets in the timeline is determined by the total number of estimated art tickets for that project.
All tickets for a project should be submitted before your project's dedicated window. If you have concerns about this, please communicate them to your project manager as early as possible.
How to Fill out a Ticket
The best way to get what you want out of an art request, and to minimize revisions, is to fill out an excellent ticket. Here are all the fields that are included on an ART ticket and how you should use them to your advantage.
|Summary||Required||The name of your ticket. Best to use the following naming convention - Name of Course: Name of Content Item - Exercise or Title of Art (Exercise Number if Applicable) If your request is part of a series of requests try to capture that in some way in the summary.||Intro to DevOps: Monitoring - Monitoring Quality (Exercise 5, 2/2)|
|Assignee||Required||Each project will have an assigned Designer. Best practice is for the Project Manager to assign these after the tickets have been reviewed.||@John Doe|
|ART Type||Required||The type of art that is being requested||GIF|
|Due Date||Required||The date the ticket is due. These should fall within the epic time period. If there are a lot of tickets you can use due dates to prioritize or group them. When do you need this by?
Always include this date! This is how art contractors know when to work on something. By default, set your due date to three weeks after creating the ticket (if time allows).
Note: this is the date the FIRST draft will be turned in. Adjust accordingly. The latest due date should be at the end of when the artist is scheduled to work on your project.
|Description||Required||Describe the art you need. Be as descriptive as possible. For most simple art requests, the description is the primary place where you will convey your need to the designers.
This is the place where you will also indicate any text that should appear in the design - Type out any text that should appear, using the case (ALLCAPS, Sentence case, Title Case) that should appear in the final design.
This is the meat of the ticket. ALWAYS err on the side of too much detail. Also include sketches (can be attachments) and try to answer any questions a designer may come up with. Explain technical terms & concepts (and/or the way you want them visualized) when describing details of a request.
|A scene showing a developer and an ops person fighting. On one side, the developer is next to a computer with red text on the screen and the text "Warning: bugs detected!". They are looking angry and pointing at the ops person on the other side. On the other side, the ops person is next to a server which is on fire with wires popping out. They are also looking angry and pointing back at the developer.
The developer says "It's your fault!" while the ops person says "No, it's your fault!".
|Link to Placement on Site||Required||Once you've uploaded the final art asset to S3, added it to the content, and are moving the ticket to Visual QA or Complete, update it with a link to the content with the art.|
|Attachment||Recommended||We highly recommend including a sketch or example of what you want to create.||Sample attachment|
|Inspiration||Optional||Provide a link to a graphic that might help convey your thought|
|Limitations||Optional||Mention things that should be avoided completely in the art and design (i.e. something that perpetuates a misconception)|
|Requirements||Optional||Mention things this art must have (i.e. labels on an axis need to be precise in a certain way or use a specific symbol for something)|
|Form Factor||Required||Where is this art going to appear? Is it going to be in the narrative (1/3 of the screen)? Is it going to be in the image component (2/3 of the screen)? Is it for an article, video, or blog post? This is necessary information so the designer can format the image optimally for that space. Art appearing in a lesson's image component will have different requirements compared to those in the lesson's narrative or in an article
Try to include both the fraction of the screen you want the image to take up and where it will appear. For example "image component - 2/3rds of the screen" or "narrative, inline image, 1/3th of the screen" are both good responses.
|Image Component (2/3) Screen|
- Submit your ART request at least four weeks before it’s due. Submitting art asks as early as possible helps the workflow to keep operating smoothly. Last minute requests may be lower quality because they are being rushed and put an unnecessary level of stress on Curriculum Developers, Designers, and Project Managers. Additionally, the artists are working on multiple projects at once, so they may not be able to jump on your ticket right away. Note: this does not mean submit incomplete tickets as a placeholder. Wait until you have all the information you need so you can submit a complete ticket a designer can start working on right away.
- Don't set deadlines too far in the future (or at launch date). It's easy to forget about outstanding tickets with deadlines 3 months in the future. By default, set your deadlines to 3 weeks after the ticket is created. This should give the designer time to work on the art but also allow for time for revisions and review after the first draft is delivered.
- Set up a meeting to review art tickets and concepts with the assigned artist. It bears repeating! This is CRUCIAL to keeping everyone on the same page, and to keeping the timeline moving without back and forth. Make sure tickets are submitted BEFORE the meeting, so the artists will have time to review what is being asked of them and will come prepared with questions.
- Make sure to copy-edit all text you expect to show up in the art asset before submitting the ticket The artists will copy the exact text you submit in the description. Resolving minor typos ends up eating a lot of artists time, so make sure to get the text you want included correct the first time.
- Be as descriptive as possible Designers can't read your mind, so let's not make them try! Make sure to mention everything you want included in the ticket. Make sure your ticket is accurate! Double check the contents of your request before submitting.
- Avoid subjective descriptions! Be explicit and visual with your descriptions. For example, the description of "a mean man who is very wealthy" is not a good description because none of those adjectives have visual indicators. Instead, a good description would be "a man with angry eyebrows, a scowl, wearing a tuxedo and holding a bag of money."
- Include a picture or sketch! Even if you are not the world's greatest artist, a visual example of what you want can go a long way in helping the designer understand your vision.
- Static assests should be .svgs - the first image that is shared back with you is not the final product The designer will provide a preview image first. Let the Designer know you approve and they will prepare the final deliverable in .svg format. For more complex requests, like web and mobile project requests, the designer will also provide a sketch file and assets included in the design (images, logos, icons).
- Be sure to move the ticket to the appropriate column When a design is provided be sure to move the ticket to the next appropriate column. Revisions (communicate revisions needed), QA (provide a link for QA) or completed.
- Submit all art requests for a project before the artists are scheduled to start working on your course Piecemeal tickets after artists have already started work will gum up the works for other productions and take the focus away from your project in general. Additionally, make sure you ask your project manager to set up some time for you and the assigned artist to talk about the requests for your projects. This should happen AFTER most of the tickets have been submitted but BEFORE work is supposed to start.
ART Tickets with Content Contributors
How and when should I collect ART requests from content contributors? What's the best practice here?
We don't have CCs directly fill out tickets in the ART board, rather, we'd like them to communicate the art requests to you by filling out a ART Request spreadsheet or ART Request Form for your project. Have them fill out this spreadsheet/form at the end of the Outlining phase for every content item.
We want to get these art requests fleshed out and submitted as soon as possible to avoid delays and allow appropriate time for revisions.