Best Practices for Solution Design (For Video and In General)
Renee Dvir
When I first got my job as a solutions architect at Kaltura, I was ecstatic about the title. “Solutions architect”. You tell me your problem, whatever it is, and I will figure out a solution for you and then help you come up with a real life plan to implement it. In the years since then, I’ve worked with many different customers to create their video solutions in a variety of different fields. Coming up with a good video solution takes some creativity and collaboration. When done correctly, it will ultimately lead to easier workflows, more adoption and engagement, and a happy relationship all around.
It’s not always easy to know what to ask for in a solution. The key to successful solution design is asking the right questions. Having worked on many different types of video projects and leaning on my life experience as a “solution architect,” here are my best practices for discovery, design, and delivery for an optimal solution:
1.Why – The Most Important Question
If I could get a t-shirt that said the word “WHY” on it, I would wear this to every pre-sales, discovery, and scoping meeting I go to.
From the start, when you choose your solution in the sales phase, it’s important to understand WHY you want a video solution. Are you replacing a different one that isn’t working for you? Are you starting to increase usage of video because you recognize this is the present and the future? Are you trying to unify all the different grassroots video solutions your organization is already using? Solidifying the “WHY” at an early stage of the solution design process will make communicating this vision internally and externally much easier, and create a clear path to implementing this vision.
When you get down to actually designing a solution, the “WHY” is equally important. Rather than communicate a list of requirements, give a list of needs. For example, someone may say,“We want to enhance the default set of metadata so we can customize a different set of values for every department.” We can do that, but unless we know the goal, it might not actually solve the problem. So the question is, “why?” This may turn into “We need to increase the searchability and visibility of our content”. Once the reason for a request is clear, solutions architects can make use of the experience we have with other similar requests and our knowledge of existing capabilities to achieve the actual goal.
-
Keep It Real – and Tell a Story
When describing an existing workflow, try and stay away from vague: “Content is ingested automatically and then placed in the correct location.”
What does that mean? How automatically? Is there an integration? Is it magic? And who is placing this in the correct location? Who knows what the correct location is? How?
Instead of a generic workflow, tell a story – and give all the details:
“Video is uploaded to a folder and then automatically picked up by our legacy solution via an API integration. Pete, the admin, goes in, looks at all the new videos, checks the user name, and places the video in the right page using embed codes. Poor Pete is a real bottleneck for all our video needs and spends so much time doing this…”
Keeping it real not only simplifies, but also gives a view into other possible pain points that may seem impossible but are actually easy to solve.
As a sub topic of this, it’s highly recommended to use visuals. Draw a picture, create a diagram, map out your existing workflow, or illustrate a real problem by screen sharing. A lot of meetings can’t be done face-to-face these days. But when you have something in common to look at, everyone involved gets a better idea of what we are trying to do.
-
Creativity, Flexibility
Both are big words. But at the end of the day, a good solution requires creativity from both sides in order to come up with a good solution. You also need flexibility on both sides in order to accept and deliver it.
-
Anything Else?
This is the second-most important question, after “WHY”. You’ve planned the big picture and made sure all the components make sense and will work together. This is the time to think if there are any other details that might help or harm this. “We also have a security team that needs to clear any content before its published” or “Our company has a delivery freeze between September and January” may seem like details, but the earlier in the solution design process these types of things are communicated, the better. That way, all these kinds of requirements can be taken into account.
Creating and planning a solution that will work perfectly can be challenging. But when the teams work together and communicate as openly as possible in the solution design process, it’s so much easier and more fun to work towards that goal. Ultimately, putting a solution in place that will delight your users and be easy to manage is in everyone’s best interest. Let’s work together to do that.
