Job request process

•

How might we make graphics services easier to procure?

The gist

The in-house graphics team job request system was opaque, complex, manual and independent of other systems in the organisation it needed to interface with. I pitched a more useable form to the team that would capture the data they needed, communicate what stage each project was at, and connect into existing systems for a smoother workflow. The resulting process has met those aims, and provides additional benefits: improved depth of information captured, a more robust job tracking system and facilitated data gathering for improvements in team resource allocation and future planning.

Key skills used:
* Project planning and implementation (identification of stakeholders, current process mapping, content review and consolidation)

* Design prototyping (low and high fidelity)

* Testing (site analytics, contextual enquiry)

* Workshop design and facilitation
* Project planning and reporting
* Stakeholder management (team liason and internal communications)

Process

I began by interviewing the graphics team about the existing job request process, and mapped this out visually to view the whole system at once. I reviewed the contents of the three existing forms with the graphics team, identifying with them what needed to stay and combined that into a single form.

Early process and content scoping.

I work shopped the form field functions and process with the IT department to scope out our first digital prototype. I also liaised with the finance team to understand their system requirements and define how our form would fit into that. We tested the form in-situ on individuals within the graphics team at first. As our iterations improved, we expanded the test group to the whole graphics team, our key client group and the whole institute.

The form was available in beta form to the whole institute and was soon to be fully launched, but something wasn’t right. Clients were using the form, but our heaviest user group were providing less and less information, or trying to circumvent the form process entirely. A few informal one-on-one interviews revealed to me that the form’s fields were acting as a barrier: they didn’t match our user’s thought process when making a request. I hadn’t questioned the form fields deeply enough when we began working, and I hadn’t included users early in the process. I’ll do this sooner next time.

I facilitated two workshops with graphics team members, heavy users and IT to explore how we all viewed the requisition process. We discovered that users expressed and organised information differently to the graphics team, which lead to misunderstandings. We identified the key pieces of information needed for a request, and prioritised their appearance in the form with a card sorting activity.

Co-designed questions and their order in the form, developed during the team and user workshop.

I created a paper prototype of this new form and tested it in-situ against some key user groups, similar to a design sprint. Several iterations later, and it was ready to prototype in digital form.

Testing the form prototype. Once complete I photocopied the responses, then cut into the form to make quick iterations.

The solution

The form has replaced the previous requisition system. The change has been introduced smoothly due to rigorous testing and the use of several touchpoints of internal communications including face-to-face meetings. Users have reported the system to be easy to use. The graphics team are supportive of the change and benefiting from consistent and more complete briefing information. Manual entry has been removed at the cost-recovery stage and data from the system is influencing resource planning.