Some background for context.
Contently's platform offers content marketing teams a more straightforward way to pitch, create, publish and track promotional content. Contently's popular product has evolved incrementally, and clients have patiently waited for the team to get to the much-needed DAM. 

What problems were clients experiencing?
Clients creating content need to include images and videos with their stories. The asset feature offered in the platform was an MVP and was ready for a significant improvement. The challenge was figuring out the best DAM experience from the user.
User studies provided a shortlist of features users need:
• To select/deselect/delete/add images per project.
• To access company-wide assets, such as logos.
• To bulk-upload assets. 

The internal challenge
The feature was a complex undertaking from both the front-end and back-end. It was a significant investment of time and resources. The risk of failing was considerable. So stakeholders needed a lot of assurances that whatever we built would work at launch.

Our approach
The project was an all-hands initiative. As UX lead, I was responsible for scoping out the discovery work and handing devs a mostly-right model. My goal was to get it to them a week early and use that additional time for pressure testing.
Discovery started with understanding how to align the experience to the user's context. So we learned from users by observing, surveying, and directly asking them to show us how they work. We captured user behaviors, thoughts, tools, and work styles. Then, when we had collected enough evidence, we began our experimentation.
Our early concepts were converted into code by devs, a time-saving decision. I set up two types of tests. One was an unmoderated task-based test. The other was a remote-moderated test. One of our UX researchers sat with clients while the team remotely observed clients interacting with the model on the screen, which is my favorite type of research to do as a team. It's always an eye-opening experience.
After every test, the team discussed observations, prioritized them into actionable tasks. Then, the Devs and Designers paired up to work through the iterations together. A quick technique we used was sketching out ideas on index cards. (see example at the end of the page)

The Outcome
Client-facing teams reported back to the team that users loved the feature. We also knew it was working based on the low number of complaint tickets reported to customer service.
Listed below are some examples of the deliverables used to build the experience.
Order of appearance:
1. UX Flows
2. Agile Wireframes
3. Initial UI Wireframes
4. Rapid sketching
5. Read more
1. UX Flows
A feature access point diagram that explains the requirements of uploading assets when the user is working from within the story creation workflow.
A overview of the UX flow and user-level permissions
2. Agile wireframes
An "agile wireframe" is a multipurpose deliverable. It tracks the evolution of the product features over time iteratively, the design shows the piecemeal user stories in context. Interactions and flow are added to telegraph pathways as they relate to user goals. The wireframe is version controlled and when the file is saved it overwrites the former deliverable in the ticketing system automatically. There were a few unresolved wrinkles we hadn't figured out, one was providing a notification system that was smart, only notifying people needing to know changes had been made. So we continued to do this via Slack and GitHub manually.
3. Traditional Wireframes (early phase deliverables)
The UI spec. Each revised draft of the spec was printed out and hung on the team sprint board. This help facilitate many discussions and quickly clarified misunderstandings and assumptions.
4. Rapid sketching
Once the system framework began to take shape, we needed a design process that would allow us to quickly patch up the loose ends of the UX. 
We worked from photos of sketches made on index cards. 
Once ideas were vetted, the cards were uploaded to their corresponding tickets. 
Fig. The sketches in this example show how users become aware of upload conflicts as well as how users learn how to avoid repeating the problem.
5. Read more
For more information about the product release, visit Contently's product announcement article.