How do they possibly want to learn all this?Yeah.
There isn’t a simple road to actually learning to code in a short timeframe.
Especially when someone can’t allocate most of their time to learn coding because they have their primary job and a life.
In a week or two, you may begin to dabble in basic concepts.
Put a month of effort in, and you will begin to understand some things, although you may not be able to understand more complex situations and especially, you may have a hard time debugging and solving problems.
That’s what coding really is most of the time.
In my opinion, there’s a much better way of asking this question:Should UX designers learn and understand the basic concepts of the technology that’s used to put their design to production?And now we should be ready to answer with a “Yes.
”Instead of learning programming (although, if you can do it, if you are interested and if you have enough spare time — certainly go for it!), you may want to learn what happens with the work you send to production and how each part of your project is turned into a working product.
Making a bigger toolboxEach designer has their own medium.
You may be designing apps, websites, devices and interfaces, just to name a few.
Each of those is implemented using different technologies, but there are some common threads to all of them.
Here are some examples of the things you may be interested in learning instead of learning to code:How does your prototype’s style guide translate into the product’s styling rules.
In case of websites, this task is done with CSS stylesheets, which are the equivalent of your style guides.
How does your design’s layout transfer to product layout.
In case of websites, that’s the HTML part.
HTML is responsible for the division of content into semantic blocks.
In iOS developers use UI elements which also can be seen as building blocks.
They use Interface Builder for that, which is in some aspects similar to the tools you are using.
What are the various programming languages and how they are used.
It’s often the case that multiple languages are used in a single project.
Learn how the languages are put together to become an interactive, working product.
You don’t have to learn the languages, or at least you don’t have to go into the details very deeply.
It’s enough if you understand how they work in general, why they are there and what they allow to create.
It’s like looking at a toolbox — you don’t have to use the tools regularly, but you may want to know what is their purpose and how and when they are used by others.
How do the designers build the product.
Usually there’s a framework of some kind involved.
Frameworks form a basis of applications and allow the developer to start working quicker, because instead of building something from scratch, they start with a very basic template that has commonly used functions already built in.
They usually have to customise it and build additional features on the top of it.
What tools are used to create code and why are they required.
Developers usually have their favourite editor (which they will often customise to fit their needs; they will probably also defend it and recommend to their fellows or even start flame wars about them — so be careful here, it can be a very personal matter!) They also use tools to coordinate their work, to push completed tasks to production, to ensure that a team of people can work on the same file without creating conflicts.
They will also have special testing environments set up to quickly see if they achieved expected results or not.
How to debug errors.
Developers rely heavily on error messages.
Those messages, which for untrained person seem like a string of jumbled words and numbers are actually crucial to pinpointing where and why an error occurred.
Learn how developers deal with such errors and how they think when they are looking for a solution.
How are the products served to customers.
In case of web apps and websites, that usually involves some kind of server-side and browser scripting in addition to serving content.
Developers write code which is then run on the server.
Then the output (typically filled with some relevant data pulled on the way from the database) is sent to the user’s browser.
There are also scripts which run in the browser itself.
They have the ability to change and update the contents of the page without the need to reload — that’s how web apps become interactive.
You should also definitely learn about AJAX if you are into web design.
What are APIs and how developers use them.
API is short for Application Public Interface.
Services and web applications sometimes allow to connect products created by third-party.
To allow this, they usually allow the third-party code to log in and request or send data.
Facebook allows to access the user graph, for example and you can build applications that plug-in and use the data in some way.
All of this allows to build complex products by gluing various apps and services together.
Definitely learn about REST protocol while you’re at it and get a basic understanding of JSON encoding.
There’s a lot of unavoidable technical jargon involved, but if explained in an approachable way, it should be quite easy to grasp to non-coders.
As with everything, learning this will require some level of curiosity on your part.
But I think UXers are one of the most curious people around, so that shouldn’t be an issue.
The curiosity you show and effort you put in will be rewarded by giving you an edge and informing your future design decisions.
Just by learning the above items you will learn way more about what’s possible and what’s not, what will require a lot of work and what will be easy to make.
And that’s something you should definitely go for.
Soon, you will find yourself checking out technical API docs for various third-party products, learning what and how can you include into your toolbox, and then using all this knowledge in your everyday job.
Let your curiosity guide youI’ve let myself to be guided by curiosity for my entire life.
I used a range of approaches in the process.
Here are some tips on where to get the necessary knowledge from.
They aren’t new, in fact, they are pretty obvious, but still — here you go:Online courses and tutorials.
Lots of them.
You will certainly find something related to your design field online.
One tip: focus on learning how things work instead of how to code projects.
Ask the developers in your company.
They’re the ones who will know best, and as a bonus, they already work with you and know your work.
Be sure to befriend them and ask them about their work and how they build products you’ve designed.
Ask them to show you the tools they use to code and coordinate their work.
Ask them about the steps they take.
Even better, ask the company to arrange special trainings.
May or may not be possible, but the one who’s asking never fails.
Just make sure to tell them you want to learn about the technology that powers the solutions of your company instead of asking for a crash course in programming.
You may even want to show them this article so they better understand what you want!.*wink*Learn to modify things created by others.
If you are in web design, you can learn to use dev tools in the browser to quickly edit and preview the changes you’ve made.
This same approach should be easy to pull-off in any other field too.
Download other people’s projects and tinker with them.
That’s how I learned HTML when I was a kid.
I saved a website I liked to my disk, and used notepad to play with it and change it to my liking!.I never published any of those and you also don’t have to!I think some understanding of how the technology behind it all works is a great asset in any UX designer’s toolbox.
It allows you to grow in new ways and it lets you communicate with developers on a whole new level.
It’s often the case where developers are annoyed by designers and designers can’t understand a word from what a dev is saying — and learning about the underlying technology tends to alleviate this issue.
You will quickly notice that when developers talk, they usually want you to know only those more general aspects of the technology they are using.
They rarely (if ever) expect you to dive deeper into strictly coding-related issues, but they would like you to know how things work in general in the product you are creating together.
In my opinion, you definitely should give that a try.