NDA'ed but a process had to be followed.

Solution...

Audit and identify the website's areas where we needed content controllable by CMS. Categorise them and create components.

Getting the solution, signed, sealed, delivered...

First stop was Miro, audited the website's page types and dentified the areas where we needed content controllable by CMS. Next, a categorisation of the different content types and writing/creating of user stories to Jira for each and every component that the website had.

From there moved in Sketch and Invision, to establish the components structure and pin pointed which design elements we wanted our team to be able to modify in the CMS and by using a Confluence page to keep track of the elements, and linked them back to the related user stories.

Design

The designs for each component, that went through 6-7 rounds of tests each on average on both qualitative and quantitive lab/web testing including all variations, were made all using Sketch. These were then uploaded to Zeplin for the developers sake (back those days we didn't have Figma). 🔮🤪🎯

Additionally, the designs were placed in a library, so they could quickly be mocked-up where and how will those be used across the site.

Build

The developers began with building the components based on the designs, but with the tight deadline and a brand new team on board - I had to step in to help with guidance on HTML & CSS as i was going through the components myself.

Test

Once the designs were in place, we completed the UAT testing, which included device and cross-browser testing to the maximum in the early morning hours.

Deliver

Over 7000 content items were migrated from an outdated in-house content management system (CMS), to a modern component-based CMS, called Amplience.

Design iterations

To measure success about the latest designs, we used Adobe Target and with the assistance of the optimisation team, all data were gathered and analysed for all the iterations that followed.

‍

What i have learned:

Takeaway 1:

Initially, the requirement was to only focus on the UI of the product. However, I knew that as a UI/UX designer, my job is to advocate for the users and to coordinate the whole balanced team to come up with the best product designs.
After consulting my design manager and other senior designers for advice, I set up a meeting to explain the user-centered design process I hoped to follow. I proposed a timeline to make sure that the product can still be built within the time constraints, and explained why adding activities like interviews, brainstorming sessions, and user feedback would help the team fail fast and eventually build a better product that people would love using.
From this experience, I learned about how to advocate for design when necessary. It is important not to blindly stick to a "process", but to understand why different design activities help us build better products, and to convey the value of those activities to stakeholders and other team members.

Takeaway 2:

It turned out that our developers were more than willing to sit with us during interviews/testings and synthesize with us afterwards. It was a win-win scenario because they were interested in hearing what the users of their products say, and their expertise in the product helped me capture a lot of important points from those sessions. We all had a better understanding of how each other work, and how to collaborate to make the product better.