
wesearch
EMERGING MEDIA LAB @ UBC / WESEARCH
Making Academic
Research Conversational.
Project Overview
The Challenge: Academic research papers are often dense, filled with technical jargon, and difficult for non-specialists to understand. This creates a significant barrier to knowledge translation, preventing valuable information from reaching a wider audience. The core problem was to bridge the gap between complex research and everyday understanding, making it more accessible and digestible.
The Solution: WeSearch is a proof-of-concept web application designed to democratize access to academic knowledge. Using a generative AI model, it provides a real-time voice-enabled chat interface that allows users to ask questions about a research paper and receive immediate, easy-to-understand answers, eliminating the need to read and interpret the entire document.
My Role: As the UX Designer on the Research Accessibility Team (R.A.T), my primary responsibilities included:
Leading user research and synthesizing insights to define project scope and user stories.
Designing the user interface and user flows, from low-fidelity wireframes to the final high-fidelity prototype in Figma.
Conducting usability testing and iterating on designs based on user feedback.
Collaborating closely with the development team to ensure design feasibility and a seamless user experience.
Team: The Research Accessibility Team (R.A.T), MDIA 470 course.
Timeline: April 2025
Tools: Figma, Miro, Notion
The Problem
The "we-search" project was born out of a critical observation: academic knowledge, while foundational to progress, is often siloed and inaccessible. The challenge wasn't just about providing information; it was about changing the way people interact with complex documents. We identified several key user pain points:
Cognitive Overload: Users are intimidated by the length and complexity of research papers.
Time Constraints: Busy individuals don't have time to read lengthy documents to find specific information.
Language Barriers: The specialized language used in academia creates a steep learning curve for those outside a specific field.
Image Suggestion: A simple infographic or a series of icons illustrating the core user problems (e.g., a frustrated person in front of a giant book, a clock icon for time constraints, a paper with an 'X' over it).
My Process
My process was rooted in a user-centered design approach, focusing on empathy and continuous iteration.
1. Research & Discovery
Our initial phase involved understanding our target users and their needs. We created user personas and user stories to document user goals, motivations, and pain points. We focused on non-academics, students, and professionals who needed quick access to information.
Key Findings:
Users are often looking for specific answers, not a full summary.
The "ask a question" interface is more intuitive than a search bar for abstract topics.
Accessibility features, such as voice interaction, are critical for a wider range of users.
Image Suggestion: A screenshot of the Miro board with user stories and personas, a low-fidelity sketch of the initial user flow, or a photo of a whiteboard with research notes.
2. Ideation & Design
Based on our research, I began the design process, starting with low-fidelity wireframes to quickly explore different layouts and user flows. The key was to keep the interface simple and intuitive. The "voice chat" feature became the central element of the design.
Key Design Decisions:
Conversational UI: The chat interface was chosen to mimic a natural conversation, reducing the intimidation factor of traditional search.
Single-Document Focus: The design was streamlined to focus on one document at a time, preventing user distraction.
Minimalist Aesthetic: A clean, modern UI was created to ensure the focus remained on the content and interaction.
Image Suggestion: A side-by-side comparison of a wireframe and the final high-fidelity mockup for a key screen, showing the progression of the design.
3. Prototyping & Testing
I created a fully interactive high-fidelity prototype in Figma to test the design's usability. This allowed us to validate our assumptions and identify areas for improvement before a single line of code was written.
Usability Testing: We conducted informal usability tests with a few target users. Feedback was overwhelmingly positive, particularly regarding the ease of use of the voice chat feature. One key finding was the need to improve the responsiveness of the voice chat, which led to a collaborative solution with the development team.
Image Suggestion: A screenshot or short GIF of the Figma prototype in action, showing a user interacting with the voice chat feature.
The Solution & Its Impact
The final product is a functional prototype that successfully demonstrates a new approach to knowledge translation. It directly addresses the problems identified during the research phase, creating a tangible impact:
Bridged Knowledge Gaps: By allowing users to interact with research papers through natural language, the application makes complex topics accessible to anyone.
Streamlined Information Retrieval: The voice chat feature allows users to get specific answers instantly, saving significant time and effort.
Provided a Tangible Proof of Concept: The successful development and deployment of a working prototype, complete with a public GitHub repository, proves the viability of this innovative approach.
Image Suggestion: A clean, high-resolution mockup of the final product UI, showing the main screen with the voice chat and the PDF viewer. This is where you would use the 1756798535881.jpg image.
Challenges & Learnings
This project presented unique challenges that forced me to grow as a designer. The most significant one was the seamless integration of a real-time API into a user-friendly design.
Challenge: The development team faced a slight delay in the voice chat's connection to the backend API. A loud environment also interrupted the voice chat too much.
Solution: I collaborated with the developers to design a visual and auditory cue (e.g., a "connecting" animation and a clear "listening" state) to inform the user of the voice chat status. This managed user expectations and created a more robust user experience. We also documented the technical limitations for future iterations.
My Learning: I learned that a designer's role extends beyond the visual interface. Effective communication and collaboration with developers are crucial to overcoming technical constraints and delivering a functional, delightful product. I also gained experience in designing for edge cases and managing user expectations in a real-time application.
Conclusion
The WeSearch project was a valuable experience that allowed me to apply my UX skills in a real-world, innovative setting. It demonstrates my ability to conduct thorough research, translate insights into intuitive designs, and collaborate effectively with a multi-disciplinary team to deliver a product that solves a meaningful problem.
My work on this project not only led to the creation of a functional and impactful prototype but also provided a clear framework for how we can continue to make knowledge more accessible for everyone.
Next Steps & Future Opportunities:
Adding a discussion section to the Article Profile page to foster a community around research.
Developing a mascot or visual identity to improve brand consistency.
Exploring the integration of additional generative AI models to provide more nuanced responses.
Conducting formal, large-scale user testing to validate the solution on a wider audience.
Roles
Timeline
4 months
UX Researcher
UX Designer
Research Accessibility Team
Team
The Problem.
1
Overview
Academic papers are dense, jargon-heavy, and honestly just slow to get through, even when all you need is one answer buried somewhere in there. WeSearch is a proof-of-concept voice chat interface that lets you just ask the paper your question and get a real answer back, instead of reading the whole thing cold.
Research shouldn't require a research background.
Three things kept coming up, over and over: people are intimidated by how long these papers are, they don't have time to dig through one just to find a specific detail, and a lot of the language is written for people already inside the field, not for anyone else. And this wasn't us guessing. We ran a discovery survey first, reaching 98 general-public respondents, before any of us touched a single design.
As a team, we landed on a conversational interface instead of a search bar - for something this abstract, asking a question felt more natural than typing search terms into a box, and it took away a lot of the intimidation factor our research had surfaced. From there, the UI side of the team took that into low-fidelity wireframes and a shared design system, focused first on two core pages: the homepage and the article profile page.
My own focus was usability testing. I designed the test protocol myself and ran all three sessions, watching real people complete tasks on the prototype while thinking aloud. People genuinely responded to the voice chat - that part landed. The clearest, most specific finding: people didn't realize "download" and "read full text" were clickable links at all. I recommended icons instead of plain text, and the team shipped that fix directly.
This never went live, as it was a proof of concept for MDIA 470, not a shipped product. Part of that was restrictions around University AI policies that we were slightly bumping into, which unfortunately meant a lot of pivoting and extracting the most out of this project as we could knowing it could not go live. But what it did prove is real: a working, interactive prototype, a public GitHub repo, and actual validation, even if informal, that people found asking a question genuinely easier than reading a paper cold.
Honestly, the biggest thing I took from this wasn't the interface, it was the team. This was the first time I got to design inside an actual cross-functional structure: a PM, developers, other designers, real constraints I didn't get to just decide away. It was the closest thing to a real job simulation I'd had at that point - designing for real people, inside real limitations, not just my own assumptions about what they'd want.
I also learned that not every problem research surfaces is yours to fix. The API delays and noise sensitivity weren't something I could solve directly, but making sure they were documented clearly, not just noted and forgotten, was still real, valuable work. That's a different kind of contribution than shipping the fix yourself, and it's just as necessary on a real team.
I helped shape this project from day one - sketching the team's first user flow before any UI work began, and helping design the questions for our discovery survey. We were asking questions about how people perform research - what tools they use, what they struggle with, and what techniques they use that were beneficial. Once results came in, I was the one who turned raw responses into metrics the rest of the team could actually act on.
Lets create together.
Always love to chat - send me an email or connect with me on linkedin!
connect
about me
fun stuff
Alexandra
made with 🫶 & gratitude in Vancouver, BC
© Alexandra Smart 2026


The Process.
Survey Findings
2






The Outcome.
3
The Reflection.
5
Final Designs
4
Link to Figma prototype: https://www.figma.com/design/5S0B5NdR8Zf97Ftx7wSub5/Prototype-%231-(Home-page%2C-Article-Profile%2C-User-Flow%2C-etc.)?node-id=0-1&t=mzXw61euJKyQieI2-1
Link to user stories on Miro: https://miro.com/app/board/uXjVLpv0VnA=/?share_link_id=684990142771








