Ennely was a video editor assistant that helped content creators put together a first cut of the final video, in minutes.
Content creators with scripted videos, spend a lot of time on editing. With Ennely, they were free from mundane edits and quickly able to focus on details in video editors such as Premiere, Final Cut and Resolve.
Our team had identified 3 primary problems content creators typically face.
1. Files synch
Content creators sometimes use external microphones and multiple cameras. They needed a way to quickly put everything together.
2. Silences and filler words
Silences in between takes and fillers words like "um", "uh", "er", "ah" need not be there. Removing them can be a time consuming process.
3. Take groups
Creators have multiple takes of the same sentences. The process of picking the best can be a hassle.
How can we help users save time and export a rough cut within minutes?
We converted our key problems into opportunities to solve during the design process.
When I joined the company, the product was already in-the-making with mockups and semi-functional prototypes in place.
The agile team that worked on Ennely was consisted of 7 people:
- The CTO
- 1 product manager
- 1 designer
- 3 developers
- 1 researcher
All of them had worked together for a while, yet, they hadn't fully managed to hit that "sweet spot" where most of the UX problems are solved.
Many problems were vague and thus, needed "breakthrough" thinking.
Ennely v2 – A "kind of", new beginning
I took some time to study all the pieces of information shared with me. When I finished, I was asked to propose a new design. The success criteria lied on solving UX issues that previous versions hadn't fully succeeded in doing so.
Based on the product's requirements, the team's past learnings and user research that had been done, I conducted thorough research and identified the problems at hand.
I tried to see how other video editors on the market were handling things and although there were no similar solutions available, I took screenshots and put everything in Figma to have a clear overview. I wrote notes on anything that could help me find solutions to the problems I'd identified, in a comprehensible and transparent way.
Next, I started working on wireframes that could help us visualize the final product. I began working independently and when the time was right, I shared my wireframes and user journeys with the team in a coherent Figma file.
Because of the uniqueness of this new product, "stealing" from competitors was out of the question. There were no similar examples and we had no pre-established rules either! I was in uncharted waters and kept on "grinding" by consistently branching out all scenarios.
The user onboarding challenge
One challenge we didn't quite anticipate, was the user onboarding flow.
The goal of the product was to save the user (video content creator), time from mundane editing by removing silences and misspeaks but also, synchronizing audio from external microphones to multiple video files, but how would the user get there? How would they be able to import all the footage and audio tracks from different folders and have them automatically combined and ironed out?
To tackle this challenge, I designed roughly 7 user journeys from which, I picked 4. I then converted them to 4 different mockups / prototypes and asked 4 colleagues from the customer support team (and not from the design or development teams to avoid bias) to share their input.
Together with the product manager, we invited folks to share their screens, their hearts, and minds.
We tried to ask as open-ended questions as possible and repeatedly asked the questions we deemed important using different wording.
Based on the most preferred version and our findings, I further iterated and moved on. We had a few good ideas for improvement at that stage.
While I was on top of user journeys and wireframes, the dev team had focused mostly on getting things ready on the backend.
I then started working on the hi-fi mockups using bits and pieces (when applicable) of the existing design system and simultaneously, further improving and enriching it with new components.
In the process of designing the mockups, new challenges came to the foreground. For the most part, I was able to single-handedly deal with them. Sometimes however, input from the product manager and the dev team too, was necessary.
When that occurred, asking the right questions, helped heaps to minimize call durations.
When most of the mockups of the MVP were in place and the team had approved the Figma prototype, I emphasized the need for an HTML prototype.
Building a Figma prototype, is key. It's can be easily built and anyone can quickly get a glimpse of how things work. It is however limited in things like window resizes, typography rendering, button states, micro-interactions and animations.
Some of these "tricks" have been recently addressed with Figma's latest update, but at that time, they had not.
Even now, setting up window-resizes and micro-interactions in Figma take a substantial amount of time and when they're done, they're pretty much useless anywhere outside Figma. With HTML prototypes however, you can get something identical to the production app, even if the production app is a desktop app and not browser based.
The CTO, the product manager and the head of development, had no previous experience with a designer who could quickly turn a Figma file into an HTML prototype. In other words, they were reluctant to give their approval for me to start writing code and preferred having me engaged with the next design tasks of the list.
To be honest, I was also a bit reluctant too. Did I really want to "push" for something like this? It was a big responsibility to take up, especially with everything else I had on my plate; but I knew from previous experience, that we'd save valuable amount of time preventing the team to have unnecessary back-and-forth communication. I was sure of it.
And so, even though it meant more work for me, I stood up for what I believed was right. I got everyone's blessings!
Was it because I was convincing with my arguments? Was it because they really saw the opportunity? Was it because the timing was good with most of developers being already away on summer vacations and so I wouldn't "block" any developers? Looking back, I think it was a combination of all the above and eventually, it worked out for the best.
Together with a fantastic developer, it took us around a week to build a first version of the product. I did all the frontend and he, all the backend functionalities. The results were amazing!
The entire team was able to test the tool, and feedback flew all around: from designers, to developers, to researchers and managers.
In contrast with the Figma prototype, the HTML proto, gave the chance to the research team to further improve the algorithm of the product even before the dev team had a chance to build the app's window. Moreover, it boosted everyone's morale when they saw something functional early in the process. We got a sense of joy and completion and knew that what we were building, was something truly useful.
The months that followed Ι focused on:
- Designing, prototyping, and bringing all the functionalities of the MVP together
- Iterating on existing flows and assumptions
- Working on error states and overall copy
- Fine tuning the design for pixel perfect results on device/OS specifications
I continued moving autonomously and occasionally participated in dev team's standups. Sometimes I partook on ad-hoc calls to get insights from the product manager or assist engineers to bring about even better results.
While I was independent with my work, I never stopped being interdependent with my colleagues. Meaning that I always kept my work transparent in the same Figma file (one source of truth) with clear indications as to what I was working on.
Additionally, I pushed the changes I'd done on the HTML prototype to the repository so everybody could see the progress.
User research with beta testers
The day for the first beta launch was here! Windows and MacOS versions of the app were ready for testing! An exclusive group of content creators who wanted to actively participate in the shaping of this new tool, were standing by!
Together with the product manager we prepared an introductory email accompanied by a Google form link, asking again, as unbiased and as open-ended as possible, questions that would help us get invaluable feedback from our target audience.
The product, overall, was very well-received!
We got exciting comments which lifted our spirits way up high, but also, feedback regarding UI improvements. Some of them we had already planned and some we had not.
Then the news broke: our company, X, was being acquired by company Y, thus, effectively stopping all ongoing projects(!).
Looking at this project a year later, I love the way the team collaborated and delivered results.
If there's one thing that I'd have done differently, that would be to have spent more time on really polishing up the UI!
More specifically, If I could turn back time, I would have invested more time in:
- Rhythm of content
- The use of white space
- Illustrations and
- Color composition
I fell into the "hurry up" trap and delivered things that worked UX'wise but failed to aesthetically please the eye of the beholder.
Besides the beta testers' opinions I mentioned above, I'm unable to share the impact this project had on users because it didn't get much chance to see the "light of day".
Nevertheless, the tool was truly built in the best possible way (imho), including:
- User research
- User journeys → Iterations
- Wireframes → Iterations
- User research
- Mockups → Iterations
- Figma prototype → Iterations
- HTML prototype → Iterations
Of course, I've worked in teams that adopted different methods, styles, rituals and we still managed to deliver solid results, but there was something about this team that made all the difference.
Maybe it was its members rather than the methods. Maybe it was the timing. Maybe the chemistry we had with one another. Maybe it was the culture and the trust for autonomous work. I think perhaps, all the above.
If you fancy going through the actual design file, check out this Figma file!
The other product I helped design and prototype from scratch was ProjectWire. Fine tune your voice and add music to online calls using Spotify!
More specifically, it included the following features:
- Noise remover
- Voice EQ
- Voice leveler
- Voice deepener
- Background music with Spotify
- Overall better voice call
This tool was initially set to address issues that streamers, gamers & podcasters face. Later on we further expanded the user base to regular business users too.
Testing (internal validation)
When we concluded on what we thought to be the best user onboarding journey (we had eliminated all alternatives), we conducted concise user testing sessions with our colleagues.
- Enlisted colleagues from departments other than design and development
- Arranged meetings
- Made them feel at ease
- Asked them to try out possible user journeys while sharing their screens, hearts and minds
- Asked them open ended questions
- Rephrased and re-asked important questions
Based on the feedback we received and our overall work on the project, we changed the look and feel quite a bit.
I realized that we needed the window to be smaller so it could be side by side with the meeting app.
Try out the clickable HTML prototype below →
ProjectWire clickable prototype
ProjectWire is a simple-easy to use product that delivers amazing results.
Working on this project was very satisfying for the entire team.
Last but not least
I was also engaged with the successful family of products, ERA Bundle.
Introducing ERA Bundle 6
The fastest audio clean-up solution for creators, is without a doubt, ERA Bundle.
Available for all major audio/video editors (Premiere, After Effects, Audition, Audactiy, Avid Pro, DaVinci Resolve and many more) ERA Bundle is hands down, the EASIEST solution to tackle all the audio problems content creators routinely face.
Voice Leveler, Rever Remover and Voice autoEQ were only a few of the tools I helped design and improve →
Audio Clean-up Assistant
Audio clean-up assistant is without a doubt, one of the coolest apps of the Bundle.
As its name implies, it's a tool that helps users automate the entire process. Roughly 15 seconds of listening is all it takes for the AI to work its magic 🪄
Helping users save time by auto-detecting issues in their audio track and then allowing them to finetune it as they require, had earned accusonus an impeccable reputation in audio engineering industry.
Audio clean-up assistant
To sum up
Working at accusonus / Meta gave my colleagues and me the moral satisfaction we yearn in our jobs.
We were a close-knit team with complimenting skills and together, we delivered exceptionally good work.
Meta Reality Labs
Senior product manager - Valia Lekka
Product manager - Alkisti Katsantoni
Senior designer - Chara Konstantakopoulou
Digital marketing manager - Chris Anastasiades
Lead software engineer - Maria Kourousi
Software engineer - Thanos Nikopoulos
Honorary mentions (in order of appeareance)
Lead R&D engineer - Foteini Fotopoulou
Product manager - Stelios Bournous
Lead software engineer - Charalampos Tsimpouris
Software engineer - Frini Paschou
Product manager - Ioannis Ntouskos
R&D engineer - Dimitris Koutsaidis
Customer experience manager - Angeliki Tzigkou
Software engineer - Nikos Skiadas
Head of software engineering - Thanos Kostis
Content specialist - Spiros Tselepis
Lead software engineer - Kostas Karamitas
Product manager - John Valasis
Administrative assistant - Georgia Eleni Tigkinagka
Senior software engineer - Fiore Martin
QA specialist - Charalampos Koutsougeras
Marketing lead - George Psistakis
Software engineer - Konstantinos Gkanatsios
Software engineer - Spyros Siannas
Software engineer - Haris Renieris
Marketing operations specialist - Vasilis Bachras