This part of the no-code revolution will not be televised — or live streamed — but there's no need for FOMO. Because I was there for all the track 1 workshops, and I’m going to give you as exhaustive an overview of every session as I can.
A workshop by Jen Kramer, Lecturer at Harvard University Extension School
Anyone who didn’t intend to become a web designer or developer, but ends up doing design and development work, even if it’s not their focus.
In other words:
It’s your client, if you’re a freelancer.
It’s your collaborators, if you’re in-house.
Web design and development is going to become a necessary business skill, and the people you work with on your projects are web designers and developers too.
And it’s our job to help them do that (part of their) job better. To do that, we need to understand how people approach unfamiliar spaces like web design and development, and how we construct mental models to help guide us through the process.
When we set out on a project in an unfamiliar space, we go through what may become a 4-stage process that takes us from unconscious incompetence, and ends in conscious incompetence.
Many of our clients and collaborators are starting at step 1: unconscious incompetence. It's our job to guide them all the way to stage 4. Or at least 3.
A mental model is what the user believes about the system at hand.
Most often, users’ mental models are based in real-world experiences. Think of the wild old world of web 1.0, when most websites had what we called a “splash page.” These pages typically featured no more than a company name, logo, some supporting graphic, and maybe a tagline — plus a button to “enter” the site. That we already had “entered” the site apparently escaped us, and it was in part due to our mental model for the early web. That mental model was based on the real world: the splash page filled in for the facade and front door of a store, which we have to “enter” to see the “contents,” the products or services inside that store.
Building websites turns out to be hard for “accidental web designers” because the typical methods for building a website defy not only our mental models of what a website is, but also how building one should work.
Further, one of usability’s big dilemmas is the common gap between designers’ and users’ mental models.
Because when designers start to build a site, they typically — or at least should — have a strategy in place. They know what the site should do, how its success will be measured, and they know what content and functionality it needs. (Again, all of this should be true, though it often isn’t.)
But the accidental web designer? They often don’t have any of that in place. And yet, we, the builders of no-code design tools, keep insisting that the starting point of the design process is not the story, but the scenery.
In part because of most no-code website tools’ design approach, accidental web designers' mental models for websites basically amounts to: paint by numbers. That is, a template.
That means they have no idea of what the range of possibilities is, because the template seems to dictate what the output can be. Its shape, its form — they’re fixed. All they need to do is fill in the blanks. Right?
Unfortunately the seemingly simple task of choosing a theme or template is in fact a crippling moment for many accidental web designers. Because they don’t actually know how to fill in the blanks.
They don’t know that building a website isn’t in fact about picking a template. They don’t know that the real meat of building a site should start before picking a template, and should focus on:
In other words, they should start with storytelling: who’s the hero, who’s the villain, and who’s the guide . And they should always remember that those roles are fixed:
The villain is the problem you and your business solve. And the hero? That’s your customer.
You: you’re just the guide. The one who helps the hero — your customer — solve the problem that’s blocking their success. More on this below.
An understanding of the process that starts with the strategy and focuses relentlessly on the user.
Don’t start with the scenery. Start with the strategy.
Thankfully there are these things called frameworks that have been designed to help people define their strategy and story before they start thinking about the scenery. You can think of them as templates, actually — they’re just information templates, process templates, instead of visual templates.
Frameworks like the one Jesse James Garrett defined in his book The Elements of User Experience . Here’s a quick overview of that framework.
Wireframe! With annotations! Seriously folks: annotations are key tools for communicating priority, functionality, and content. Most of us non-designers don’t “speak wireframe.”
Now that you have a picture in your head (skeleton) and the content (flesh) …
Now you can pick your theme.
Another useful framework for this is Donald Miller’s "storybrand framework," which, as the name might suggest, revolves around the timeless, essential structure of stories, focused specifically on the people who bring our stories to life.
We can understand this framework pretty easily by applying it to a “mom-and-pop” restaurant website:
What role does your org play? You’re the guide. Your customer is the hero.
Phew , what a talk. Now let's move on to our next speaker.
David Adkin, cofounder at Adalo
David gave us a deep dive into how to get started building no-code apps for clients, offering insights into how to find good clients, what to look for in your clients, and how to estimate, price, and sell your projects to clients.
David evaluates potential clients’ viability as customers on a few dimensions, looking for positive signs and red flags in each dimension. See more red flags than you’re willing to deal with? Don’t take them on.
Agencies and freelancers have found years of success with 3 core methods of finding new clients, namely:
We dig into these and more methods in our article, " How to find freelance design work ."
For no-code agencies, these methods still work. But the nature of our toolkit introduces a few wrinkles:
Know that you know what to look for in your clients, it's handy to know who to look at before you start that more personal evaluation.
Advantage: because startups have a spectrum of design-related needs, you can be their full-service agency, delivering their branding, website, and apps.
Find viable startup candidates through:
Less technically inclined local businesses can still make great potential clients. Here's some tips for making local businesses into viable clients:
A great example of the last point in action is Mindbody , a scheduling app for both providers and customers of fitness services.
David then outlined the meetings you'll need to have with potential clients to both gather the information you need and make the sale.
Before your first meeting, look into:
While discussions about website features are relatively simple, revolving around:
The app space is a bit more complex, with additional considerations like:
While you're discussing features, keep an eye out for the following red flags, which are particularly challenging in the current no-code landscape.
Prioritize feature sets based on versions: Version 1 will have these features and take this amount of time, Version 2 will have these additional features and take this much time longer.
Again, be transparent and specific. Accurate timelines are key. Prioritize features that will actually get used (reviews are useless for an early-stage business with no customers … maybe).
Pricing: estimate hours and multiply by your rate. When feature creep happens, use the same formula. Most of David’s apps were $2–10K. If the rate is over 10, they probably need a more traditional dev shop. Don’t go under 2 unless you’re doing a rinse and repeat model, or you’re early stage. The more experienced and confident you are, the more you should (and can) be charging.
Just make sure to discuss how ongoing payments, whether for continued development or mere maintenance, is going to work.
Here’s your secret weapon for making the sale:
Make a quick version of some portion of the app to show them their future, i.e., the app they’re going to launch. Even creating a quick MVP of a single feature in action can help them understand not just what you can deliver, but the exciting possibilities of what their company is about to deliver.
Just don’t invest too much time in this development. Even the most powerful secret weapon can fail to sell some clients.
Once they’ve said “yes, let’s do it!” make sure you have a professional service agreement and a clearly defined scope of work. Even if it’s just an email!
Okay, so you’ve sold the client. Congrats! Now comes the real work. Here’s a few quick tips on that.
That’s right: there’s really just 3 types of screens in most apps.
As you start creating your screens, remember that they’re just the skin over a wealth of content (or data, if you prefer). So a big part of the app development process is, in fact, designing your database.
The essence of designing your database is relatively simple:
We dig deeper into this process and how it works with Webflow CMS in our article “ Why your design process should start with content .”
The key thing to remember here is to work incrementally. Build up your app feature by feature, but follow every single “feature complete” stage with a thorough round of functional testing. If you don’t make sure that each feature works as soon as you build it, you’re going to end up playing whack-a-mole — fixing bugs that seem to literally create other bugs, in other features. Because at that point, your app is a complex web of interconnected elements. Moves you make in one area inevitably impact the others.
During the app development process, and in particular as you near completion, you’re going to want to work closely with your client on your beta , launch , and iteration plans. In other words, plan out how you want the before, during, and after of launching the app to work.
During this process, you’re going to be switching between 3 roles: