I’ve been spending some time on Twitter lately (@gardennookdev), and I’ve noticed that there’s an inversion of knowledge between the people getting into a side hustle from a low to no code point of view, and those who are building up their (first) startup.
The early startup folks seem to have their process nailed down, to a point. They often iterate to improve their product in phases, get feedback, and then work on growing an audience for marketing purposes. (The ones who realize that marketing is critical to success anyhow. It doesn’t always come naturally)
The low-code crowd tends to pull from more creative professions – designers, artists, and writers come to mind here. The key difference is that one group moves comfortably within the tech space. The other group tends to vary. Automation makes a huge difference in running a business for both groups, but the low-code group has to work harder to reach for it.
(This has way more to do with immersion than skill, by the way. The low-code crowd also tends to grok that soft skills like marketing are critical to success much faster than the first group, so…it’s more that the two groups are balanced differently.)
For example, I’ve seen web design projects with large teams assigned, where all of the stakeholders gather to give their vision for the project, and a user experience expert would gather data on how people interacted with the project. They all have key points of view that need to be incorporated into the project. A design team is assigned to this project to manage this balance, coming out with a set of files that the developer can take over and implement. There is some iteration at each internal phase, but it moves steadily onward at the end of each phase towards eventual completion.
This process exists in web development. A lot of professional websites get built this way.
Here’s the problem with this approach. Unless you have a process and a team behind you, this process can turn into a trap for your professional vision. Unless you’re working with a team that tightly manages their discovery process…setting up a website outside of out-of-the-box web builders (Carrd, Wix, SquareSpace) can get complicated.
For solopreneurs, freelancers, side hustlers and small teams, trying to get things perfect on the first run can trip you up. Furthermore, it’s counterproductive to what you’re trying to do at the beginning – that is building an audience, seeing what works, and calibrating as you go. This, more than any other time, is the time to experiment.
Yes, you need to constantly be building and learning as you go. BUT you also need to be releasing content, updates, and information on your product (often service-based) service offerings. And who knows? You may not even be selling the same product three months from now. Do you really want to have to restart a ‘perfect’ website after all of that? For no-code people wading into the pond, the problem compounds itself – everyone has THE solution, and it takes a while to realize that they need to develop the best solution for THEM.
Full disclosure: I fell into this trap myself. (There’s a reason that startups stand behind the maxim ‘fail fast, often’.) For businesses that are scaling up, ready to go for that sleek, competitive look, it makes a lot of sense. I’ve been known to go on excited monologues over the potential of Gatsby and Frontitiy in the past; static site generation, oriented to a flexible array of content management systems. (The JAMstack vs WordPress monolith debate is one I’ve spent a good amount of time going back and forth on, although, unless you’re absolutely committed to Javascript, then it’s worth looking into getting a CDN (Content Delivery Network) and calling it a night.)
Here’s the thing, though. A lot of people with websites have one product. Maybe it’s a professional portfolio advertising their services, or a blog detailing a research project to followers. Most people start small.
Yes, it’s important to have a clean, professional-looking website.
Yes, it’s important for it to be responsive, accessible, and user-friendly.
But if you’re still developing your business? Figuring out your branding content? It’s better to start with something and grow it from there, than have nothing at all.
(side note check out Logology (not an affiliate!), by the way, they break down visual branding in a way that went way beyond my expectations for a web app, and their 5-day onboarding email tutorial on brand elements was a lovely low-stress entry into that space for me. You get a lot of space to get a sense of what works for you before investing.)
The perfection trap: waterfall to iterative design:
The idea of a website that is is complete at the end of a long-term, linear process follows what’s known as a waterfall design, and many start off a web project assuming that this is how the project will go down:
- Requirements
- Design
- Implementation/development
- Verification/testing
- Maintenance
Waterfall design is known to be sequential, precise, and deeply problematic when applied to projects that prioritize flexibility and speed. (It’s great for long-term planning, and user experience designers are coming back around to it as an aspect of their planning process.) Projects that only used waterfall would often find at the end of the process that if they missed the mark, they’d have to go back to the drawing board. Again.
And again.
This got incredibly expensive when you’re a huge company like IBM in the eighties and trying to innovate while young geniuses were coming up with innovations in their garages.
There are plenty of reasons that Silicon Valley runs on keywords like “fail fast and often”, but needing to get away from the rigidity of the traditional waterfall design pattern was a matter of survival. A lot of websites are built with the expectation of waterfall design. If design expectations or the scope changes during the process, it’s harder to course correct, risking a frustrating experience.
I won’t get into the history of iterative design, though you can check out a few methods here. A larger project can combine methods and pulls from the strengths of each, like the waterfall-agile methodology.
A small-scale project with a small team generally gets planned with these three elements:
- Clear expectations of what the design process is, and what it isn’t (clear scope);
- Clear checkpoints at every step of the design, development, and revision process; and
- An iterative feedback process that has a strong sense of what tasks to prioritize first, which counts as final polishing.
This article is available on Medium. To discuss content strategy or web dev, hop over to my contact page and drop me a line.