Tracking System for Job Applicants Sprint Schedule and Overview. By Erik Flowers

Transcription

1 Tracking System for Job Applicants Sprint Schedule and Overview By Erik Flowers This overview is to determine and develop the Tracking System for Job Applicants (TSJA), to be used by Recruiters/Managers and Employees. Low-fidelity overview of product and one high-fidelity interaction will accompany this schedule. 12 Week (3 month) Schedule and Overview, UX and Development cycle. 6 UX Sprints. Week 1 Sprint I (one week) Determine needs for primary stakeholders/users. Week 2-3 Sprint II (two weeks) Usage and User Research Week 4 Sprint III (one week) Initial Flow-Charting and Scope Defining Week 5 Sprint IV (one week) Wireframing and View Creation Week 6-10 Sprint V (five weeks) Prototyping and Development, User Testing Week Sprint VI (two weeks) - Testing, Staging, QA, User Testing, Delivery Week 12.1 (one day) Post Release Meeting UX Sprint I Determine needs for primary stakeholders/users. A. Gather requirements and needs. Open ended and non-limiting. a. Make list of users and stakeholders, using both existing declarations of involvement, and assumptive invitations of people that the UX team feels are relevant. i. Schedule meetings and planning sessions to gather data and make notes. ii. Meetings can be split between parallel UX personnel or teams, merging information together in virtual branches. b. Interview recruiters/managers on existing tools, existing application screening processes, current state of usage and perceived effectiveness. i. If no format system exists, document the offline/analog process currently in use. ii. Posit a scenario to users of an application-like system for accomplishing existing, segmented tasks regarding job applicant tracking. c. Interview recruiters/managers on existing problems, shortcomings, missing features (relevant or not), and perceived ineffectiveness of existing system. i. If no system exists, follow same above items in A.a.i and ii. d. Gather information about wants/needs from recruiter/manager user, realistic or not. B. Compile list of needs and wants into an un-ordered list. a. Planning poker to determine where the UX team feels the priorities should be.

2 UX Sprint II Usage and User Research A. Compose list of possible research and data gathering techniques, decide which fit the schedule and existing resources a. Surveys, individual user studies, single interviews, group interviews, subjective observation of user. b. Once determined based on time/resources, proceed to utilize techniques in the observation and research process. B. Observe usage of user; note the obvious and nuanced interaction patterns. a. Rely on standardized practices to make note of observed behaviors i. Tap in to experience and intuition as a UX practitioner ii. Make educated guesses and assumptions, for later review against gathered data and notes. b. Screenshot/annotate existing UI and annotate existing interactions, experience, and pain points in the process. i. If no formal process exists, formalize existing process as best as possible. c. Heuristically contemplate and brainstorm on potential uses and problems from an outside standpoint. Make assumptions based on past experiences and known practices. d. C. Organize usage observations and patterns into spec-sheet for UX team. a. All team members contribute to initial spec sheet, and will refer and edit this sheet and project advances. b. Planning meeting between UX team to merge notes, and commit to initial product requirements sheet. c. Move forward with initial requirements sheet into sprint III. UX Sprint III Initial flow-charting and scope defining A. Meet at the biggest whiteboard available with involved UX team members and begin abstraction of the data gathered. a. This is not view wireframing. This is a visual map of the project as understood so far by the UX team, and a backlog of existing requirements and needs gathered. b. Process is collaborative and non-discriminating against any ideas or insights by the UX team. B. Sitemap (project map) of potential and needed views (screens, pages) determined and linked. a. Map links together interactions and the flow of the user experience as the user navigates through the product and accomplishes the needed tasks. i. Map elements that are actual discrete views will correspond to a UI wireframe

3 C. Planning remaining development strategy and benchmarks a. Determining resources and timing needed for following 3 sprints. b. Divide responsibilities between UX tem i. Interaction design ii. UI design, asset library iii. Persona and user modeling UX Sprint IV Wireframing and View Creation A. Views are taken from flow chart and site/project map and wireframes are started. Locate the biggest whiteboard you can find. a. Initial view wireframing takes place with one or more members (if available) from the: i. UX Team ii. Project Managers iii. Software Developers iv. User Group (since this is for recruiters, managers, and employees it is assumed that some/all of those users will be available). b. Wireframes are drawn in front of everyone on the whiteboard i. UX controls the drawing process using the elements and information they have already gathered. ii. Other non-ux attendees will be solicited for feedback and initial reactions. c. The whiteboarding session wireframes will either be drawn in tandem by a UX team member, or photos of the whiteboard will be taken and sent to the UX team members. B. From the whiteboard notes/pictures, wireframes of the views can be created. a. Wireframing into a digital format takes place within the UX team, staying close to the initial whiteboard (or sketch). b. Wireframes are drawn up in digital format with annotations, comments and markup. c. Wireframes can be printed and re-evaluated by UX team, with new annotations and comments based on team suggestion and known factors. C. Wireframes are reviewed and confirmed by the UX team a. Wireframes can be shared with development parties, software engineers and programmers, and the development manager or director. b. Software/programming developers receive the initial wireframes so they have something to start with, and can begin building backend functionality and models/controllers of the MVC. D. Expectations on delivery are set a. Input from software developers and creative is taken into account to determine the iterative benchmarks for the next sprint.

4 UX Sprint V Prototyping and Development, User Testing A. With wireframes in hand, UX team takes them and begins constructing prototypes a. Prototyping will consist of i. Overall design framework of product ii. Developing a consistent, hi-fidelity UI library and asset iii. Determining which interactions need to be made into clickable prototypes. 1. Flat images, simple clickable HTML (illusion of function), advanced jquery-enabled views, interactive mockups from Catalyst or similar program. b. Prototypes will receive constant iteration between the UX team and an involved representative from the software development team. i. Developers will need to know about the granular addition of interactions and features that will require backend programming and consideration, database work, and other changes/additions to the model and controller. B. Prototypes presented to stakeholders/users as an alpha demo a. While not a deliverable product, a reasonable presumption can be made that the project is within the scope and planning that was originally determined and set out with. b. Last minute changes or considerations can be suggested, but without a promise that they will be included with the first working release. C. Developers are working in a delayed, parallel production cycle, integrating UX and UI elements as they are created and have initial approval from the UX team. a. Developer needs and questions are addressed from the UX team, with the assumption that the UX team has a handle on what needs to be accomplished and included in the feature set. D. As prototypes or basic live demos are available, they are shared with a small portion of users to determine if there are any oversights or glaring omissions. a. Notes can be taken if any new requests/needs/wants arise from users, and evaluated for present inclusion, or if they need to be backlogged for the next release cycle. E. Creative assets are integrated with the UI and application screens a. In this instance, it is assumed that creative is a part of the UX team and capable of delivering the needed UI and creative elements. F. Deliveries from the software engineers are QA s by the UX team and a constant feedback loop is going between the software developers and the UX team. UX Sprint VI Testing, Staging, QA, User Testing, Delivery A. The initial, usable product is pushed to a staging environment. a. Tests of the working product begin with the UX team

5 b. QA is conducted on working product, by UX team or uninvolved, unbiased QA representatives. B. User testing is planned a. Primary users are selected and invited to test and use the initial release candidate i. Notes and observations are taken by the UX team on how the user interacts and responds to the product. ii. Resembles a compressed version of Sprint II Usage and User Research. b. Observations are made by UX and compared to the initial flow chart and site-map of the project. i. Fixable, non-loadbearing feature changes can be made ii. Loadbearing features that fit the original, planned development requests will remain as they are, with any user feedback that requires change saved for the next UX and development cycle. C. QA is completed, bugs and errors are fixed, and a release candidate can be tested with users. a. This final testing is the point of no return for this cycle. The 12-week product will be released at the conclusion of this sprint. b. One final look from the users, developers, and UX team is given to the product. i. Notes and ideas are recorded, but not introduced into the scope. No feature creep is allowed at this point. D. Delivery a. The TSJA (Tracking System for Job Applicants) is released to the users on a conditional 1.0 basis. b. The delivery is feature complete in accordance to the original and revised plan. Post Release Meeting A. Evaluation of process and delivery a. UX and Developer consensus of success, areas to improve b. Prioritization of features that were lacked, skipped, or non-loadbearing and left out of first delivery. B. User observation a. Essentially a micro-iteration of entire process. i. UX note taking ii. User feedback iii. Evaluation C. Discussion of 2 nd release candidate (if needed, planned, requested).