Ask HN: Front end designers, where did you start?

I can't quite tell if you're having trouble with front-end architecture (code structure/design, separating things effectively across HTML/CSS/JS) or design (UI, UX, look/feel, application layout and navigation structure) or both.

If the first is the problem, it's probably worth running through some tutorials to build a full application on whatever set of libs/framework you've chosen. For example, there's a course on Udemy called "Modern React and Redux" that'll introduce you to (surprise) react and redux, as well as demonstrating how to structure your application and build some basics. There's any number of similar things from other people for other ways to structure an app with jQuery or Angular or whatever.

If the design-side stuff is the problem, the first and easiest thing to do is look at examples of good design. Showcases like https://www.thebestdesigns.com/ will have tons of beautiful, well-designed websites you can look through and examine. This is more useful if you put some effort into it (What do I like about this design? Why did they do things this way? If I play with the CSS and adjust these things, how does that change the look/feel? How did they get this effect?) Sites like https://alistapart.com/ and Smashing magazine will have some useful articles to read, sites that sell templates can give an idea of current design trends that are popular/sell well (themeforest etc.), Dribbble and the like will have detailed design mocks, UI kits and guidelines will have basic layouts for UI elements. It's probably worth spending time wire framing with tools like Balsamiq/Sketch/Photoshop, though if you've never used any of those I'd go with pen and paper.

If you're doing both the coding and design parts of the process, its probably best to separate them. If your design isn't well defined when you start coding, it's easy to discard important aspects of it in favor of code efficiency. Similarly, it's usually better to get the look of things right in your design tool instead of spending hours tweaking shadows and colors in CSS.

It's the second for sure. With a design I can recreate it in code without that much issue. The problem for me is very much the blank canvas. I sit down knowing what I need to include, but then I start with the mobile spec (as I've been told you're supposed to) and the the tablet, then the desktop...Somewhere in between I've lost the thread, in fact, I've lost all perspective about what I'm supposed to be making and how things tie together.

Thank you for the links, those are good resources. I think I'm going to just have to commit to study and deconstruct what is working for other sites, it's just not something that comes naturally to me. I do wish that there were the kind of declarative tutorials/walkthroughs available for the front end as there are for the back end, a kind of case study in solving a particular design problem.

In that case, a few more things.

https://www.amazon.com/Dont-Make-Think-Revisited-Usability/d... http://webtypography.net/

You'll probably want to do some reading on common components of design such as color, spacing/negative space/white space, grids, typography.

I feel like even experienced designers can have trouble coming up with something that will work on phones, tables, and various desktop/laptop screen sizes all at once. I'd pick one platform to target initially, get something working there, and then see about the others later; otherwise, you're taking something you already aren't practiced at and multiplying your difficulty several times.

Here's another design book I like and which is more in the direction of case studies, but the material (dashboards) is very specific and might not be useful to you - https://www.amazon.com/gp/product/1938377001/

Copying in front-end design is not exactly a bad thing, software interface isn't supposed to be a work of art and as web software have similar patterns, it can be good UX to copy since you'll be using conventions your potential users are already used to. I'd recommend reading this: http://thehipperelement.com/post/75476711614/ux-crash-course...

Awesome link, thank you!

I find the front end space overwhelming and am deliberately saying NO to a lot of stuff. Getting better and being able to do more complex stuff with the tools and frameworks I know seems to help me more than complementing what I learned so far with other stuff on the same competence level. That is not to say I don't look around - I do a lot.

In communication with others I'm very explicit about what my tool stack is to the extend my boss told me recently I'm painting myself in a corner. I realized I got to work on the perception but I will not change my strategy. Being good in one allows me to have the confidence to be good in another quickly if need arises.

> I have tried decomposing other people's designs, but whenever I try to apply the results, it ends up looking like a poor copy.

There is a huge difference between "trying" and "doing". From POC to something that is launch-able is a long way - at least a factor of 3. Unless you put in the time and effort to really polish something the surface will look dull. Maybe find a project where you are intrinsically motivated or paid to push a solution to a higher level?

Yeah, this sound familiar to me. I feel like I'm specializing way too early though and starting to be a bit brittle. I already look for front end help for most new projects, which is fine because it helps projects go to completion, but it is starting to feel like a crutch that will soon turn into a handicap unless I commit now to only being able to handle one side.

Totally agree with the last point. Of course it takes a lot of effort to make something really shine. I'm just feeling frustrated that I can't even find the diamond in the rough to take to the expert and have them polish.

I probably have a weird way of learning things, but the way I started, was by analyzing the Vue.js Hacker News clone and then just adapting the structure to my own project and it all made sense really quickly after that.

https://github.com/vuejs/vue-hackernews-2.0

I am a beginner frontend developer and not a designer, so take my advice at your peril :)

I would draw all the screens on paper, with a pencil, trying to get it right. Then I would code it in a by-the-book style using VueJS or EmberJS and Bootstrap or Semantic UI. Don't try to customize the design yet, just make it exactly as it come from these tools. Then, when everything is working and looking fairly ok as a modern interface, I would check out more interesting websites out there that has the feeling you want with your own project. And used it as reference to choose colors, fonts, layout, etc.

A good place to start looking for references that I found here at HN just now: https://klart.co/pixels

Nice link, thank you! It's a fair point, maybe I have not copied enough and am trying to run before I can walk.

Let's get this out of the way from the start, you're definitely not lacking something. Like most things you can get pretty far with deliberate practice. The front end is usually a combination of usability, design and code. It sounds like you need help with the usability and design part.

The first step of awareness means you're on the right track. You've also developed a sense of taste because you've recognized something is distinctly better than the other. Ira Glass has a great way of framing this concept [https://vimeo.com/85040589]. You can close this gap of ability vs taste by continuing what you're doing. If it feels confusing and difficult, you're making progress. It will take a while to constantly probe at the "why" something is better. Next you'll learn how to apply it.

If time is a constraint there's a way you can accelerate your learning. You'll have to ask someone who is better than you for feedback and advice. This works really well. If you have the resources and don't feel the need to learn, you can always pay someone to do it.

There's a lot more I can go on about but feel free to reach out if you need some help. Here's some additional random thoughts:

- Don't get too caught up in the design and elegance of your front end design. Show it to people, they will help guide what you need to work on.

- It's okay if things look like a copy of something else. We can learn a lot through imitation.

- Pay attention to software you love and really try and understand why you love it. (Sounds like you're doing this already)

- Check out these books: Steal like and artist, the design of everyday things.

- Read through Apples's HIG docs, there's lot of great stuff there on mobile and app design.

- Empathy is a critical tool when making interfaces for others. Really try to understand the problem you're trying to solve by getting in the minds of the user. Usually the solution comes pretty naturally.

- By exposing yourself to lots of different kinds of software and apps you'll start developing a sense of what works where. Like when do I use a slider vs a numerical input.

Ira Glass is one of my heroes. It's both inspiring and depressing that you would remind me of his approach; his is the hard way for sure, but maybe the more rewarding one in the long term if true understanding/mastering is what is desired.

Your points below are also excellent. Thank you very much!

I have found HackDesign[0] to be a great source of ideas and resources to learn about design. I'm a developer myself and just have a guilty pleasure in learning design so I follow along HackDesign every now and then to learn new stuff.

[0]: https://hackdesign.org/

It sounds like your question is one of general project structure, organization, application design/architecture and more or less "how do I hook components together?/what's the right way to modularize/organize an application or web page?"

This is going to sound dumb, but I would suggest reading a bit about backend or systems programming.

In my limited experience, code organization and modularity principles, as well as application architecture/structure principles, tend to hold regardless of specific domains with perhaps only some minor differences. So, even if you are designing a front end the way you break up components and the degree of modularization/your process for determining when something can be separated out, compartmentalized, etc. should be relatively similar to a native/systems/backend project--even though your materials and purpose are different.

In my personal experience, most front-end web development resources are either not geared toward these principles/are not always good examples of them. You find a lot of front-end tomes more or less just sugessting you follow the current idioms without teaching you why you should nor questioning whether there's a better way. Front-end texts generally are not good resources for learning programming/comp sci-fi fundamentals for, I think, two reasons: a. it's generally thought that these concepts are less important for front end devs (somewhat true but I guarantee you a front end dev that has some knowledge of the fundamentals of computer systems is going to perfrom better than one who doesn't) b. often this material is out of scope in front end resources, which focus on the nitty gritty of frameworks, js, etc. (the proliferation of frameworks is also a massive problem, imo, when it comes to front end development/web development which probably would have been avoided had more front end devs been more familiar with the way things are done in the systems programming world/unix principles etc.--you still have plenty of libraries in that case, but generally dedication to core libraries and their maintenance is stronger)

Contrarily, systems programming texts/conceptual texts, since that domain has been around for a long time and since organization and rational decision making are very important in that domain tend to stress these things and communicate them clearly.

Once you get the general/abstract notions of code organization, modularity, and application/architecture design and structure down I think you'll find you can easily adapt/apply the same principles to web development/ web apps, and will probably have a better understanding of what's going on.

I'm self taught myself and don't profess to be a front-end nor systems programming wizard by any stretch of the imagination, so take all that with a grain or two. That approach just happened to, I feel, greatly increase my own understanding and be a big step in my learning. If I had confined myself only to books/articles about front end web development I think I'd actually be worse at it in a lot of general respects, but perhaps a tad better at the particulars of certain frameworks etc.

Hmm, this is intersting. I have previously thought about front end design as a way to access and suss out the users needs so that I can make a better model on the back end (or at least plan for an extensible one) especially since the wireframes/mockups often help to get user feedback. It would be an intersting experiment to create my own project and just fiat all the user requirements. If I then broke up the front end in the same process that I do the back end it would certainly feel more manageable.

Now that you have me thinking down this path, I wonder if I couldn't map a kind of UML for what messages the user wants to send the application from the browser. I'll have to pull at this a little more, but this kind of description seems both more tangible and translatable to specific elements of page design.

For a start, don't overthink this. There's a wealth of tools[1] you can use that have all the functionality you're looking for baked in. If you're concerned about copying others work, don't be. Everyone does it. Why re-invent the wheel? Just be careful copying things like images and copy, as you will have to be original there[2]. There's actually not much skill required for this stuff, and this is why basic coding skills should be taught in school, because there's little 'grit' to this. Make something bold, do this: <strong>bold</strong>. Not so hard. The hard part is doing this at scale and this is why you need to simply accept that coding sites is a lot of repetition.

So to answer your question - I started by calmly accepting that as a developer, I would be typing out a lot of the same bits of code over and over, often creating <table> soup in the early days, and have since moved onto <div> soup and then styling accordingly with CSS. Sadly there is this trend of designing sites in reverse and people doing all the CSS and JavaScript first, and only when they're ready they start adding actual content.

[1]: https://adventurega.me/bootstrap/

[2]: http://bettermotherfuckingwebsite.com

Both bettermotherfuckingwebsite and motherfuckingwebsite have seriously brightened my day, thank you for that :)

>>Sadly there is this trend of designing sites in reverse and people doing all the CSS and JavaScript first, and only when they're ready they start adding actual content.

So, I find this to be really true. Maybe because it's easier to present a code solution to a design problem than it is to present a design solution to an extrinsic problem? But, this is exactly the problem I want to solve. I want to watch a screen cast of a designer solving a design problem the same way I can watch a screen cast of Ryan Bates solving a Rails problem.