Published on | Prototyping: From UX to Front End — Medium Robert Sens

Part 2 / How might we leverage research insights and hypotheses-driven ideation to rapidly define and prototype a proof of concept?

This is part 2 of 2 / If you read part 1 — skip the intro!
If not, you can read Part 1 here: Taking a User-centered Approach to Transactional Email Design: Case Study (Part 1 of 2)

When it comes to prioritization and resource allocation, the design and definition of transactional emails is typically not at the top of the list. This often results in design and content that is not given the attention necessary to capitalize on the potential impact that an informed, intentionally structured email can drive for a product or service.

I quickly recognized the potential for intentionally structured transactional emails to help us deliver on our target KPI’s.

In my role as the Lead Product Designer at Reserve, a startup in the restaurant technology space, I encountered this very challenge. With limited resources and higher priority tasks, our suite of consumer-facing transaction emails had been given just enough resources to get them up and running, but were rarely though of unless absolutely necessary.

As the Lead Product Designer, I was responsible for the design of all of the products within the consumer product suite, transaction emails included. As we scaled our product ecosystem, I quickly recognized the potential for intentionally structured transactional emails to help us deliver on our target KPI’s.

In order to rally support around the initiative, I decided to take it on as a side project.

The only problem…time and resources, not just my own but also the other team members I would need to contribute to the project: content, marketing, technology, etc… In order to rally support around the initiative, I decided to to take it on as a side project.

To get started, I asked myself two questions.

To get started, I asked myself two questions:

How might we design more effective, intentionally structured transactional emails?
How might we build advocacy and equity around the project in order to secure the resources to bring it to life?

This case study outlines the bootstrapped process I implemented to develop a proof of concept (POC) of a modular transactional email design system.

This case study outlines the bootstrapped process I implemented to develop a proof of concept (POC) of a modular transactional email design system.

Part 1 of this story (click here) is focused on the first phase of the project which includes initial research, planning, and collaboration as a means to build equity and internal advocacy for the project.

Part 2 of this story (below) focuses on the second phase of the project which includes detailed interaction design, content definition, and developing a production-ready prototype using the Foundation for Emails front-end framework from ZURB.

This is part 2 of 2 / Part 1 can be read here: Taking a User-centered Approach to Transactional Email Design: Case Study (Part 1 of 2)

Phase 2: Outcomes and Takeaways

The second phase of the project focused on interaction design, visual design styles, content definition, and developing a production-ready prototype using the Foundation for Emails front-end framework from ZURB.

Phase 2 Outcomes:

First, we identified scenarios and triggers as a basis to map all of the interaction points within the service ecosystem. These accounted for the various user types and origin points identified on Phase 1.
Second, we utilized the user needs and goals identified on Phase 1 as a basis from which to identify and design a modular set of components. This coincide with the design of a responsive architecture that would house a subset of modular components to form a discreet email.
Third, the foundation of a visual design language system was compiled in order to facilitate full-fidelity prototyping and testing.
Fourth, system content and copy needs were further defined, prioritized using an evaluation framework, then clear expectations were set on who was responsible for what and when it was needed.
Finally, we coded a production-ready prototype using the Foundation for Emails front-end framework from ZURB. We tested the prototype extensively using Litmus, and iterated on the design and codebase to ensure consistency across a range of mail clients, apps, and devices.

Phase 2 Takeaways:

The up-front research, ideation, and hypotheses orchestrated in the first phase of this project provided a basis from which content-definition, design, and prototyping could take place quickly and efficiently.
Utilizing the Foundation for Emails front-end framework from ZURB facilitated rapid prototyping, it allowed for less up-front static design in Sketch and more dynamic design and experimentation in code.
Content is king! Keeping content top-of-mind and implementing a content-forward approach during both ideation and design will help facilitate a more efficient progress and production pipeline.

Conclusion & Next Steps

The proof of concept prototype was just the beginning of this project, it was the trojan horse I used to build advocacy and equity around the project in order to secure the resources to bring it to life. As the initiative gained traction, responsibilities for the project were more evenly distributed various stakeholders andteams.

A few next steps not outlined in this case study included:

Utilize Mandrill to make our templates dynamic by pulling content directly from our database, and customizing our transactional emails on the fly.
Plan and coordinate a limited production release with support from the cross-functional teams including: Back-end Development, QA, Marketing, and Operations.
Monitor and assess end-user interactions with the new system through analysis of key analytics and operational metrics over a three month period.
When confident, push a full production release to our entire user base!

Thanks for reading! Did you read part 1?

Part 1 of this story (click here) is focused on the first phase of the project which includes initial research, planning, and collaboration as a means to build equity and internal advocacy for the project.

Part 1: Taking a User-centered Approach to Transactional Email Design: Case Study (Part 1 of 2)

<a href="https://medium.com/media/b85dfbb5286d8a25cf2e754b9462cf45/href">https://medium.com/media/b85dfbb5286d8a25cf2e754b9462cf45/href</a>

A User-centered Approach to Transactional Email Design: UX Case Study (Part 2 of 2) was originally published in Prototypr on Medium, where people are continuing the conversation by highlighting and responding to this story.

A User-centered Approach to Transactional Email Design: UX Case Study (Part 2 of 2)

Cool stuff, every week

More Articles