To understand the nuances of what it means to be a developer or a designer let’s take a walk down memory lane and end with where we’re at today.
A Little Bit of History
When I started dabbling with HTML in the late nineties the term “Web Developer” and “Web Designer” were synonymous. As more and more traditional, print marketing agencies expanded into the digital side of marketing, the roles started to diverge.
People who traditionally were working in print and had the aesthetics nailed created Photoshop mockups. These were the new Web Designers. The designs they created were for people to code in HTML and CSS. The Web Developers.
The print designer knew about the print medium, they knew about things like bleed allowance. When it came to the web, it was a new frontier for them. They had to work with the Web Developer to see what was possible or not. For example web forms weren’t like the traditional forms that were printed out. There were limitations.
Ultimately, Web Designers needed to learn some web development to inform their design process, or at least understand the strengths and limitations of the technologies used to build web pages.
For the most part Developers and Designers have worked together in harmony whilst looking at each other’s skills as two separate non-overlapping magisteria; aesthetics vs programming.
What’s the Problem?
Both the Designer and Developer feels fairly comfortable in their respective roles. Actually, scrap that, I think there’s plenty of imposter syndrome in both the Developer and Designer. They feel they’ve got to contend with enough, dealing with their own feelings of inadequacy in their own role, which often leads to them either not contributing to the discussion with people in other roles, or being super defensive about their own role.
But it doesn’t have to be this way.
Uniting in a Common Goal
Both the Designer and Developer have one very important trait in common: problem-solving.
They are using different mediums, but it’s the same underlying principles in play. Designing user interfaces or designing the code used to build an application relies on you building something that functions. That thing has to have a function; if there is no function, there’s no problem to be solved with it. It’s just art or playing around, both have their place but in a project there’s often little to no room for that.
The role of the Designer and Developer is to improve another human being’s life. Their roles both heavily rely on empathy, psychology and neuroscience. Both have to logically and methodically think things through. You have to put in the thoughtfulness of what the problem is first before designing or coding. Any failure to do this could end up creating something that’s unintuitive and perplexing to your users. In other words, you have to put in the work of cognition up front to reduce your user’s cognitive overload figuring out how your application works.
What Does it Mean to Be a Problem Solver?
When I was developing one of my courses at Treehouse I decided to look at a colleague’s course, Design Foundations by Mat Helme. The further I went through it, the more I was thought, “this is what it’s like to be a developer.” I solve problems. There’s a section called “Becoming a Problem Solver” where he goes over the 4 P’s of Problem Solving.
In short there are four steps to solving a problem.
- Prepare – where you understand and diagnose the problem and think of a high-level solution.
- Plan – where you organise everything you need or plan out what you need to accomplish.
- Perform – where you put your plan into action, design or develop.
- Perfect – where you check to see if the solution has solved the problem. If it hasn’t you can review and rework using the process again.
I’ve been using this in several of my courses since. Teaching people to solve problems is probably the most valuable thing I can teach someone, rather than just simply dispensing the syntax of a programming language or the API calls of a framework. I want them to feel like they are becoming superhumans that can do anything!
Conclusion
You’re what Aral Balkan describes is an Experience Designer. Human’s have a finite time to spend on things. The applications you design and build is part of their human experience. If they are frustrated by your application they are wasting their precious time, it’s not their fault, it’s yours.
Design should lead the development and development should inform design. Separating out these two roles or facets of your application can cause bad experiences for users or should I say real living human beings.
Here’s Aral talking at a PHP Conference 2013 where he talks to developers about them being designers too:
Also, if you’re a designer or developer you should check out Mat Helme’s Design Foundations too, it’s well worth your time!