Bielefeld Shop

An online shop run by a city marketing company sells two very different things under one roof. On one side there is the souvenir range: physical articles, often in several versions, with different sizes, colours or weights. On the other side there is the city voucher, a product that has no physical properties, only a value.

Bringing both together in one shop is the real requirement. Articles and vouchers follow different logics in presentation, shipping and processing, yet they should feel like a single offer to the buyer.

Then there is the sender. A city marketing company appears in public, its visual identity is fixed and applies across every channel. Until the relaunch, the shop ran on a standard WordPress design. A standard design is functional, but it does not carry an identity of its own. The relaunch therefore put the corporate design of the city marketing company first, so the shop is recognisable as part of it.

The new shop design takes up the corporate design of the city marketing company. Tidy does not mean plain here. The page subordinates itself to the product, which is the right order for a souvenir range, because the articles themselves carry the recognition value.

The link between design and technology becomes visible in the product variants. An article available in several versions is a data model in the shop and a selection on the product page. The two have to match, otherwise selection fields appear that hide existing variants or offer combinations that cannot be delivered.

Shipping specifications were set individually down to product level, following the customer's requirements. For a mixed range that is the only dependable approach. A single flat shipping rate fits either the heavy article or the light one, never both. Once the rule sits on the product, the basket adds up correctly and nobody has to correct amounts afterwards.

A shop that is already selling is not rebuilt on empty ground. It keeps running while it is being changed over. That is why the relaunch focused on protecting the existing order and invoice data. Order histories and invoices are not leftovers, they are records that have to be kept and that get used in daily business, for instance when a customer asks about a purchase.

This sets the sequence of the project. What happens to the existing data has to be settled before decisions about design are made. Do it the other way round and you end up with a finished shop that cannot be put into operation.

With shop implementations of this kind, the same attention pays off for the processes behind an order. Payment through a payment service provider, order confirmation, a compliant invoice and shipping are steps that either run automatically or are done by hand. Whatever is not considered during the relaunch stays manual work for good.