Indy Judd
Product Designer


Balancing flexibility and ease of use for
insight-driven corporate events

Image alt tag

The Company

Rainfocus is an insight-driven event management platform. Events are an extraordinarily effective marketing channel, but due to their organic nature, it is notoriously difficult to quantify, measure, and act on data from them.

By providing a set of guided yet flexible tools for building an event around data and outcomes, Rainfocus allows clients to collect and manage data into one ecosystem. This allows companies to define metrics for any touchpoint (digital or physical), benchmark, and improve ROI.


Scrum Team

Each designer was embedded in a Scrum team, occasionally providing assistance where a designer was stretched thin.

Early on, I interviewed the other designers to find areas of overlap between our areas of ownership and put a physical reference of the findings at my desk to reference regularly.

I was also part of a "Product Decision Team" and "Product Strategy Team" that curated input from stakeholders for important tactical (weekly) and strategic (monthly) decisions, respectively.


Design Team

All contributed to a design system effort asynchronously with checkpoints for the design team and UI Development team to manage the component library.

We had weekly team meetings to discover collaborative opportunities as well as an active Slack channel for smaller feedback needs.

Frequent design reviews were scheduled with whoever was available at the moment or who is an active collaborator.

I was assigned a designer with more experience as a mentor; we had short daily meetings which generated learning opportunities and provided direct assistance.

Challenges & Takeaways

Here's a quick look at some of the growth opportunities I got to grapple with during my time at Rainfocus:

Entered a team that had little experience working with an embedded designer.

  • Created processes for better including Design as an essential element of team

  • Sought collaboration with Scrum Master & UX Manager to iterate on standard processes and educate team members

Inherited a large, green-field project with pressure to deliver.

  • Ensured rapid research and testing was still included throughout

  • Was mindful of and ready to address setbacks

Led one of the first product-level research initiatives.

  • Used a training I had given on scoping issues to guide artifact creation deepening understanding and alignment across the organization

  • Tracked overlaps and ripple effects to collaborate with proper people

A Stopgap MVP

User interface > JSON

The Context

Rainfocus originally operated under what resembled a consultancy or agency model in order to form close ties with clients and learn about their needs while simultaneously building the product.

The new strategy was to build a capable SaaS platform with a focus on usability and training instead of taking on work for the client.

Today, Rainfocus automates much of the creation of the digital attendee experience, leaving only details to be dealt with by event organizers.

But those responsible for assisting clients with building a successful event were stuck using JSON and HTML to produce the online attendee experience, despite having no relevant background or training.

These people would inevitably reach a point exceeding their ability, or run out of time, then pass the work to a team of developers to be finished.

As a result:

  • Clients were disappointed in results and didn't have realistic expectations

  • Attendees were frustrated with an unpolished experience for expensive conferences

  • CS team was frustrated with difficulty setting proper expectations with clients due to a lack of definition and guidance for attendee experiences

  • Developers were frustrated with inheriting attempts by untrained people to develop webpages

  • These developers were also responsible for updating the component library our product was built on, creating an extra incentive to release them from any unnecessary workload


Minimum Viable Research

When I arrived at the company the developers on my team were ready to begin building but were left with nothing usable from the previous designer.

This phase of the project was intended to be minimal scope. I needed to reach an appropriate level of understanding of the problem space ASAP.

How I accomplished this:

  • Quickly interviewed key stakeholders, squeezing into their availability however I could

  • Leaned on Product Owner's understanding

  • Analyzed existing research

  • Ideated throughout research to understand the problem, uncover new questions, and work on solution concurrently

Concept Demos

After a short iteration cycle using the favored directions from ideation sessions, I needed to make sure we corrected course before going further.

I needed to find:

  • Discrepancies between solution and problem

  • The best general form for the solution to take

  • Best way to implement into the structure of the product overall

  • Balance between time-to-delivery and polish

I planned and executed concept demos with key stakeholders including users, SMEs, dev, and product. I made sure to follow up with the same folks throughout the subsequent iterations as well.


Usability Testing

I decided to use a cognitive walkthrough to test the proposed solution as it was straightforward and had a very familiar flow to other areas of the experience.

With some fine-tuning, the construction of the MVP was well underway, in turn alleviating a lot of pain in the meantime and making room to work on a strategic vision for the next phase of the solution.

One of the cognitive walkthrough paths used in testing

Building a Builder

The Context

The next phase would set the stage for a fast, self-service tool for better online attendee experiences with richer data than had been seen by our clients.

The Product organization believed the solution we would deliver would be a web page builder.

I expressed caution against beginning with a prescribed solution in mind even if it felt obvious.

Instead, I insisted we begin by identifying and challenging our assumptions so that we might meet the problem with the best solution.

Luckily, the previous phase of the project provided good points of contact and foundational understanding, making it easy to move into generative research.

Learning & Growing: Scoping

The previous project presented important opportunities to improve our team's processes. We were still experiencing some of the same stumbling blocks.

I identified the issues by talking to the members of my Scrum team and seeking advice from the Design team and leadership.

I held separate trainings for the Design team and my Scrum team on the scoping trouble we faced and potential solutions. There was time for feedback immediately after my presentation.

The information gathered was then used by myself, the Product Owner, UX Manager, and Scrum Master to rework processes, formalize missing pieces through checkpoints, and clarify role responsibilities.



After exploring many directions – from boring & utilitarian to creative & exciting – I looked outward to collect patterns from other "builders" around the web as inspiration. There is a wealth of comparable tools and everyone I spoke with seemed to have well-formed opinions.

I also got my hands on competitive analyses from our Product Marketing team and read in-depth about our competitors' similar features.

During this "messy middle," I explored good ideas through whiteboarding sessions, impromptu critiques, and lo-fi prototypes.

Iteration & Concept Demos

Given the scale of what we were trying to deliver by the end of the quarter, I took a few concepts to high fidelity to solicit feedback from stakeholders.

This decision was based on:

  • The familiarity stakeholders have with the product aesthetic

  • Subjects having difficulty comprehending artifacts in low states of fidelity

  • Relevance to stakeholders who aren't intimately aware of the project

After capturing and analyzing feedback data, we settled on a general structure.

However, the developers were having trouble estimating technical lift even with a robust set of artifacts. This was because of the large, and semi-interdependent, feature set of the project.

This prompted me to split my artifacts up so they could be easily consumed by Engineering while at the same time maintaining a strategic design direction to create a "North Star" to head towards.

By doing this we could:

  • Thoroughly validate the experience of what we were building

  • Uncover potential roadblocks (technical or otherwise)

  • Set expectations for strategy-level stakeholders (leadership, marketing, etc.)


Early Prototype

I needed to make sure the structure we were basing our solution on was well-validated as we were nearing development on the first pieces.

Based on all the learnings up to this point I iterated to a prototype going through the primary user flow we aimed to deliver that quarter:

Getting Unstuck

At this point, my team and I hit a snag. No one was fully satisfied with the pattern for resizing content on the page and dissenting opinions were preventing us from reaching the level of alignment I found acceptable to move forward.

In order to break through, I organized a workshop that would use ideation techniques to help everyone communicate how they understood the problem.

Ideation Workshop

The agenda:

  1. Ice breaker: lateral thinking puzzle (5 minutes)

    • Lateral thinking puzzle: A man pushed his car. He stopped when he reached a hotel at which point he knew he was bankrupt. Why?

  2. Explain the context & background (10 minutes)

    • Keep in mind the MVP for Page Builder is only intended to take on the use case of building Portals, but will eventually be expanded to other use cases that are TBD.

    • The Page Builder is intended to reach an internally viable MVP this quarter with the intent that new insights and refinements will help us reach a client-ready version.

    • Show Portal examples

    • Show Page Builder mockups and explain the structure

  3. Go over problem statement (2-3 minutes)

    • As a user building a portal I need to be able to resize the cards on the page to match my vision for a speaker, exhibitor, or attendee portal.

  4. Go over "how might we" questions (2-3 minutes)

    • How might we provide users with the flexibility to reach desired outcomes?

    • How might we assist users in reaching attractive, desirable outcomes whether they have competence in designing web pages or not?

    • How might we create an intuitive experience that makes resizing straightforward, easy, maybe even delightful?

    • (After ideation) How might we ensure we can provide the functionality necessary for the MVP while building towards the right solution for future use cases?

  5. Ideation stage (10 minutes)

    • Come up with any ideas, feasible or not, crazy or obvious

    • Provide paper, pens, post its

  6. Pitching stage (15 minutes)

    • Pick as many of your best ideas as you want and explain them to the group.

    • After everyone is done we all vote for the ones we like best.

  7. Further discussion and next steps (15 minutes)

    • Don't leave without a plan for what to do next


Process Adjustment

Question: Why did we end up out of alignment?

Answer: Not enough communication. Wow, what a surprise!

Collaborating with those that were affected by the alignment troubles I proposed some experimental solutions.


  • More transparent and intentional tracking of pipeline feeding the roadmap

  • Created framework for collaboration on early-stage research, strategy, kick-off, deadlining

  • Clarified research and strategy responsibilities


  • Daily check-ins and weekly deep sync-up for implementation demos and concerns

  • Created a more reliable process to hand-off designs

  • Final design check on any "complete" work

Path to Solid Solution

Now that the stakeholders were realigned I could look back at all of the data and start to put a finer point on the solution.

After constantly gathering feedback from our sponsor users and getting critiques from Product and Design while iterating, I reached a threshold of confidence.


Vetting & Testing

Seeking to improve the quality of my usability tests I recruited a note-taker and recorded every test.

The cognitive walkthroughs of the updated prototype showed a clear improvement over the previous round of testing:


Because of the many constituent elements which each provided a unique value, I determined a survey would be helpful in organizing the sequence of delivery.

Key stakeholders helped to finesse the final set of survey questions.

The outcomes we sought were:

  • Sort out some finer details within the proposed design

  • Validate priority of delivery for value-adds not yet built

  • Obtain preliminary data on potentials to add to our roadmap

We were able to get high levels of engagement both internally and externally through a well-designed survey, but more importantly, thanks to a healthy and enthusiastic company culture.

Heavily recruiting from Business Intelligence and customer-facing roles was the key element in the success of our survey.


After all of the work we had put into finding an effectual dynamic it was a pleasure working with my Scrum team. The Developers and I had reached a habitual back-and-forth and I never felt out of the loop about technical limitations and shortcuts, and they didn't feel out of the loop with design progress and timelines.

We'd also opened up a significant cross-team effort to:

  • Consider future use cases that may consolidate other features

  • Avoid redundancies

  • Discover additional opportunities using other teams' expertise

Customer Advisory Board Rainfocus Event

The Context

The Product Marketing team turned the annual "Customer Advisory Board" into a bona fide corporate event, renting the Salt Lake City Grand America hotel and planning, building, and managing the entire event with our own product.

This was a fantastic opportunity to interact with people it was usually a struggle to even schedule a phone call with.

Moderated Card Sort

I gave a presentation providing context on the "Page Builder" project as well as some tips on building the pages our customers were after.

Everyone received a physical representation of all of the building blocks available in V1.0 of the Page Builder. They were then instructed to use the limited space in front of them to prioritize and organize these pieces.

Post-Activity Feedback Cards

We opted for physical feedback cards in lieu of a digital format. These people had very full schedules over the course of the event and would be presented with more relevant and exciting activities than our card sort.

The hypothesis was that we'd receive more engagement by encouraging and making time for the cards to be filled out and returned to us.

What we learned:

  • Our customers' mental models of the individual building blocks

  • Responses regarding key parts of the attendee experience

  • Their process for completing setup and related pain points

  • Other use cases or elements they would like to see in the future

After the card sort, I encouraged our audience to come and visit me and the Product Owner in the next room where we would be available for more discussion, this time led by them.

Data Dive

With all of the captured data in hand, I used the Design team's tool of choice, Dovetail, to organize, clean up, and dig insights out of the qualitative information.


Beta Plan & Measuring Success

Working closely with our partner in Product Marketing, the Product Owner and I brainstormed metrics that would reliably guide the effectiveness of our project.

We decided to use:

  • Integration points for analytics using Fullstory

  • Cadenced surveys to Beta participants

  • In-depth testing as deemed useful

We would measure things such as engagement and acceptance rates, time to completion, the quality level of attendee pages, etc.

We created a timeline with milestones and increasing availability for the Beta rollout and were ready to go!


Our target users were more concerned with quickly laying out many pages as opposed to seeing the details of every element. We also encountered some technical constraints that made the approach to designing placeholders easy.

I used a minimalistic style for the placeholders and color-coded them based on our users' mental models we learned about with our research. This way our users quickly saw the groupings and logical layout of the page.

Relying on the research from the CAB event, I organized the elements into layout templates to start our users as close to their goals as possible.

Looking Ahead

Later in the year, my team was to improve the experience for templatizing branding styles, assets, layouts, navigations, and anything intended to be applied across many pages.

This would unlock a new level of potential for our tool:

  • Improving user outcomes

  • Increasing # of relevant use cases

  • Streamlining workflows

  • Creating opportunities for synergistic interactions with other product areas

Because of its relative importance, I wanted to drum up buy-in and interest early.

To achieve this I conceived a possible solution to put in front of leadership and quickly turned around interesting iterations based on their feedback.

Long-term Roadmap

After a demo with the Designer and PO from another scrum team, they decided to free up space on their roadmap to integrate and rework the solution they owned into the builder project.

This was an exciting development as scrum teams at Rainfocus were somewhat siloed up to this point. Not to mention, I had considered their area of ownership in the design of the page builder framework.

Working with other teams and leadership, as well as researching the next use cases to add to our builder, we identified routes to continue exploration.

As COVID-19 made it clear that virtual events would become critical, solving virtual events was prioritized and the Page Builder became even more important.

"Baseline" Research Project

The Context

Leadership came to us with a new high priority effort that ended up pushing everything else on our roadmap. It was an exciting project codenamed "Baseline" that had begun in the non-product departments.

Leaders of operations and customer-facing roles put together a resource tracking overlap between events and workflows to templatized or automated.

The baton was passed to us.

Baking Alignment In

During previous research efforts, there were incidents that pointed to a lack of clarity regarding UX and PO responsibilities which caused slowdowns.

To avoid this, I proposed a Design–Product collaboration method by generating a visualization based on our professional dynamic.

Upon using this tool to communicate my mental model we closed the gap between us and had a concrete reference to adjust going forward.

User Archetypes

The Design team was working on creating archetypes to understand the many different roles of users and their interactions with each other.

I provided assistance to the Designer leading the effort for the two archetypes relevant to both the builder and Project Baseline research.


Phase One Research Plan

Many guiding conversations resulted in a research plan that was split into two paths.


  1. Event Project Managers describe timelines and roles

  2. Solution Analyst module experts share workflow details

  3. Training team takes us through a simplified event build with Solution Analysts providing support


  1. Project Manager coordinates proper contacts from client orgs

  2. Clients explain the ideal experience to provide their attendees and their workflow pain points/priorities

  3. Stakeholders from leadership, Business Intelligence, etc. assist in analyzing data gathered

A key resource we were leveraging was the internally developed "Event Success Methodology."

This is a training program for clients to learn how to achieve better event experiences and marketing outcomes than was thought possible.

The output we were aiming for was an experience map outlining the process of building an event with Rainfocus.

The outcome we sought was understanding and identifying opportunities for automating as much workflow as possible while improving end results.



Since this effort would free up an immense amount of time and resources for everyone involved, we had no trouble in scheduling many interviews in rapid succession.

The interviews were conducted jointly by the PO, myself, and a note-taker whenever possible.


Dovetail & Analysis

Using Dovetail I organized and tagged all of the information being gathered, adding in informally gathered data separately.

I made sure the relevant stakeholders were aware of this resource and had access.

Experience Map

After the data gathering was executed I had enough information to map out the process of building an event in Rainfocus.

By soliciting feedback from stakeholders I hadn't interviewed I was able to add depth and better understand the level of variation between clients and events.

This artifact was distributed and next steps were discussed with stakeholders.

Baseline Definition


I was confident in my understanding of the process. Now to find the level of granularity our automation required and break down the workflows.

Story Map

I recruited the PO to collaborate on understanding user needs and determine where to focus first with a story map.

Keeping our minds focused on user needs helped to ensure that we weren't working backward from a solution and instead, finding the best way forward.


Hierarchy Map

The Design team was currently restructuring and fully redesigning the aesthetics of the Rainfocus platform. This presented an opportunity to include considerations for assisted workflows in the Information Architecture of the product.

To help my teams understand what form this could take and raise new questions I created a hierarchy map to serve as a point of discussion.



To effectively scope the project I produced a concept artifact built on the most obvious form a solution could take.

The intention was to:

  • Create a visual reference to communicate the functionality to deliver

  • Discuss technical implementations and implications

  • Gather early feedback on the direction of a solution

This was done in close collaboration with the Designer leading the product redesign effort as well as stakeholders familiar with our Event Success Methodology.


Concept Ideation

With an idea of where this would live in the redesigned experience I shifted focus from the problem space to the solution space.

Now I was collaborating more closely with the entire Design Team since this would touch most teams' areas of ownership.

With a focus on solutioning, I was checking in as often as I could with other non-design, non-technical stakeholders.

If I wasn't correcting course frequently this project could have caused massive headaches with its effects on the IA and its own framework.


Other Highlights

Some other highlights from my time at Rainfocus:

I was able to iterate on my design process/tooling and found effective ways to track and increase productivity

Led the charge to include more motion design in the product, demoing Flinto and Protopie as options and creating proof of value for leadership

Participated in a multi-day product summit where the strategy for the next year was finalized

Contributed to our design system by moving proposals through the approval and development process



The event industry and our company were hit hard by the COVID-19 pandemic resulting in a large workforce reduction, including my entire team.

My time there was an incredible experience that allowed me to grow at a rate I'm very proud of. I'm also proud of the lasting impact and contribution I was able to make.

In the time since, I've been working on new skills like graphic design, branding, 3D design, etc. I've been able to focus on my health, social activism, and relationships.

I absolutely cannot wait to design more digital catalysts of useful, usable, and delightful experiences!