Reely
Product Update
UX/UI Design | Jun 2021 - Jan 2022
Designing “Version 2” of the Reely AI SaaS Platform
Description: Reely is a SaaS platform, utilizing proprietary AI to automatically identify, cut and distribute sport and esports video clips. Version 1 is currently operating, and this case study follows my journey on the design and development of v2.
Role: Sole UX/UI Designer
Tools: Adobe XD, InVision, Adobe Illustrator
Responsibilities: I was brought onto the Reely team to design v2 of their platform. This required familiarizing myself with v1, strategizing with the team to decide on feature requirements, updating the UI, defining UX/UI best practices and ensuring development adhered to our design requirements.
Final Screen Highlights
Why a Version 2?
New GUI: Aesthetic updates to align with UI/UX best practices, accessibility guidelines, accommodate new features and increase visual appeal.
New features + upgrades: Expanded API & user management, new onboarding process, automated social-sharing tools, automated and sponsor-ready video package options, custom package "Reel Builder" tool , new "Live Stream Monitor" and Challengermode esports platform integration.
(Plus additional backend/AI implementations that I was not personally involved with).
Adding revenue streams, setting stage for consumer offerings: Reely v1 and first phase of v2 will remain B2B-centric, but creating this foundation on the shoulders of v1, and adding the new specified features will broaden the company’s revenue model and prepare Reely for B2C.
Re-evaluating the Bones
Database Structure
I collaborated with the CEO, CD(data)O, and internal software engineer to revisit our existing database schema, and reevaluate what data should be captured, stored, and surfaced to the user.
I used this as a guide when designing inputs and outputs in the UI, leaving dev notes to map them to the appropriate ID in the database.
User Roles + Permissions
It was key that account types, user types, and the permissions available to the combinations of these two categories were clearly defined.
The results would define our various user and customer types, and from there we explored the most important user tasks for each of them.
• It was my responsibility to document these tasks, craft sitemaps for each user type, and ensure each screen on the sitemap was designed.
Approval process + pipeline for UI/UX development of screens
Iteration Examples
(Click to expand)
Iterations over time for the Livestream Monitor feature. First image is the original “v1”, and proceeding images are iterations I worked on from feedback I received.
(Click to expand)
The home page was a new concept for v2, so I helped develop the screen from concept, wireframing to final hi-fidelity mockup.
Style Guide
While honing the visual direction of the Reely product update I started creating style guide sheets. The goal is to expand the guide into a robust Design System by collaborating with our developers, and then use this as a tool to assist in scaling the product.
This process also aided me when I would occasionally design assets for branding and marketing initiatives.
(Click to expand)
(Click to expand)
(Click to expand)
(Click to expand)
Bringing V2 to Life
Working with an outsourced dev team
A development team was outsourced to build v2 based on our designs and requirements. My responsibilities included being the point of contact for the dev team, and I frequently acted as a liaison between their team and ours. I was responsible for ensuring that v2 was being built according to our specifications and to resolve any discrepancies.
Lessons Learned
Communication and Accountability
Communications were a struggle throughout the project. Our outsourced dev team were utilizing outsourced dev teams of their own, and several issues were causing lines of communications to break down. This caused confusion in the development/QA stage.
My Takeaway
Set a clear and defined communication plan from the start with all accountable parties.
Ensure all documentation (including my designs, explorations, artifacts, etc.) are accessible and visible with clear notations. I also learned including clearly defined goals and success criteria to support the intention of each document/artifact is very important.
Preparations and Expectations
Due to the early departure of our Head of Product, there was a scramble to prepare materials and technical requirements. I was not trained in front-end development, so I had to work as closely as I could with our internal team to best communicate technical requirements in my designs. This also left expectations unclear and ambiguous, and took extra time to resolve.
My Takeaway
This project drove home the value of the designer-developer relationship. Also, having technical specs prepared and extremely clear guidelines on the work that needs to be done.
I’ve since started doing research on Functional Specification Documentation, and exploring learning how to code to provide support to front-end devs.
Having user stories and journeys based on research would have helped remove some ambiguity from the project. Ideally I would have had time to execute user interviews and testing.
Thank you!