My team recently launched (and ended) the Beta phase of our content strategy application, Blaze. With this limited Beta, we hoped to get some insights on how different users perform a content audit, as well as learn some things about how they use our application in general. The goal of this to further our mission to provide high-quality tools to content strategists in order to make their work faster, easier, and more pleasant.
Of all the insights from our beta, two big lessons emerged:
- – When it comes to software interfaces, “intuitive” is a relative term.
- – We are moving too slow in our development.
“Intuitive” is a relative term.
“Intuitive” is a word that shows up quite a bit in the software industry. In general, “Is it intuitive?” asks “How easy is it to use your product?” We have put some time into thinking about the users and how to make it easy for them to transition from spreadsheets (ugh) to a new interface. For the most part, we have done a good job adding the features they need. Our content matrix has been a bright spot providing the flexibility we knew the users would want. One new feature that came from the Beta program was predictive tagging, which means the matrix interface would anticipate what tags users would type based on earlier entries. After our Beta users requested this feature, our team was able to add it to the matrix interface and make the task of tagging content much faster.
However, one area in which we lacked sufficient foresight was crawling. Crawling is the ability of the application to move recursively through a website and capture data about each individual page. There are so many ways to crawl a site that it’s difficult to account for them all. We have worked with our Beta users (Thank you to any participants reading this!) to try and understand how they think about crawling. We’ve learned from them and we will apply that education to Blaze in the near future. We will simplify, then we will simplify more, and then simplify again.
We are moving too slow.
During the Beta we became aware of some significant process shortcomings that were slowing us down. I’ve worked on software products before, and streamlining the deployment process is essential to any product’s success. That starts with your code repositories and branching strategies. When you have a team of developers all working in the same code base you have to make sure that they aren’t tripping over each other. Everyone must be rowing (er… coding) in the same direction. We didn’t come to a solution immediately, it took a few iterations, but we have it now. The part of the credit goes to the Dev team for understanding the goal and making it happen.
The other half of the DevOps movement involves our IT team, who handle setting up our infrastructure and automating our deployments. Much like branching strategies in software, there are numerous possible deployment solutions. We were able to try a few configurations and then make the call on what the best would be for our users. I’m proud to report that our team has accomplished our goal to be able to deploy new software with zero downtime for most (if not all) deployments. If we do everything right, you won’t even notice it has happened.
Onward to Release!
Our mission is to serve the content strategists out there by giving them the best tools available. We will continue to learn and we will get better with every iteration. Many thanks to the content strategists who participated in the Beta program and helped us on our mission.
Blaze is almost ready for release! You can get access to your free 14-day trial after signing up for a live demo on our website.