Scoping of Graphic, UI, and UX Design Teams for the Design Quality Review Group
Closed this issue · 5 comments
Problem
Currently the team has yet to clarify the design team aspect of quality review for the platform. It needs to be addressed. This is an extension of #44.
Proposal
My proposal is that we make explicit the nature of the groups within the design quality function to identify their respective deliverables, how they might interact with the crowd research community and the other teams, the more common tools used by team members, and ... The teams will consist of both designers and researchers as to be inclusive of the skill sets and fields. The steps of making it explicit will be conducted in google docs for intermediate drafting and the more refined identifications here in this thread. The final concensus of the different sections will appear in the teams governance document posted on Github. Additionally, all members of the design group are considered a part of the same quality review team, and will be identified within a group specialty (User Experience, User Interface, Graphic) or specialties if the group so chooses through nominations to expand the communal recognition of the individual. It is the proposed responsibility of the larger group to maintain the created standards and adjust them to fit changes in awareness and knowledge in practice. The final product from this proposal will be introduced into the groups document here: https://github.com/crowdresearch/collective/blob/master/governance/groups.md
IMPORTANT (#44): The overall quality design team will be responsible for the final wording and maintenance of the document being developed below as well as the nature of the relationship between design and engineering. Their members will be expected to eventually use github to manage changes if they chose to participate in its iteration. Only under conditions that are warranted under increased workloads, will this team break into sub-teams of Graphic, UI and UX. The threshold will be determined during the execution of the next cohort (i.e. basic variable threshold will be quantity of proposals submitted within a domain).
To minimize power struggles, each member will be able to serve on the teams at most once and for a period of no longer than 6 months. After this period of time the person will be recognized for their service and be expected to defer requests for help to the current quality review group.
Implications
The major benefit for this group is clarity on what the different roles are within the research group. This clarity will assist members of the on board group to be able to expect specific expertise and guidance from the team members in such as way as to avoid nonsense as well as enable potential future members to wisely self select themselves into their own professional domain.
Examples of the segmentation is as follows:
##Design Quality Team
Members
Jane Doe, Graphic
James Smyth, User Experience
Le Phoung, User Interface
Graphic Team
Graphic creates and iterates the assets and collateral that establish the identity of Daemo across media and technology. To members of the community, the members of the quality review team that are identified as members of the graphic group become the mentors and teachers of the community about the Material Guidelines and that presentation materials adhere to Daemo’s style guide. They help to guide members in the development of graphic assets for conference presentations, submitted publications, and the software visual look across phones, laptops, desktops, and other media devices identified by the User Experience team. These members are responsible for maintenance and submission of the graphics to github, as well as maintaining a components library of icons, logos, etc. from 3 competitive platforms on the Crowd Research Wiki.
Deliverables: graphic re-draft, written feedback to members submitting graphical changes to the team, wire frames and mock ups across media and devices, written validation of developed media to the Daemo standard and other relevant standards required by ... Pixel Perfect Daemo Resources.
Collaborative Tools used by members: Figma, Slack, Github...
User Experience
The User Experience group within the Design Quality Review Team focus on the Human Behavior aspect of the platform. They define the work models and the general UI specifications. As an outcome of their emphasis on human behavior, this team maintains relevant scenarios, heuristic evaluations, personas, interaction models and wire frames to communicate with stakeholders. In Daemo, these presentations are often email exchanges or REDDIT forum presentations with workers in their preferred forums. This team uses statistics and appropriate research methods to inform and shape the the platform to meet the needs of its workers, requesters, and researchers. In interactions with the research community, this team reviews proposals and makes contact with workers and requesters upon their behalf. This team will be maintaining a major scenario library considering 3 competitive platforms on the Crowd Research Wiki to demonstrate the differences between them.
Deliverables: work interaction models, research method review and written feedback, experimental analysis review and written feedback, click through prototypes, questionnaires, academic article suggestions, support with the community as needed, mentoring as needed, priority alignment with the larger quality team, user requirement specifications, user cases and scenario library
Collaborative Tools: Figma, Slack, Google Drive, CoLab, UX component library (behavior patterns of users)...
User Interface
The User Interface Group focuses on the pages and screens of the Daemo Platform. They will conduct research to optimize the pages of the platform to match the work priorities for the users as well as designing the information path to assist users to achieve their tasks successfully. Results for platform studies are posted with the appropriate Github Issue thread with the research and analysis methods and final results from the related study. The Ux Group will inform the UI group with validated scenarios, whereas the task flows are their responsibility. They maintain the current style guide and the site's design language. With assistance from the Ux group, they will suggest further notifications and alerts to support users on the platform. This team will maintain a design pattern library from 3 competitive platforms on the Crowd Research Wiki.
Deliverables: mock ups, design patterns, template layouts, internal reports and studies, provide written feedback to members on related proposals...
Collaborative Tools: Figma, Slack, Google Drive, CoLab, UI component library...
Weakness to note: the transition members who handle the front end are not in this group.
Use comments to share your response or use emoji 👍 to show your support. To officially join in, add yourself as an assignee to the proposal. To break consensus, comment using this template. To find out more about this process, read the how-to.
Please feel free to edit the beginning document directly.
This conversation is locked to only commenting, since this is the initial starting point and any revisions will need future proposals.
This change need the revision
Could you edit the description and focus on the quality review process for each of these sub groups you have added?
The description listed above highlights generic functionalities, which any member should be able to perform. However, the quality review duties are different and it would be good to specify them.
Can you update the proposal content and commit to reflect the spirit of Cascade governance i.e. community oriented decision making with no centralized control or leadership of any sort.
Thanks!
Neil. It achieved consensus. As a result it is a part of the group's documents and now must go through the revision process. 9 days and my attempts at direct participation did not attract any changes; the breaking of consensus occurs at this time. If you have recommendations, please write a new proposal building off of this one to follow the constitutional proposal process.
How far are we going to require the groups to go? Verification, validation, reviewing, auditing are the key practices for which these is come by. The members of the groups will need to compare/contrast the Daemo platform for defects or inconsistencies between the proposals and provide feedback to that effect. Would you agree with this?