How Ascender finds solutions through fluid specs.
Here at Ascender, we recently took on two unique startup projects. Our typical web site, email, banner, or CRM projects are certainly challenging and enjoyable, but the startup projects are usually a bit more fluid and give us opportunities to try new things.
From the perspective of the Ascender development team, these projects were particularly exciting to dig into. Our Creative Directors brought exquisite and detailed designs to the table, but we had some freedom to make creative UX choices during the build. With these custom platform projects, we document the basic Functionality Requirements and compose a base Technical Spec including data models, content validation, and extended functionality we’ll incorporate through plugins. But, we don’t cover every last detail…and that’s on purpose.
For example, consider a registration and login system. Seems pretty straightforward. But, should we require email address confirmation? Of course, that’s a must-have. Do we allow the user to log in for a period of time before they’re kicked out for not having confirmed their email address? Yes, otherwise it might turn away users eager to start using the app. We couldn’t display email addresses publicly on the site, so we needed to decide on usernames or real names. And with more of these open text fields come more opportunities for inappropriate user-generated content, so we added profanity filters.
For one of these apps, there were content creators and content consumers. About two thirds of the way into the build, we realized (through workshops with our client) that the creators ALSO want to consume other creators’ content. We initially had two separate data objects for the creators and consumers, so we needed to merge them while keeping the custom features for each group. The creators could now log in just like everyone else, but they had additional rights to create content. This, however, opened up questions about how each user’s settings functioned, how the registration processes differed, and what permissions both types of users had. We had a dozen email notifications going to both groups that needed to be updated and merged.
We LOVE these little roadblocks and challenges. We develop in a way that doesn’t paint us into a corner and allows us to stay nimble and change directions easily. We refactor code, time and time again, to make platforms run faster, more efficiently, and to DRY (“Don’t Repeat Yourself”) things up.
We build these custom platforms for big Fortune 500 companies–not just startups–so we’re always looking for ways to help our clients differentiate by going with a tailored solution.