Vasilis Kolip

Ennely overview

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.

Problems

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?

Goals

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.

One of the early versions

The team

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.

Some rough sketches that led me to the wireframes that followed

User flows covering various cases

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.

One of my early wireframes

...And its iteration

Early version

Early version alternative

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.

Possible user onboarding journeys

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.

Mockups

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.

Figma and browser preview side by side.

Mockup of the import screen

Part of our design system

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.

HTML prototype

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.

Queued for import files

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.

Synch buckets

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!

Successfuly synched all files

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!

Ennely overview screen

Re-arrange drop

Leading silence edit

The entire team was able to test the tool, and feedback flew all around: from designers, to developers, to researchers and managers.

HTML prototype

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.

Iterating

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.

Export screen

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(!).

In retrospect

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
Iconography
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.

Ennely's impact

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
Repeat

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!

ProjectWire

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

The problems we were trying to solve

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.

One of the initials UX personas

User onboarding journey

Early wireframe

...and its iteration

One of the light-themed initial designs

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.

Voice optmization

Background music

Dark version experimentation

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.

ogmacast is ProjectWire

Last but not least

I was also engaged with the successful family of products, ERA Bundle.

Introducing ERA Bundle 6

ERA Bundle

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 →

Voice Leveler

Reverb Remover

Voice autoEQ

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.