Below I describe the process of planning and involving stakeholders in a UX project, taking the role of a UX Lead.

If you are looking for a thorough design process and its results, please visit my other project: Dashboard UX Design.

In this project a few roles can be defined.

First I describe my roles in this project.

- UX Lead: I oversaw the whole project and what and who I needed to achieve a good end result. I connected to the right people to bring the project to and end in time.

- UX designer: I went through the design process to create the prototypes for the report.

- Planner: I created and stuck to a tight planning.

Other roles in this project.

- Product owner: available to discuss business requirements, data restrictions and advise on programming.

- Head of Business Development: proposed requirements based on the information the business development team gathered. The requirements were based on information from users and and on business perspective.

- Full stack developer: available to think the project through with me and check the feasibility of the requirements and designs.

- Data engineer: research on data granularity and feasibility of the data requirements.

Unless stated differently, I initiated, organized and created everything what I describe below.

The project started with a briefing initiated by the product owner. 

During this briefing the internal client exchanged as much information with me as possible. The internal client was the Head of business development.

Project Date: 26/10/2023 - 01/12/2023

Goal: Create a ready to develop prototype of an extra report in our dashboard.

After the briefing I started with creating a planning. The project time was roughly one month and since we were dependent on the availability of our clients, I didn't want to waste any minute.

I expected to lose time on 'waiting' for usability tests and to be able to design the final prototypes fast, since the report had to fit together with five other reports that we have already.

In the planning I defined all the steps that I had to take and I mixed the planning while working on the project. For example, I started to work on the test plan already for components that would be in the report for sure, since certain parts were tested thorougly for the other reports already, so that I would create some space in the schedule.

Also, I was dependent on my internal client, because I needed him to contact the users. For that reason it was important to keep communicating what I needed in order to finish the project in time.

Below you see a part of the planning.

From the internal client and product owner I received a list of requirements. To be sure that I would work with the correct requirements and to get a better understanding of the needs, I tested the requirement list with a few of our key clients.

Many general requirements I gathered from the existing reports in our dashboard. And during the design process I created extra UX requirements there were we had new types of charts.

The list of requirements I prioritised with the product owner and with the full stack developer I checked the feasibility.

Below you see a few of these requirements.

When all the requirements were validated I tested my first sketches. Most of the time for this project was reserved for prototyping, the sketches were the most important aspect of that. I planned usability tests for validating requirements and testing the sketches in one session per client, mostly because of the limited amount of time.

Below you see an overview of the sketches that I tested with.

After the usability tests I redefined the requirements again with the internal client and the product owner.

From this requirement list I created a component overview and a test plan.

Since we stopped using XRay for Jira, we needed to test manually. 

For all our components I created a mastersheet with all the specifications, so that in a test plan I could just make a list with references to that master sheet and extra information if needed.

I created the testplan to have a checklist to build and test the final design and for building and testing the real product.

When we were sure that the functionality that we required from the product was indeed that what we needed, I created low fidelity prototypes in Figma, which I tested with users.

After the testing was still room for requirement adjustments and discussing last changes with the product owner and the full stack developer. This resulted in the high fidelity prototype.

Below you see on the left side the low-fidelity prototype and on the right side the high fidelity prototype.

Together with the internal client and the product owner I created a priority list for development, based on the MoSCoW method, the final component list and the final test plan.

When the project was sent to development I stayed available for discussion about and tweaking the design.