Whenever I try to google for front end design I get a lot of hits for JS, HTML, CSS...but it's not the coding part with which I am struggling, I feel like I don't have a vision of how things should be put together or why. What's even more frustrating is that I've been around long enough to know the basic building blocks and so it feels like I have all the parts sitting in front of me, I just can't put them together. I have tried decomposing other people's designs, but whenever I try to apply the results, it ends up looking like a poor copy.
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.
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.
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/
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?
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 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
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.
Your points below are also excellent. Thank you very much!
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.
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.
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.
>>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.