Not every software project has the luxury of a dedicated UX designer, graphic designer, development team, QA engineer, project manager, cheerleader and irritable boss.
Often you are on your own - looking to fulfil many or all of these roles at the same time. You end up being forced to make decisions about the UI while at the same time considering the flow of data and how to prevent your users from breaking the system. Tiredness and deadlines can cause you to take short-cuts that you know will result in a sub-par user experience or hacky, unstable code.
By splitting your attention between designing the user flows and defending against issues that will horribly crash your user’s phone or corrupt its data, you risk delivering a solution that doesn’t deliver on either front adequately. The app store can be a cruel mistress, and a few one star reviews can be a hard pill to swallow after all your effort.
Often, after spending many hours staring at an almost impossible to reproduce bug, the temptation to patch up something quick and assume the user will just get the flow without any hints or guidance becomes too strong. You put your work live. You’ve already make the decision to live with the technical debt and design debt for now. You slowly come to accept that gnawing feeling inside that the code base isn’t as neat as it once was, and you know that bit by bit, each new feature will become harder to implement than the last. But at least the release is live.
The one positive you clung to when deploying your work for all to see is the great sense of accomplishment at hitting version 1.0. But, it lasts only as long as it takes the first user to write up a complaint about the quality of the experience, putting your app at risk of instantly being consigned to the graveyard pages of the app stores. The real work has only just begun.
At the core of this all too common experience is the fact that it is almost impossible for one person to both code well and design well at the same time.
Design requires an inherently creative mindset. Your user wants to achieve something - what is the easiest way to help them achieve it? How can you combine colours, shapes and words gently nudge a user along a given path, successfully communicating your message without creating fear or confusion? How do we order things to help the user pick the right options at the right time? Great designers make sure the human can progress, regardless of the computer.
Development requires an inherently structured mindset. A stable product means thinking through all the flows, not just the positive ones. It means making sure a user can’t go to a certain screen unless certain criteria are met, and handling when they try. It means making sure the right things happen in the right order, or rolling back. Regardless of what unexpected action the user takes the integrity of the app must be maintained. Great developers make sure the computer can progress, regardless of the human.
Great designers make sure the human can progress, regardless of the computer. Great developers make sure the computer can progress, regardless of the human.
Every developer knows about the cost of being interrupted while deep in concentration. Gerald Weinberg created a famous rule of thumb to estimate the amount of time wasted due to context switching. He estimates that the cost of context switching is 20% per simultaneous project.
Switching mindsets between design and development falls within this category. Thinking about design requires one mindset. Thinking about development requires another. Switching between them costs time. Not switching is even worse - it means making design decisions with a development mindset, or development decisions with a design mindset. The time and effort spent repairing the damage of a poor decision made earlier in a project can be a hundred times more expensive than getting it right at the start of the project.
As humans, we use the tools and knowledge we are comfortable with to achieve our goals. As developers, this also means we instinctively use what we are familiar with - code - to solve our problems, even if they are design problems. It takes a different degree of knowledge and experience to decide that your first port of call is not to spin up the project in xCode, Android Studio or Bootstrap.
The success of your project depends on your ability to separate your design thinking from your development thinking. Keeping the two apart will let you make design decisions first, setting out what you want to do from a development perspective, and keeping you on track and focused on the important parts of the user’s experience. It will let you prioritise where you spend your effort.
Design decisions need to be made far away from the dark depths of loops, recursion, bugs and functions. Development decisions need to be kept far away from the shiny utopia of perfect user flows, scaffolding and user engagement. Be aware when you are in one zone, and when you need to transition to the other. Try and group your design time and development time separately to minimise context switching costs. And when you need to take a break, do so.
Designers focus on reducing the number of brain cycles a human needs to achieve a goal. Developers focus on reducing the number of computer cycles a machine needs to achieve a goal. Switching between contexts takes time, and not switching is even more costly. Where possible, don’t mix the two. Definitely don’t launch into code until you are ready. Your users will thank you for it and your efficiency will be dramatically improved.
