November 13th, 2024, posted in for_founders
by Adelina
Our years of experience in building software products has taught us many things. And one of these is the efficiency of design-driven development. This means putting more time and effort into product discovery and mapping out high-fidelity designs, and only then getting into the code.
Okay, but what’s wrong with starting with the code, you might ask? Here’s where that gets you: UI done by software developers, new features that weren’t properly fit into the existing flows, edge cases that were found too late, inaccurate estimates that take projects over budget, and (god forbid) more.
In other words, going development-first means playing a guessing game of what should go into the app, without having a clear visual guide to base user stories off of and letting developers fill in the gap where the first user stories didn’t cover all flows. If you’re not sure your app’s design meets the mark, check out our free UI/UX assessment to see how it aligns with best practices.
So what does design-driven development entail, exactly? It means going through a meticulous product discovery process which focuses on creating a final, high-fidelity design (a.k.a, ready to go into code). This design will be the basis of the app’s user stories, and thus, development estimates. Put simply, this way you’d know what everything is supposed to look like and how it should work, so estimates should be fairly accurate and there won’t be many surprises in development.
How did we get to this? We’ve done the development-first approach. And it led to us constantly going back and redoing flows, patching up code, navigating old designs that don’t match what’s on production, and endless discussions with clients on how to approach new tasks.
So in this article, we’re going to give you a few pros and cons of going design-first, so you can get a better understanding of this workflow and figure out if maybe this would work for you as well.
Pros
1. You get to finalize the app’s look and feel before it goes into code
One major difference between design-driven development and going code-first is that you’ll get a clear look at what the app will look like before anything is actually built. This means that clients get to see the final look of the app and approve its design and flows before waiting for months for it to be coded. In other words, they’ll know for sure that what they see is what they’ll get - no surprises when the coding part is done.
This way, clients get to picture how they’d use the app and help you finalize the flows based on what they know they need. With clear designs in front of them, they don’t need to use their imagination. Thus, you can hold much more productive conversations regarding the app you’re working on. They’ll be able to figure out if you missed anything in the app’s features and you can keep reiterating the design until it covers anything.
Otherwise, iterations would be done in code, which would take much longer - and if these iterations don’t end up being what the clients needed, then what? Would you scrap weeks of code? In other words, finalizing both the look and feel of an app through design brings a lower level of commitment and can allow for small changes in less time.
2. User stories will be more accurate and easier to write
It goes without saying that writing a document explaining what an app should do is easier when you have the app’s design in front of you. With the designs, you can quickly map out all the app features, all the flows and all the actions that can take place on every page.
Thus, the user stories you write will be accurate and will also contain visual representations, which will help developers when they start coding. Plus, accurate user stories means getting accurate development estimates. Developers will know exactly what they need to code and they won’t give ballpark estimates.
3. Developers won’t need to act as UI/UX designers
Making developers jump straight into coding with 0 designs means making them do 2 people’s jobs. Their own, and a UI/UX designer’s. Let’s say they have a rough idea of what the app should do, what technologies to use, they have access to a database of things that go into the app, they might have a logo from the client, and that’s it.
This means that the developer will have to pick colors, fonts, choose styles for inputs, buttons, modals, and so on. Now - in a time crunch, developers could grab a ready-made template such as the ones made by Creative Tim. And that’s great, if they’re not making a complex, customized app.
But if your developers are tasked with building a complicated, multi-faceted app, maybe one with a customer-facing side and an employee-facing side, a template might not provide everything they need. Which means they’d have to do design work on their own. Which, in turn, means the risk of getting a not so pretty software product as a result. Maybe some developers could do great design, by a sheer force of luck - but that’s no guarantee. You’d risk not only shipping out an ugly app, but also one with convoluted user flows. It works, but at what cost?
4. You can reduce costs when building an app
Continuing our ideas from the first point, reworking app features through the design is far more cost-efficient than doing that in the coding stage. Designs can be reiterated much quicker, you can save older versions of screens and go back and compare, you can look at different versions of the same pages at the same time, and you can quickly move things around in brainstorming meetings with the app stakeholders.
Coding, on the other hand, is more expensive as it takes much longer. And by jumping into code without a final design (or none at all) gives you the risk of not liking the final product and having to go back and change things, which will again take a long time.
With a finalized and approved design, you already know how the app will work. So there are low chances of wanting to change big things when the app goes live. Why do so when you already approved a version of it, right?
Cons
1. Designs might not always be entirely code-friendly
We’ve made it very clear that developers aren’t designers, and obviously it goes both ways. Designers will do their best in creating a beautiful design and useful user flows, but they’re not developers, and they might not always design things that can be coded exactly the way they want them to work.
Developers can be limited by the technologies they use, what plugins they can find, their skillset or even the client’s budget. And sometimes, elements from a pretty and well-planned out design can slip through the cracks. For instance, let’s say the designer used an icon pack that is difficult to add to code, which means the developers will have to switch to a different one, which will change the design of the final product. For an added layer of design support and to ensure every detail is development-ready, consider using our UI/UX expert review to get a professional review.
Another point to consider here is responsiveness. Not everyone will want to spend extra money on mobile designs alongside their desktop ones, but might choose for the final app to be responsive. This can be troublesome for developers as desktop designs might not always be easy to transform into mobile screens, especially if not planned out for this at the beginning. This can lead to extra design work in the middle of the development process.
There is a solution to this, however. And that’s constant communication between these 2 (or more) people. Brainstorming and approving ideas together can go a long way. Especially during the designing process - make sure to involve developers here to make sure you’re not designing something that can’t actually be built.
2. Edge cases can still show up
The final design will cover all the flows that could be figured out by the product development team. Key words: could be figured out. When building an app from the ground up, there’s always a chance you won’t be able to predict everything.
In the design stage, everything is static. You can use your imagination to figure out how things would work, but sometimes it’s only when the code is done that you discover what you missed. Human error intervenes: when you design an app, you look at it through the eyes of someone using it exactly as it’s supposed to. Give that app to someone new and they might find issues you would have never thought of.
Of course, issues or edge cases can be found during the development process (in other words, before the app is actually launched). You’ve still got time to fix things and work out the flows before the app reaches its customers. The key here is looking for those edge cases while you still can.
3. Complicated onboarding process
With design-driven development, once a design has been completed, the project will be passed on to the development team. This means taking the time to walk them through the screens, explaining the flows, the different user types and overall how it’s supposed to work. After this, the developers will use that information to estimate their work.
The downside to all of this is that it can get very time consuming, especially if the developers are seeing the designs for the first time (or hearing about the app itself for the first time). Information can easily slip through the cracks, and not everyone is good at explaining their work. This can lead to an endless back and forth with questions, which can make it difficult for the designers to work on their other tasks.
What can make this more difficult is outsourcing design and development in 2 different places and not allowing those teams to work together. The developers won’t be able to ask questions about the design and they’d have to guess what certain actions are supposed to do.
4. The live app can go in a different direction than the design
This won’t happen in all cases, but it’s good to be prepared. Sometimes, when met with a live app, long after the design was finalized, clients will ask for changes. Changes which can be made straight to the app, so as to not pay for extra design hours. What that means is that the app and design will start going in 2 different directions.
Now, there is a solution to this - designers can go in and update the design accordingly. But that requires approval of extra hours, which means more spending. This can get especially convoluted if new features get added to the app which require new designs, but the designers will have to return to an outdated design document. They’d end up spending that extra time mentioned earlier, in order to update the original screens.
Overall, design-driven development is a much more efficient methodology that not only saves time and effort, but which also leads to better apps that can truly serve their target audience. Product specs will be better thought of and developers will have a clearer starting point for their code.
Looking to use design-driven development in your own software project, but you’re in need of assistance? Contact us with a few details about your project and we’ll chat about what we can do together.
