Required Fields Revisited Written by Edward Hewitt in Concept on June 13,2019 It's always tempting to say 'yes' to a feature request - especially when you can understand the use cases and when it is popular among existing users - but it comes with the risk of losing sight of what you want your product to be in the long term. In the case of Required Fields, we understand why many of our users want it, but it is an example of when we truly feel that we know better. We know that it could help some developers, but we also know that it will hurt all of our end-users. We are a company that openly asks our users to give us feedback and deciding when to say 'no' is never easy, but we have to trust our vision. We hope that this article will help developers frustrated by the fact that we aren't implementing Required Fields to understand why we've made that decision. If you aren't a frustrated developer, well, we're happy to hear that, but this might provide useful insight into how we choose to use feedback and feature requests and why we would take the risk of saying 'no'. Vision, not arrogance Feedback isn't ignored just because it isn't acted on Required Fields is one of our most common feature requests. It's so common in fact, that a few months ago we decided to publicly address it in an article called Unpopular opinion: why required fields lead to terrible UX and it was...unpopular. This didn't really surprise us. To go a little inside baseball on you, every two weeks we have an all-hands meeting in which we discuss feature requests - and it is safe to say that Required Fields almost always makes its way onto the list. It's not that we're ignoring you. It's not that we aren't aware of the use cases or the reasons why some of our users will want to have them. It's just that we have a vision for our product that means that Required Fields go totally against how we want our users to experience Prismic. The importance of 'No' Saying 'yes' to the feature request would be an easy win for us. It would be fairly straightforward. It would make a lot of users happier. It would save our Customer Success and Education teams a great deal of time. But it would be a short-term decision that would mean that we would risk losing sight of our long-term vision. Keeping that vision means that we sometimes have to make the difficult decision to say 'no'. It's not a decision that we take lightly, but it's a decision that we want you to understand. Now, reading that may have gotten a reaction out of you. It might sound arrogant and, in a way, it is. But it isn't arrogance born out of the fact that we think we always know better than our users, it's arrogance born out of the fact that, in this particular case, we are certain that we can't provide the user experience we want whilst also providing a feature that some of our users feel that they need. And, quite frankly, we think that end-user experience is way more important than the difficulties caused by not having Required Fields. So, why do people want them? Our last article did a good job of discussing why people want Required Fields, but it has been a few months, so there's nothing wrong with taking another look at why users think that they could be so useful. Whenever we are reviewing feature requests, we always make sure that we have a full understanding of why our users feel that they need it. Does it already exist? Are we not doing a good enough job of explaining how to use Prismic? Is there an easy workaround? Have we overlooked something? Each new request requires full care and attention and user feedback has an integral role to play in how we plan our product roadmap. In the case of Required Fields the need seems quite simple. Null exceptions Bill Gates once said that you should hire lazy people to do difficult job because a lazy person will find an easy way to do it. Well, it seems that Bill Gates would hire a lot of our users (if you need a reference for your CV, we will be happy to provide one). But we get it. You put in all of the hard work to build your website and you want to have an easy solution that makes sure some content creators doesn't come in and break everything. If you're missing data in parts of your website that need it your page can become unavailable. A few missing characters can turn a beautiful website into an error page in a split second. I get it. I'm a content creator. I've done it. And I've seen the look on the faces of my developers when I ask them why the website has suddenly crashed. Trust me, the developers here are lazy as well and, even though we see ourselves as a CMS built by developers for developers, we also place a high value on end-user experience. Ensuring that content creators have the freedom and independence that they need is important to us. Choosing Prismic means that you have a CMS that allows you to build your website how you want. Choosing Prismic also means that your content creators get to manage your website without having to rely on you for every update. We're here to help you be lazy...just not when it comes to Required Fields. So you might still be asking yourself, I get all of that...but why would Required Fields stop that? Well, if you're a developer that wants Required Fields all you are saying is that you want a CMS that moves a pain point from the developers to the content creators. Maybe that sounds great to you, but it isn't part of our vision. End-User Experience Do you know how many times I have saved my work while writing this? We don't want Prismic to be a CMS where you just add your content, we want it to be an editing experience where content creators feel confident that they can write, edit, save, and publish all in the same place. If you add Required Fields, you kill that experience. We've all had that moment when we've been filling in an online form and you either save or submit only to be told that you missed a required field and that you now have to fill it all in again. Imagine that happening after you've just spent hours working on that piece of content that you REALLY need to publish. Nobody likes to start again. A website going down is bad. Losing all of your work is worse. OK, but we can fix that, right? Yes, we could make it so that it is impossible to publish something without all of the Required Fields being filled. That would prevent content creators from losing their work, but it would also mean that they miss out on one of Prismic's best features - Previews. Previewing content is an invaluable part of the publishing experience. Once you've tried it you will never go back. I've saved this article a dozen times while working on it and, each time that I have, I've looked at the Preview. Every time I add a new media asset I Preview it. Every time I add a new section, add a headline, I Preview it. When I want to get feedback during my writing process I send them the shareable Preview link. Yes, feedback, that dirty word again. So, when you are wondering why we don't want to add Required Fields you need to think about the full experience we want to provide. We didn't make this decision because we don't care about your feedback or because we are too lazy to work on our product. We made the decision because it would really hurt how content creators can use our product. But keep giving us feedback I'm hoping that reading this article will make you understand why we have made a difficult decision that we know will frustrate some of our users, but there is also a very good chance that it will make you come to a very difficult conclusion: Why would I ever give them feedback again? And that is a fair question to ask yourself. But, trust us, we want to hear from you. We really do consider all of our user feedback and feature requests when we are planning our roadmap. And we really do make a lot of changes and updates as a result of what we hear from our users. That's why we speak so openly about the decisions that we make. That's why I'm writing this article. That's why our Support and Education teams take the time that they doe to understand every user that contacts them. And, we hope, if you are a Prismic user, that's why you will have seen a number of new features and updates that specifically address issues that our users have had. But we can't listen to it all. We can't have a clear vision of what our product will be whilst also incorporating every piece of feedback that we get from our users. A camel is a horse designed by committee and we want a CMS that knows that it is a horse. We're not alone in this approach. We think that most great products are the result of a clear vision. That vision needs to be adaptable, but it can't be so flexible that it loses sight of what it is trying to achieve. Sometimes you have to say that you think that you know better. Hopefully, we'll be right often enough for our users to trust us. We hope that you don't see us as arrogant. We hope that you will continue to give us your feedback. And, most importantly, we hope that you will continue to trust our vision.