Skip header to navigation
My favorite process in software engineering, whether I’m building something new or working on an existing feature, is to first focus purely on the functionality and completely ignore the design. Once everything works, I shift my full attention to making it look and feel great.
I learned this process over a decade ago, and I’ve been recommending it ever since to anyone who’s struggling while building something: struggling with refactors, with design collaboration, with pressure from planning and management, or simply with finding creative direction for the UI.
I first experienced this during an Android development course by Ben Jakuben on teamtreehouse.com. At the time, I was enrolled in a mobile app development class at university where we learned iOS development in Objective-C. But as an Android user, I wanted my final project to be an Android app. Having no clue about Android development, I looked around, found a course on Treehouse, and speedran through it over one or two late nights.
Ben did a fantastic job of guiding you through things logically and leaving you in a place where you could confidently keep learning on your own. The end result of the course was a Snapchat clone built with Pusher as a backend. It was refreshing to not just build a throwaway demo app, but a real media-based app that was genuinely relevant at the time.
The course focused heavily on getting the functionality right first: signup, login, creating posts, listing them, viewing them, expiring them so you could only see them once. Only after everything worked did Ben show how to layer a proper design on top, and really demonstrated the merits of this approach. You could see how the app suddenly came to life, without having to refactor everything again and risk breaking things.
That was a real “woah” moment.
Since then, I’ve often advocated for this approach and repeatedly experienced how much it can help.
Even though I’m such a huge fan of this process, it wasn’t possible to do in every project, and it doesn’t work equally well for every kind of product. Sometimes “functionality first” doesn’t mean “design later”, but something in between: where interactions are already considered in the functionality, while the visual polish is postponed. And sometimes you’re joining an existing team that works design-first, and you can’t just overthrow their approach: that wouldn’t be professional. But you can observe friction and frustration, and when it makes sense, recommend trying to focus on the functionality first.
Once everything works and you’re happy with how it behaves, there’s a good chance the design will naturally start to form in your head. It often just takes a shower, a night of sleep, or a walk. And if it doesn’t, you can still research and ask for help: “How do other apps solve this?”, or “This is how it should work, can you help me make it look and feel great?”.
The main downside of this process is that some people will assume what you’re building is already the final design. You know that it’s obviously not, but they don’t know. Not everyone is familiar with this way of working, or with how quickly something ugly can completely change into something polished. Not everyone can mentally cleanly separate functionality from appearance, and sometimes early visuals tend to stick with them. You’ll get questions about whether this design is already final. You’ll hear comments about spacing, colors, fonts and alignment.
This can be annoying, but don’t let it distract you. Part of this process is giving people a heads-up… often more than once: I’m focusing on functionality right now. We’ll make it pretty later. This is intentionally left ugly.
My favorite process in software engineering, whether I’m building something new or working on an existing feature, is to first focus purely on the functionality and completely ignore the design. Once everything works, I shift my full attention to making it look and feel great.
I learned this process over a decade ago, and I’ve been recommending it ever since to anyone who’s struggling while building something: struggling with refactors, with design collaboration, with pressure from planning and management, or simply with finding creative direction for the UI.
I first experienced this during an Android development course by Ben Jakuben on teamtreehouse.com. At the time, I was enrolled in a mobile app development class at university where we learned iOS development in Objective-C. But as an Android user, I wanted my final project to be an Android app. Having no clue about Android development, I looked around, found a course on Treehouse, and speedran through it over one or two late nights.
Ben did a fantastic job of guiding you through things logically and leaving you in a place where you could confidently keep learning on your own. The end result of the course was a Snapchat clone built with Pusher as a backend. It was refreshing to not just build a throwaway demo app, but a real media-based app that was genuinely relevant at the time.
The course focused heavily on getting the functionality right first: signup, login, creating posts, listing them, viewing them, expiring them so you could only see them once. Only after everything worked did Ben show how to layer a proper design on top, and really demonstrated the merits of this approach. You could see how the app suddenly came to life, without having to refactor everything again and risk breaking things.
That was a real “woah” moment.
Since then, I’ve often advocated for this approach and repeatedly experienced how much it can help.
Even though I’m such a huge fan of this process, it wasn’t possible to do in every project, and it doesn’t work equally well for every kind of product. Sometimes “functionality first” doesn’t mean “design later”, but something in between: where interactions are already considered in the functionality, while the visual polish is postponed. And sometimes you’re joining an existing team that works design-first, and you can’t just overthrow their approach: that wouldn’t be professional. But you can observe friction and frustration, and when it makes sense, recommend trying to focus on the functionality first.
Once everything works and you’re happy with how it behaves, there’s a good chance the design will naturally start to form in your head. It often just takes a shower, a night of sleep, or a walk. And if it doesn’t, you can still research and ask for help: “How do other apps solve this?”, or “This is how it should work, can you help me make it look and feel great?”.
The main downside of this process is that some people will assume what you’re building is already the final design. You know that it’s obviously not, but they don’t know. Not everyone is familiar with this way of working, or with how quickly something ugly can completely change into something polished. Not everyone can mentally cleanly separate functionality from appearance, and sometimes early visuals tend to stick with them. You’ll get questions about whether this design is already final. You’ll hear comments about spacing, colors, fonts and alignment.
This can be annoying, but don’t let it distract you. Part of this process is giving people a heads-up… often more than once: I’m focusing on functionality right now. We’ll make it pretty later. This is intentionally left ugly.
