Client UX Process

I was asked to create and document a flexible UX process that could be tailored to use for large-scope projects, but also be easily reduced for use in much smaller projects.

After discussion and approval in-house, this process would be fully documented in the client's knowledge base.

THE BRIEF

The client already had an existing UX process, but they contacted me because, having recently completed a diploma with the UX Design Institute, I had up-to-date knowledge of the most recent parts of the process. I was to look at their existing internal processes and use my knowledge to bring their UX process up to recent standards. I would then document this in their knowledge base.

SOLUTION

After reviewing their existing processes and recent projects, I realised they needed a flexible UX process that could be tailored to the size of the project easily and quickly.

I kept elements of their own processes – some of which were not strictly UX-related – and organised the UX process into their internal 'sprints'. Finally, the documentation was written up and submitted.

‍

INVESTIGATION

The client's UX/UI process was divided into three 'sprints' – one for research, one for analysis, and the final one for prototyping and testing. When I looked at the way tasks were split up between these sprints, it came to light that some tasks were being scheduled too late in the process, with not enough time to complete them successfully; some other tasks relied on the outcome of tasks that were scheduled in the following sprint.

At the end of the second sprint, the client always scheduled a client-facing workshop to present findings and suggested solutions – unfortunately, it became clear that the expected outcomes from the workshop were not well defined and, on some occasions, the workshop was run even when the scope of the project had already been established. Because of this, the clients weren't invested in the workshop itself.

‍

THE UX PROCESS

My first task was to define a 'modern' UX process and fit it into the client's sprint architecture. To do this, I expanded their three-sprint schedule into a five-step process, including pre-project tasks, internal and client-facing kick-off meetings, and separating the workshop into its own stage.

At this stage, I reorganised the tasks, moving time-sensitive tasks earlier in the process, especially when later tasks relied on the generated data. As all of the client tasks were tracked internally, it was also necessary to put time estimates against every stage.

Although most of the tasks were assigned to a UX Designer in a research position, I also had to reassign some of them to a UI Designer and also to a development team.

All of this initial work was done in Figjam, as it allowed quick changes, flexibility, and collaboration with the team members involved.

‍

APPROVAL

Once the development was completed in Figjam, I carried out a number of one-to-one stakeholder meetings to determine whether any further development was required. At this stage, I was given approval to begin documentation.

DOCUMENTATION

The knowledge base documentation would be for reference by the entire company staff, so it needed information on what each task was, which order they went in, and any information that might have been relevant.

I wrote all of the documentation in Google Docs, which was passed to the studio manager to be entered into the online knowledge base.

‍

‍

USER FLOW

During my stakeholder interviews, it was discussed numerous times that the UX process had to be flexible depending on the size or the scope of the project. For example, a full UX project would span multiple weeks and require most, if not all, of the process. Meanwhile, a small web development project may only have a week or two set aside for UX research and analysis, and not all of the UX tasks would be relevant.

To this end, I developed several user flows that were geared towards providing the appropriate UX tasks for each project.

‍

‍

CONCLUSION

The goals for this project were to create and document a new UX process that could be used internally by the client, and these were successfully met.

During this project, the most interesting thing I learnt was that different companies and agencies have different ways they want to use the UX process – and they may want to incorporate tasks that are not necessarily directly related to UX design, and find a way to make that work.

The stakeholders that I interacted with were very enthusiastic about the new process as it was developed, with a couple even saying that they now felt they understood the process properly.