Rainfocus

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

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

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.

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.

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

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:

Survey

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.

Implementation

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

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.

Templates

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.

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.

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.

Intro

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.