In order to give back to the community, Accenture has a number of 'Do Good' initiatives. The initial aim of the SkillsGuide project was to increase employability and occupational mobility, in particular for members of NGOs we partnered with (Refugee Talent Hub, Werken voor Elkaar, Access).

After extensive research and many workshops, we eventually came with the SkillsGuide concept. A (web)app that helps users figure out which skills they already have an which are transferable amongst different professions.

Below is a case study of the project, including personal insights and learnings. Throughout this project I was the sole designer, meaning my work consisted of UI, UX as some service design. That being said, I am grateful for all the help and support I received from my fellow colleagues at Accenture Interactive.
‍

First, let's talk about how we got to our solution. As is quite conventional these days, we used a double-diamond approach, where we ideated rapidly while constantly validating our hypothesis with potential end-users. Because of our close partnerships with NGOs, we had access to a large number of potential users and were also able to interview them in person, leading to a greater amount of tangible insights.

Once the concept was validated, we set out to build the platform. This is where the overall user experience and interface validation started. One important factor during these validations was negating for bias, as participants generally were very grateful for our efforts on their behalf, and hence we encouraged them to be as honest and forthcoming as possible.

To ensure consistency and to make developer handoff more efficient, we developed a design system. Below is an overview of some of the components developed for this project, their various states and specifications.

Given the scope of the project, we created a relatively simple design system. However, in the future I look forward to developing one further. I especially look forward to being able to sync design changes with their programmed counterparts automatically. E.g. by syncing React components with a design tool like Framer X.

As mentioned above, we constantly tested both our assumptions as the interfaces we developed during the project. This included both hands on interviews with participants (which were recorded), as using great tools to asses the effectiveness of the product on a larger scale.

To accomplish this, we used tools like Hotjar, Google Tag Manager and Analytics. Analysing all this data at a larger scale made it easy to come up with actionable insights to improve the user experience.

One take away I'd like to share, is that we tried to use Material UI  Components for React when applicable. This huge library had the major advantage of saving a lot of time which could then be used for other aspects. However, it is very important to remain vigilant, because these UI components might not work as well as you hope, or perhaps haven't been validated with users sufficiently. To give you an example, the Material date picker we used, ended up being very user unfriendly, at least in particular with our target users, because the year selection field was quite hidden away. This had the painful result that users would keep on hitting the previous button (per month) to eventually get to the year in which they were born. That can take a lot of time! The moral of the story is to always validate all UI components, even if they're already mainstream and popular.

‍