April 11th, 2024, posted in learning
by Adelina
Every software development company has their own preferred workflow. These are adjusted to the kind of clients they work for, the technologies they use, the size and complexity of their team, and how lengthy or complex the software they build is.
In this field, there are 2 types of approaches one can take when building a software product:
- A development-first approach, where the developers make all important UI and UX decisions themselves, and the app goes straight into development once the main features and requirements are fully mapped out.
- A design-first approach, where all app user flows are mapped out and the entire app is designed by a UI/UX designer. Once this stage is complete, the app goes into development, and all features will be based on what’s in the design.
Clearly, what sets these 2 apart is the stage that the app building process begins with, either design or development. The design-first approach puts a bigger emphasis on product discovery, on clearly mapping out the app scope, while a development-first approach skips most of that and relies on a more general app scope, and the developers figure out flows, UI and other specifics.
Here at UPDIVISION, we’ve taken a design-first approach, which has proven to be a lot more efficient in the long run, and which leads to better software products. And when we say better, we mean apps that serve their intended users as required, which help them achieve goals or complete certain tasks.
So in this article, we’re going to tell you why we prefer this approach and why it’s better than going development-first, based on our own experience creating software products.
What is design-first development?
Let’s start with the basics. What does design-first development even mean? Well, when creating a new web or mobile app from scratch, there are a few steps we go through (we go more in depth about our process in this article). Mapping out the app’s flows and features is the first and most important step, this is also known as product discovery.
During product discovery, especially when creating SaaS software, we hold meetings with the app stakeholders or product owners to discuss the app’s requirements together. We usually start off knowing what the stakeholder’s business needs are and, broadly, what the app should do. So through these meetings, we sit down with the stakeholders and brainstorm key app info such as user types and main features, and we discuss the best ways to bring those features to life in ways that best serve their intended user types.
This is where we do user research, and with business-facing software we rely on the product owners for information, especially with more complex industries where you can’t find data simply on the internet. When it comes to customer-facing apps, the best approach is to find potential app users and hold interviews about their day to day life to try to find the best ways to include the app in it. We go more in depth about user interviews in this article.
After we clearly map out app requirements and user types, we head into the design process. Either using visual branding guides from the app stakeholders or creating something from scratch, design-first development starts with full app designs - where “full” means covering all user flows in that app. The designs will always follow key development rules to ensure codability. For instance, one of the frontend frameworks we use the most is Tailwind. And while designing apps meant for Tailwind, we follow a series of rules we described here.
Once the design is complete, we usually go through all the pages with the app stakeholders, and we make sure they fit the requirements we discussed together at the beginning. In the case of customer-facing apps, this is where A/B testing or focus groups would take place, in order to test how well the app could serve potential users, before committing to code.
After the design is finalized and approved by the stakeholders, we write user stories based on them. After these are done, developers jump in to estimate every feature within the app, based on the user stories. This will lead to a clearer image of how long it will take to implement the project. Of course, development itself starts after this stage.
What is so good about design-first development?
The biggest difference between these 2 approaches, as their names imply, is what you’d start with when creating a software product. You can’t design blindly or based on just a list of major features, so starting with design means having to map out the app in more detail, including every user flow.
This means that you’d take time to truly understand the app users, to brainstorm and to figure out how to create the best user flows for those users. The app scope is clearly mapped out before going into development, which means that the developers can create accurate estimates on how long their work would take. Business-wise, that’s a favorable approach as you’d know off the bat how much you’ll need to pay for the most lengthy chunk of work.
Estimates and financials aside, one of the biggest advantages of design-first development is that you get a clear look and feel of the app before it even goes live, which is a great opportunity to brainstorm, change features that sounded good on paper, test the app concept with potential users, or just to sit with it and know for sure that it’s what you wanted.
In other words, it’s a lower level of commitment compared to a development-first approach: coding an app, even small, can take up to a few months. While the UI/UX design portion can be done in a few weeks, especially with a dedicated designer (who’s working on the app full time). In just a week or 2, you can go from idea to final designs, which, with the power of prototyping tools in Figma, can be clickable as well.
This is especially useful when you’re launching a new product as an MVP, and you want to test the waters before going full-speed with a large, complex app that could take 6 or more months to code. It’s a great way to quickly test your app concept and the usability of the first design.
Compared to a fully coded app, making changes to an app’s design is much easier and faster. Let’s say you, the product owner, have received the first iteration of your app’s design. And you realized a feature you asked for can be moved to a later phase. Had it been coded already, it would take up to a few weeks to take it out of the app (depends on the complexity of that feature, so this can vary). Whereas in design, it just means removing a few buttons and/or pages, which takes seconds.
And so, through a design-first approach, as a product owner you get to truly finalize your app concept and user flows, alongside, of course, the UI. All before committing to months of coding, testing, bug fixing, releases and maintenance.
What is a development-first approach?
When going development-first, you skip app designs and user flow brainstorming meetings and start right away with code. This might sound like you’re saving time and money, but you’re actually just saving it at the beginning.
Writing code without a clear foundation (set by the design) means going in blind and letting your development team do UI/UX design for you. But that’s a job for another team of people, and developers aren’t designers. Some might have a knack for it, but are you willing to test that out for the sake of your project?
So what does this mean in the grand scheme of things? It means that your development team will run wild and design the app as they see fit, maybe they’ll use a template, but their priority won’t be looks, it’ll be functionality. However, there’s no guarantee that functionality will be user-friendly.
How does that even happen? Well, developers won’t be conducting user research. Most times, they’ll ask what user types you have and what kind of permissions they should have, which is what they need on a technical basis. But they don’t know much else about the users, whether they’re tech-savvy people, young or not, or maybe they have poor connection speeds or slower computers.
These sort of aspects can influence the UX of an app - for less tech-savvy people, it’s best to include contextual help or even tutorials to help them use the app. Or if they have generally poor connections, it’s best to include compressed images that load faster, or show loading spinners to make it clear things are happening, it’s just taking some time. If they’re not so young, they might need bigger fonts and better color contrast.
These are things that developers won’t focus on, as it’s not their expertise and their main goal is code. They’ll focus on what plugins they need, how to keep their code clean, responsive settings, how to map out the layout of the pages, or how to define the app’s architecture.
Why is a development-first approach not as good?
When you head straight into code without any designs, you’re asking your development team to do UI/UX design themselves. This means the app might not look that good, it might not work as intended, it might not truly serve its users, and it could be difficult to use.
Since spending time on UI/UX design means fully mapping out an app’s flows, features and requirements, with that done the developers would have a stable foundation for their code. But without those things, they’re figuring things out on their own, which can take much longer. That time you thought you were saving by skipping design? This is where it goes.
This not only means the first iteration of the app won’t be what you really wanted, but it also means you’ll spend a lot of time and money re-iterating it, fixing bugs and issues and mending features that didn’t turn out as intended. You’ll end up going over the original project estimates, and releasing the product will take much longer.
And since we were on the topic of estimates, UI/UX design also plays a big part in making accurate development estimates. With the design in front of them, developers can get a much clearer picture of the app’s features and how things flow together, so they’ll be able to make better estimates. This means you’ll know how much the project will cost and how long it’ll take.
Without that visual foundation, you’re letting developers use their imagination. This means getting estimates that might not accurately reflect how long the project will take. If you’re in a bind, this is not a good approach. You’re leaving your app release date to chance. This can also create a lot of resentment towards your development team, who is just doing what they were told.
Development-first also means spending extra time molding the product onto what you really needed after it’s been brought to life. You won’t know at all what it’ll look like until it’s been coded. That means waiting weeks, maybe even months, just to see the app. And after all that time, it might not look the way you wished, or worse, it doesn’t work the way you wanted either.
That means taking a few extra weeks to evaluate the already-coded app, writing tasks on what to fix, and waiting for those changes to be turned into code. This can become frustrating and could delay your project release. And it requires you being good at giving feedback when it comes to UI/UX design. As we’re already pointed out, the time you thought you were saving at the beginning will be spent during this stage.
All in all, starting a software development project with a robust product discovery process can go a long way. Development takes a long time, and thus it’s expensive. Not having a design as a foundation means you gotta spend that time and money and then find out if your app looks good or not. Or if it’s usable or not. But with a design already done and approved by an app’s stakeholders, or even tested with potential users, which then goes into development, you’re more likely to create a successful software product.
Looking to create great software products, the design-driven way? Contact us and let’s see what we can do together.
