Design Editor
Decision
We decided to move forward with Chili Publish. At the moment, we are assessing whether or not a design editor integration with Chili Publish can solve our customer's pain-points.
Problems
We need a bet that might turn into an upsell opportunity.
- Competitors are catching up, so we will need to keep our advantage
The design editor represents a bet to alleviate the design edit pain-points our customers experience:
- Design teams are in general a very scarce resource for our customers. Asking for small design edits/adjustments usually involves a time-consuming process which leads to time and/or financial loss.
Context
- @dbartholomae and the create team conducted several customer interview sessions to understand design editor pain points
- Chili Publish was previously considered as a potential integration partner for a pre-flight solution
- Chili Publish demo
- Deutsche Post at some point integrated with Chili Publish to offer their customers a print-focused design editor
Options
The following integration partners were considered
Reasoning
We decided to partner with Chili Publish because they offer an editing solution that has the potential to import InDesign files, which would allow us to both create designs from scratch and make adjustments to existing ones. We were also interested in other potentials that the Chili Publish editor had such as:
- Creating templates (this would help us automate a minimally editable Letter)
- Potentially program all prints via Chili Publish
- Allow customers that have simple design needs to create their own campaigns without the need of a design team (Banks and other financial institutions)
Consequences
How do we implement this change?
We start by implementing the use case where we want to allow our customers to be able to make small edits to an existing Template. This Template is tailored to a single campaign that our customer wants to automate. In general, creating such a Template means getting the initial InDesign file from their design team, and we import it into Chili Publish and do the necessary corrections/constrains.
The constrains are defined in collaboration with the customer. For instance, it could be that they want to:
- Be able to replace the picture in a free-flow shape that is located at the top-left corner of a Postcard.
- Edit all texts, but not move them
- Edit individualisations
- Re-size shapes but only proportionally
The design editor should be accessible via Client Dashboard 2.
Who will implement the change?
The Create team will make this change.
How do we teach this change?
Integration with Chili Publish will be implemented by following the Hexagonal Architecture approach. Which is already an adopted technique within the product team. It should be easy to follow the core use cases as well as the domains that it interacts with.
What could go wrong?
- We are not able to guarantee customer assets are not leaked to other customers
- The Chili Publisher editor is too difficult for CRM managers (or others not trained in design) to work with
- We encounter deal-breaking non-technical problems with Chili Publish (e.g. pricing model, legal, security standards)
- The design editor does not actually solve the customer's pain points
- Creating highly personalised Templates for each customer does not scale
What do we do if something goes wrong?
If the problem is security-related we need to escalate the problem with the CISO (Chief Information Security Officer) and ensure that customer data is protected.
If we need to switch integration partners, the code is written with the Hexagonal approach. So it should follow that the changes would be limited to the adapter layer.
What is still unclear?
Our current agreement with Chili Publish is a single environment which hosts all of our customers. It is still unclear whether or not we can guarantee our customer's assets are only accessible by their rightful owners.
Related ADRs
None