Designing and testing an AI-powered CMS for a global news company

Running a two-day design sprint, designing and validating the product idea, and planning for the MVP.

Case study
March 31, 2018
Designing and testing an AI-powered CMS for a global news company
My role

Product Designer

The activities

Workshop facilitation and Product Design

The team

Product Designer (remote), Account Executive (in-person)

The tools

Facilitation props (markers, whiteboard, sharpies, sticky notes, and dot stickers), Sketch, InVision, and Google Meet


The product is a B2B platform that allows publishers to find and embed video content on their publications quickly. The company worked for months on the backend and the algorithm to make recommendations of videos based on the content, but they didn't have any interface designed yet. These are some of the activities they wanted to enable on the users' side:

  • A publisher goes to his or her CMS to write a piece of content
  • They click on a button to get video recommendations to be embedded in different places of the article and different formats
  • The user selects the content and publishes the article
  • The user gets access to a dashboard with metrics related to their content, and the number of readers or viewers

During a two-day workshop, we needed to define and validate a high-fidelity prototype conveying the experience listed above.


Deliver a clickable prototype of the minimum viable product in two days and get positive feedback from potential buyers.


The first challenge was to run a successful two-day workshop by myself on the other side of the world with five high-level executives and deliver a prototype on time. The second challenge was to get positive feedback on the prototype from potential buyers and extend the project to its implementation.

Process & Solution

The client approached the company just with a few days of anticipation and asked to have "something tangible" to show to their investors within the next month. We had a prep call to review the scope of the project, understand the level of definition of the product, and the current understanding of the users.

After the call, I planned a set of activities to be run with the information that I had, plus another set of activities as a backup in case I needed to change directions based on new findings or if the client decided to go in another direction (which is usually the case).

These were some of the exercises I prepared for the sessions:

  • Warm-up exercises
  • Proto-personas
  • User journey maps
  • UX honeycomb
  • Ideation activities from Sprint (HMW's, crazy-8's, lightning demos, and heat-map votes)
  • Storyboarding
  • User story mapping

Since I knew I would need to improvise a lot (change activities on the spot, switch the order, tweak the exercises, etc.), I put together a 100-slide deck with every exercise step by step and a first slide with links to jump quickly to every activity.

I head to Australia by myself and asked for the support of my peer, Florian Lissot, who would support me from 12-hour difference timezone (I will explain later how this situation was beneficial for us in the end).

First day

We kicked off the workshop with some introductions. To make it a bit more fun, I asked them to say these three things about themselves:

  • Their name
  • Their position in the company
  • One skill they would like to learn this year (doesn't have to be work-related)
  • A superpower they would love to have (mine is teleportation)
Introductions slide

This activity allowed people to feel more relaxed and laugh a bit by listening to the answers of others (especially the answers to the last question).

0. Warm up

Since the participants would be sketching a lot during the day, I had them go through a warm-up exercise called "The 9 Dots": a puzzle from the '70s invented by John Adair commonly used at the Walt Disney Company.

The activity is very simple: we ask participants to draw a square made of nine dots, then we ask them to connect the dots by using as few lines as possible.

Although there is no perfect solution, this exercise usually allows for many creative solutions from our participants. These are some examples:

"9 Dots" solution examples

In this case, this activity helped my stakeholders to feel comfortable using sharpies and paper before jumping into other exercises (funny story: this is how the term *thinking outside the box* was coined).

1. The problem

When running a workshop, making sure participants feel their time is being properly used is crucial. In this case, I wanted to get a good idea of how much understanding did they have already around the problem space so I could discard any activities that might be unnecessary.

I asked the group which problems they wanted to solve for their market and took notes while they listed them. Most of the stakeholders had first-hand experience in this market and had done a lot of desk research. They had enough understanding for us to move to define the specific personas we wanted to focus on.

2. User groups

I gave five minutes to the team to write down the different profiles or user groups that would be interacting with the platform, one sticky note per profile.

Once they finished, we grouped the profiles on the whiteboard and then asked the team to select the profiles we should be focusing on for the workshop. The prompt was: if we were to launch a first version of the product next month, who would be the first people using it?

User groups

We selected two profiles and started creating proto-personas.

3. Proto-personas

Proto-personas are archetypes not wholly based on research but instead made of a combination of hard data, anecdotal evidence, and strong (as in very close to reality) assumptions.

For each archetype, I draw four quadrants on the whiteboard:

  1. Challenges and pain points
  2. Needs and goals
  3. Behaviors
  4. Demographics

Then I allowed the team to add ideas for a couple of minutes. Once finished, I asked them to place their sticky notes on the whiteboard and group the similar or identical ideas. Next, I put a name to the proto-persona, read the pain points, needs, goals, and behaviors, and briefly discussed any ideas that the team might have missed and should include in the whiteboard.

As the last step, they voted on the pain points and goals that had more relevance, as in those that needed to be addressed first through the product. We would revisit these proto-personas once the solution was ready to ensure we were addressing these needs.

Needs, goals, behaviors, and pain points of a proto-persona
Proto-personas documented

4. Ideation

Now it was time to work on the solution, so I ran the following activities from the Sprint methodology:
1. Crazy 8's (8 min): fold the paper in half three times until you have eight panels. Draw one idea per panel, one minute each.
2. Solution sketch (15 min): choose one or two panels to create one big idea. On one piece of paper, draw your proposal in detail and make it self-explanatory so others can understand it without asking questions.
3. Art museum (3 min): Stick the sketches on a wall and space them out in one long row, just like the paintings in a museum. Observe the details of each idea in silence.
4. Heat map (5 min): Look at the solution sketches. Put dot stickers beside the parts you like (if any). Put two or three dots on the most exciting ideas.
5. Speed critique (3 min): Gather around a solution sketch, call out standout ideas, and write them down on sticky notes. Review concerns and questions. Explain any missed concepts. Move to the next sketch and repeat.
6. Super vote (5 min): Give each participant one super vote and give three to the decider. Use the elements with more super votes as a reference for the whiteboarding.

Solution Sketches

By the end of the ideation phase, we had a good definition of the ideas we wanted to use in the final prototype.

5. Storyboarding 2.0

I used this technique from AJ&Smart to create the narrative for the prototype. I asked the team to individually define the steps the user should follow from start to end while navigating the product without considering edge cases, just the happy path. One sticky note per step.

They placed their timeline on the whiteboard, and then we merged all the steps into one master timeline.

Storyboarding 2.0

We ended up with a simple journey that was enough to describe the value proposition for our users.

6. Whiteboarding

I have done this activity collaboratively and individually. The truth is that doing it with the whole team watching you is an overkill – you already have all the steps you will draw, plus a bunch of sketches prioritized that describe the details of the UI. It is better to give the team a break while creating a first version of the flow and calling them later to get their feedback and iterate.

This is what we ended up with:

Sketches describing the interaction for the prototype
Sketches describing the interaction for the prototype

Our main stakeholder had already scheduled a few meetings with potential buyers for the next day to walk them through the product and get their feedback. It was crucial for me to deliver a high-fidelity prototype the next morning.

I went back to my hotel to have some dinner before continuing with the pending work.

7. Asynchronous collaboration

That night, I had a zoom call with my peer, Florian, who couldn't travel but would still supported me from Mexico. We had a 90 min session where I walked him through the work done during the day and then jumped into Sketch to do some peer design.

We created the wireflows for the prototype together, and then I went to sleep. The next day, he would have a high-fidelity prototype ready for me to present to the client.

Wireflows in Sketch

Second day

The next morning, Florian showed me the prototype. It looked great! He even created symbols of most components to quickly make changes that could be replicated in every screen when I implemented feedback from the client.

Final prototype

8. Feedback sessions

As opposed to the typical sessions I run at the end of these types of workshops, this one didn't include a concept testing with a set of users navigating through the prototype. For our client, it was more important to showcase the product to potential buyers (not the people who would actually interact with the user interface) to get their feedback and initial reactions. Although some of the feedback we receive during these walkthroughs tends to be biased (because people usually tend to be nice), we still received feedback of value around what was helpful.

We ran these sessions while the team was taking notes, then we had one last session to debrief and agree on potential changes to the prototype.

9. Closing

We closed the workshop with the agreement to send an SOW to continue refining the user interface, cover alternative paths and edge cases, and develop the minimum viable product in the following weeks.


We delivered and tested an MVP and received positive feedback. Our client felt confident about the direction the product was taking, and we turned a 2-day workshop into a 6-month assignment with a team of eight people implementing and iterating our initial design.