small_Fcsqb5pWQAAzPIK.jpeg

thumbnail_Fcsqb5pWQAAzPIK.jpeg

Adobe acquires Figma, cue the memes 🤪

large_Crossover Series NFTs.png

medium_Crossover Series NFTs.png

small_Crossover Series NFTs.png

thumbnail_Crossover Series NFTs.png

From Photography to NFT Art: Twisted Digital Landscapes with Nate Hill

Still can’t get a UX job? Give up.

large_featuredImage

medium_featuredImage

small_featuredImage

thumbnail_featuredImage

Sticking to UI/UX trends is a losing strategy

<a href="http://ift.tt/2qwJF8m">RE: Write &mdash; Medium</a> | Kate Mills <img alt="" src="http://ift.tt/2pv3xu9">
You might think this post is going to be all about the hotly debated question, Should designers code? At this point, it seems that everyone has put their 2+ cents in, and yet, it still gets asked at every single panel discussion I have attended having to do with UX and design (with a sharp edge of concern and worry from newbie designers); it is to the point of mockery on the <a href="http://ift.tt/2cOqJey">Design Details podcast</a>, and yet they still ask it of just about every designer in the tech space that they interview on the show.
But no, this is not about that question.
(And in case you were wondering what my answer is currently, it is this: Code if you want. Code if you like it. BUT MAKE SURE to have some understanding of coding in general and the process that developers go through to make things work. More on this later.)
What this post is actually about it how coding has benefitted me, a newbie designer with limited professional experience in the field. Because yes, it has benefitted me.
<h4>A Lil’ Coding Backstory</h4>
<img alt="" src="http://ift.tt/2pvapry">
I would say I first started coding in earnest this past December. I had learned a bit, hodge-podge, before then: some python basics from my boyfriend a couple years ago (if/else statements, for loops, etc.) and a little bit of front-end fun in a few weeks from one of my instructors last semester. It was all piecemeal though. I would hack together different snippets I found online, hoping that they would do something. If they didn’t function, I really didn’t know why and was somewhat at a loss as to how to fix my code.
So, over winter break, I started going through some tutorials online and working on coding some simple things from scratch. I did this because a) I had noticed that some UX job postings named HTML, CSS, and JS as preferred skills, but also and mainly, b) I liked coding. I didn’t go running screaming from it like a number of other designers I know which seemed significant; conversely, it gave me great satisfaction when I could make things work in robot language. It’s constant problem-solving on a large and small scale, and, well, problem solving is my bag.
<img alt="" src="http://ift.tt/2qwJ1Ys">An original sketch for the Droplit concept before our final presentation as a small group, courtesy of my teammate <a href="http://ift.tt/2pv37nt">Alli</a>
When we came together as a class on our startup project Droplit (catch up <a href="http://ift.tt/2qxan0M">here</a> if you need) and it was time to choose roles, I knew I wanted to dev the marketing website for our product. I didn’t *quite* know how it would work exactly, but I knew it would be a fun challenge, and one that would give me experience different from anything I have done in my Masters program, or for that matter, ever.
After lots of research and discussing it with the two guys on my team, we decided we wanted a bigger challenge than creating a site on Squarespace or WordPress: we were going to do it using Bootstrap templates and libraries and host it on Gitpages (which is freeeeee!).
<img alt="" src="http://ift.tt/2pv1AOd">Some Bootstrap bits + Github = Droplit site success
This was going to be difficult. The biggest anything I had coded to date were <a href="http://ift.tt/2qwSizU">silly little codepen things</a> that didn’t do a whole lot. But, we figured that if nothing else, we would learn something new (even if we failed).
I will bypass what I still think was the hardest part: getting our file structure in order, connected and working, and up on Gitpages. There were three of us, and though we knew in general how Git worked, none of us really knew how to use it in practice and were concerned about messing everything up that we had just worked so hard on to get up and working properly. So, before we had any design to speak of from our design team, we worked separately and then manually (and also, a bit painfully) combined our code into one place.
I finally figured out how to use Sourcetree to get changes committed to our repo and then up and live, and somehow along the way, I sort of became the “lead” on the project, as we decided that trying to manage pull requests and conflicts in our code was just not in our skill set. So, I would be the only one committing changes to our site.
And thus, <a href="http://ift.tt/2puLjsW">the Droplit website</a> has become my baby.
<img alt="" src="http://ift.tt/2qwQ7ML">Isn’t she a beauty?
I have spent many, many hours working on the site and have learned a lot when it comes to frontend coding. But that’s not the point I really want to make here. Instead, I’m going to talk about what being in the dev position has taught me about being a better designer.
And here we go:
<h4>What Dev’ing the Droplit Site Has Taught Me About Collaboration as a Designer</h4>
1. My Design is NOT the Final Product
This one is a favorite of one of my instructors, so I have heard it again and again over the past year. My design is NOT the final product. My design is a means to an end, which is producing (coding) a piece of software.
To that point, it is important to remember my role in the process. As a designer, I am important, and I can have a real and vital impact on what we hand over to the client or to our users.
However, when it comes down to it, what I do is really is a means to an end, and it is my job to make that end as easily achievable as possible (while still making the end product as usable/effective/delightful, etc. etc. for my users). And that means producing good work in a timely manner. And that means giving some things up and sometimes compromising when collaborating with devs. And that means not treating my design as overly precious, as a treasure set in stone that cannot be tainted or changed. But it also means defending the user and arguing for my design when necessary.
2. Shit Rolls Downhill
Yup, yup, and yup. I know no other way to say this. Developers are the ones who have to bring everything together and hand that product off in its final form. They are the ones who have to make things work when (often) other parties along the way have already washed their hands of it. Therefore, it is my job as a designer to not contribute to the inevitable shit that will end up on a coder’s plate.
Empathy, man. It’s what us UX’ers are supposed to be supreme at, amirite?
3. Think Through All the Things. All of Them.
Websites, apps — these are living, breathing things. Machines run them, and humans interact with them, so a lot of crazy stuff can happen. And it’s important to think through (and communicate) all of that.
What happens when a title is way longer than the easy, succinct one I used in my wireframe? What happens when this goes to a mobile site? What happens when the user scrolls? What about when they push this button? What happens when they collapse this table view *almost* all the way, but not quite? What happens when there’s no data yet and this is empty? And what about this, and this and this…?
It’s my job to think about this stuff and communicate it to my developers instead of them having come to me with a million questions so that they can do their jobs correctly. If I am not clear about my designs and how they live and move, then I can’t expect that they will be coded correctly.
4. Be Communicative. AND KEEP YOUR COMMITMENTS ALREADY.
Don’t make others guess or try to read your mind. This is something that has been important in many facets of my life (personal relationships, being a teacher, giving a pitch), and now is no different. To work successfully in a team, communication is key. That means keeping others abreast of your progress (within reason, of course). It also means communicating when you have hit a road block or things aren’t going to plan. As I said above, shit rolls downhill, so it’s only fair to keep your devs in the know so they can prepare themselves as well as possible.
In the end, developers needs assets from their designers, not concepts or half-baked ideas. So, when you say you’re going to have something for them by a certain time, have it. And if you don’t, stop talking about it and just do it already. Because, I mean, come onnnnnnnn.
<h4>The Future</h4>
My immediate next steps in life are 1. finishing up my grad program (one more week of class + a design sprint for our finals) and 2. finding a job (read more <a href="http://ift.tt/2o4Iak4">about my hunt here</a>). Part of #1 is being able to finish up the Droplit site to hand off by Thursday evening. Almost there! Just a couple things to clean up (mainly mobile optimization) and some assets to wait for (sigh).
I don’t know how much I’ll code when I’m all said and done with this, but I have a sneaking suspicion that everydroplitcounts.com will not be my last dance with HTML, CSS and JS.
<a href="http://ift.tt/2puLjsW">Visit the site for yourself </a>and let me know what you think.
<img src="http://ift.tt/2qwMcPU" width="1" height="1" alt="stat?event=post.clientViewed&amp;referrerSou">
<hr>
<a href="http://ift.tt/2pv4eDM">How Being the Lead Dev on a Project Has Made Me a Better Designer</a> was originally published in <a href="http://ift.tt/2nbcQv3">RE: Write</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

How Being the Lead Dev on a Project Has Made Me a Better Designer

How Being the Lead Dev on a Project Has Made Me a Better Designer

Top Stories