I had the opportunity to shadow the UX team at Rapid7 in Belfast during my first summer, spending a day alongside Andy Robinson and several senior designers. This experience offered an authentic glimpse into the daily life of a UX researcher and designer, from team meetings and design critiques to seeing project work in action. It was an inspiring and eye-opening day that helped me build new skills, gain practical advice, and strengthen my passion for pursuing a career in user experience design.
Before beginning my work experience day at Rapid7, Andy explained what I could expect and how the day would be structured. While I wouldn’t be doing hands-on design work at a computer or producing sketches, I was instead allowed to immerse myself in the environment and observe the processes that drive professional UX practice. A section of the day involved attending a range of meetings, both casual and formal, that covered different aspects of UX design. These included critiques and collaborative sessions where ideas were shared and discussed, many of which were presented and worked through on Miro. Being able to sit in on these conversations gave me insight into how teams communicate, review each other’s work, and problem-solve collectively. Andy also advised me to take advantage of moments throughout the day to connect with other team members, including UX researchers, designers, and leads. This gave me the chance to ask questions, gain advice, and see the variety of projects people were working on at different stages. What made the experience especially rewarding was that I was also able to share some of my own work with the team, receiving both supportive feedback and constructive critique. With this structure in mind, I knew the day would be busy, creative, and full of opportunities to learn. It provided me with different perspectives, new ways of thinking, and a deeper understanding of how UX design functions in a professional setting.
The first meeting I attended with Andy was a great introduction to how UX design discussions are handled in a professional environment. From the beginning, it was clear that the focus was on problem-solving and collaboration. Team members discussed in detail the problems that needed to be addressed, the progress already made on designs, and the ways information could be best presented through both UI and UX perspectives. A recurring theme was the importance of understanding what users would want to see and how they would interact with the product. In the context of Rapid7, this meant looking closely at issues such as security threats, attacks, and how these could be represented clearly and effectively within dashboards. The meeting also explored broader topics such as future visions for the product and overall user experience. Notes and diagrams were used to map out how different pieces of content connected, while team members contributed valuable insights into what needed to be done, solved, or created next. It was also interesting to see how discussions revolved around customer expectations, ensuring that deliverables aligned not only with project goals but also with what users genuinely needed. A structured approach was taken to these discussions, often framed around “who, what, when, where, and why” statements, which helped clarify objectives and ensure nothing was overlooked. Real examples were shown to illustrate how and why certain features were implemented, what benefits they provided to users, and where they would fit within the overall system, such as widgets or dashboard programs. Timelines and deliverables were another important focus. The team considered when problems should be acted on and how progress could be measured against deadlines. The meeting also looked at a specific project goal that combined both Figma-based design work and coding versions. Each brief followed a consistent format, outlining the title, description, purpose, links, and actions required. Finally, workflows were demonstrated through Miro, where wireframes were annotated with briefs for each stage, and a Figma prototype was tested to check functionality. This hands-on walkthrough of the prototype showed how the dashboards worked, including whether different tabs functioned properly and fulfilled their intended purpose.
This first meeting was a great introduction to how a high-end team of designers comes together in a more formal setting to discuss their work. It was the first time I had experienced this level of collaboration, and it gave me a clear sense of how professional designers structure their discussions and advance projects. The team explored detailed aspects of UX projects, breaking down problems into smaller, manageable parts while also considering how best to create solutions that met both user needs and business goals. What stood out most was the way the meeting was structured and how each member contributed valuable insights, whether through sharing progress updates, critiquing ideas, or suggesting new directions. Seeing how ideas were presented, discussed, and refined gave me a much stronger appreciation for the role of teamwork in design. For me, it was an eye-opening experience that highlighted the level of detail, organisation, and problem-solving required to deliver high-quality UX outcomes.
The second meeting I attended shortly after felt noticeably different from the first. While the initial session had been more formal, structured, and complex, this one was smaller, more relaxed, and focused on design critique. Using Miro, the team discussed concepts around unified notifications and user stories, breaking down the topic in a way that was both approachable and practical. The main goal of the session was to explore how notifications should function within a product, why they matter, and how they can best serve different types of users. The team asked important questions such as how notifications should be configured, when they are actually necessary, and how to avoid overwhelming users with excessive or irrelevant alerts. They looked at both internal and external scenarios, linking each to user personas and considering what value each notification would bring. It was interesting to see examples of grouped notifications, like those used in existing apps, and how configuration options, such as those found in Slack, allow users to fine-tune what they see. The discussion also highlighted the importance of prioritisation. Critical events, such as urgent security issues, need to take precedence over less important updates, and the challenge lies in making sure systems communicate this effectively without creating noise or confusion. The team reflected on real-world comparisons, such as how Apple manages time-sensitive alerts, to explore best practices in simplifying and controlling notification settings. This session felt less like a formal update and more like a problem-solving workshop. It was about identifying gaps, understanding scenarios, and shaping solutions based on user needs. The team continuously framed the discussion around user stories, asking not just what notifications to design but also why users would want them and how they should be able to take action. Figma prototypes were also used to support the conversation, helping to visualise workflows and test how notifications might appear and function in context.
What I took from this experience was how much easier it was to understand and relate to my own coursework. The second meeting in particular gave me a clearer connection to what I am currently studying, as the discussions around notifications, user stories, and prototypes linked directly to the kind of design thinking and research methods I have been learning in class. It was reassuring to see that the principles I am applying in my studies are also used by professionals, just on a larger and more complex scale. At the same time, the day exposed me to different methods and approaches that I had not yet considered. Watching how the team broke down problems, explored scenarios, and structured their critiques showed me new ways to think about user research and design. It highlighted the importance of looking at features not only in terms of how they are built but also why they matter to users and how they provide value. This perspective gave me practical insights I can take back into my own projects and build upon as I continue developing as a UX student.
The final meeting I attended with Andy was a more personal, one-to-one session with another designer that focused on unified user consoles. This was a smaller and more hands-on discussion, which gave me the chance to see how design problems are broken down in detail. The main focus was on identifying what features of a system are genuinely useful, what might not be necessary, and how these decisions are influenced by everyday user scenarios. The designer walked through how tasks are captured and represented, using both Miro and Figma to explore wireframe challenges and potential solutions. A key part of the conversation was about personalisation—how users can tailor their experience with an app or system so that it aligns more closely with their needs and workflows. What stood out most for me was the way case stories were broken down into their goals, values, user stories, and personas. I was introduced to the “when I… / I want to… / so that I…” framework, which helps clarify the user’s motivation behind every action. This approach made it easier to understand not only what users do but also why they do it, and how those insights can directly inform better design decisions. This meeting tied together many of the ideas I had observed throughout the day, reinforcing the importance of grounding every design choice in real user needs and motivations.
This session was a really valuable experience for me because it offered a more broken-down critique that was easier to follow and connect with. Both Andy and the other designer were open to suggesting new ideas and exploring different approaches, showing me how collaboration can generate multiple solutions to the same problem. By working through different user stories together, they demonstrated how these narratives could be used to solve design challenges and ensure that solutions were grounded in real user needs. What I found most useful was how straightforward the discussion felt. It wasn’t just about the technical side of design; it was about stepping into the user’s perspective and asking what they truly want or need from the system. This gave me a much clearer understanding of how user stories shape design decisions and how important it is to always frame solutions around the people who will actually use them.