From Design to Deployment – How the UI is Created in the DOUGLAS Online Shop

When I read the job posting, I immediately knew that I wanted to give DOUGLAS a try. As a large company with an established e-commerce platform, I was especially hoping for well-organized workflows, an interesting tech stack, and more understanding of my work. In order to be able to fully concentrate on my tasks as a developer and grow with them, it was especially important to me that I could fully rely on the expertise of my colleagues.

The tech stack delivers what it promises. The extensive React frontend offers me the opportunity to learn new techniques that will help me grow as a developer. Here, it is especially exciting that the frontend provides a shared codebase for a variety of different platforms. Through the sophisticated build processes of our DevOps, we frontend developers can reuse the same code for the different web shops abroad, for example in Belgium and the Netherlands, but also for the different platforms such as the iOS and Android app of DOUGLAS, where we focus on the core points when making adjustments. It is also interesting to note that the same code forms the basis for our internal Bella platform, which is used by our colleagues in the stores.

Before I started at DOUGLAS, one question was constantly buzzing through my head: How does a new UI element get into the online store? Now I can explain it to you.

Once the feature planning has been completed in a roadmap, the design is conceived by our colleagues in the UX department and worked out as a Figma prototype. If there are several different ways to implement the same user story, A/B tests may also be conducted during this phase to determine the best variant. After the finished design has been handed over to us devs for development, we begin to work until the keys glow!

And here comes the magic. Because as soon as a feature has been implemented, the deployment process starts.

With each pull request, an automatic build process is performed that checks the code quality and runs unit tests with Jest on each individual component. If all goes well here, a push of a button is all it takes to start the Azure pipeline, which installs a dedicated test server where we and the QA team can rigorously test the developed feature. In many cases, this includes end-to-end testing with Playwright. This tool automatically clicks through the store and reports on potential bugs and quality defects that we missed during manual testing. It makes my developer heart beat faster! For testing purposes, we also have the ability here to create dedicated test data such as products with special features via IMPEX Builder. This rigorous test track gives me as a developer the assurance that my features are robust and free of bugs.

One or two more clicks and you’re good to go. The next Azure pipeline grabs the code with the new feature and delivers it to all stores and apps so our customers have an even better buying experience. Ultimately, if the feature can prove itself on the production system, it will be finalized into the source code. I don’t have to explain to anyone how cool that is, do I?

But what’s even cooler is that here at DOUGLAS I get to talk to a bunch of experts about the technologies and tools we use, and everyone has an understanding that software development goes sometimes up and down despite tried and true processes.

I’m excited to see what the future holds!