Challenge Summary
Welcome to [serenity] New Challenge Requirements Builder Design Concepts Challenge. We are currently running a challenge to redesign the overall Challenge Creation flow for [topcoder] (at least, for one specific challenge type). A step in that process is one for the definition of project requirements. We feel that step may be amongst the more complicated of the steps in the process.
In this challenge we are looking for DESIGN CONCEPTS on how this could work. What should the user see and experience?
Round 1
For your R1 deliverables please submit the following screens:
1. Requirements Builder Section
- Readme.jpg : Provide notes about your submission.
- Make sure all pages have correct flow! Use correct file numbering. (00, 01, 02, 03)
Round 2
Final Design plus any Checkpoint feedback
1. Requirements Builder Section final design
- Readme.jpg : Provide notes about your submission.
- Make sure all pages have correct flow! Use correct file numbering. (00, 01, 02, 03)
Challenge Details:
The primary goal of this challenge is to focus on project requirements step and what should be presented in it when creating a challenge.
We are looking for the [topcoder] design Community to help us and show us a variety of approaches to making it simple and engaging.
Supporting Document:
- Appirio Application Framework (Storyboard.zip); use it for branding guideline.
Design Considerations:
This interface should work within the larger process of Creating a Challenge that is embodied by topcoder challenge New Challenge Creation and Launch Design Challenge. That challenge describes a single-page, scrolling form for creating/describing a new challenge. This UI will end up being but one section of that larger experience. Please try to design it as modularly as possible, so that it will scale gracefully to fit within that large experience.
Required Screen Size:
- Desktop page of size 1024px width and height as required.
Data Model for a Requirement:
Users will use the interface to create Requirements. A complete requirement has the following data elements:
Body:
- Text field, Max. 400 characters
- This field contains the written description of the requirement, in as much detail as the Challenge Author chooses to provide.
Type:
- Requirements may be one of 3 types:
-- Functional - what it does (eg. “Include a search box.”); this is the default type
-- Technical - how it does it (eg. “Use angular.js.”)
-- Informational - useful information that may not affect scoring (eg. “First, grab the source repository from github/foo/bar”)
Importance:
- A range of values from 1-4:
-- 1- Critical to have. Submission will fail scoring if this is not present.
-- 2 - Important. Submission that satisfies this requirement has a better chance of besting competitors.
-- 3 - Desired. Submission may omit this requirement, but will fare poorly against competitors that include it.
-- 4 - Nice-to-have. Submission will garner good will by accommodating this request, but will not be punished for omitting it.
Tags:
- Array of plain-text tags.
- A requirement may have a number of Tags, provided by the user, that describe the content of the requirement in a tokenizable, cross-queryable way.
-- Ex. a set of tags for a requirement could be: {“css”, “bootstrap”, “front-end”}
Challenge Requirements:
- User can create requirements using the interface. There is no upper limit on how many requirements a user can create, but ~16-20 requirements is the reasonable upper boundary for what the interface should accept.
- The interface should feature some kind of complexity indicator (a scale, or an adaptive graphic) that indicates to users the overall complexity of the set of requirements. There is an example of this in the wireframe provided, but feel free to improve upon this basic concept.
- The purpose of the Complexity Indicator is two-fold: (first) it should discourage users from providing too few requirements for a challenge (fewer than ~3-4); (second) it should give users an idea when the number of requirements they’ve listed has gotten quite large (> 10) which may indicate a fairly complicated challenge.
- User can create arbitrary sub-groupings of requirements in the list. For example, in a list of 12 requirements, user may choose to identify the first 4 as falling under the heading of “FOO”, the next 6 under “BAR” and the final 4 under “BLAMMO.” User does not have to use groupings for requirements — they may opt to leave their whole requirements list for a challenge as an unordered list.
Target Audience:
- Customer technical resource
- Customer non-technical resource
- Appirio consultant
- Appirio management
- Appirio [topcoder] expert services resource
- [topcoder] co-pilot
Judging Criteria:
- How well you plan the user experience and capture your ideas visually
- Cleanliness of your graphics and design
- Your design should possible to build and make sense as a mobile application
Submission & Source Files:
Preview Image
Please create your preview image as one (1) 1024x1024px JPG or PNG file in RGB color mode at 72dpi and place a screenshot of your submission within it.
Submission File
Submit JPG/PNG for your submission files.
Source Files
All original source files of the submitted design. Files should be created in Adobe Photoshop and saved as layered PSD file, or Adobe Illustrator as a layered AI file.
Final Fixes
As part of the final fixes phase you may be asked to modify your graphics (sizes or colors) or modify overall colors. We may ask you to update your design or graphics based on checkpoint feedback.
Please read the challenge specification carefully and watch the forums for any questions or feedback concerning this challenge. It is important that you monitor any updates provided by the client or Studio Admins in the forums. Please post any questions you might have for the client in the forums.