It's still too early obviously BUT from a web development perspective, I'm wondering if it's a bit overkill to just focus on type, and even redundant maybe.

The fonts shown in the page are mostly for display use and at any given page you're bound to use these sparingly. I've seen a few and the bitmap ones do get a little too big for it's purpose.

Assuming you're going to use it on just a few words, why bother downloading a 3 MB font file where you can do the same thing with a much smaller SVG or other responsive image methods?

I do agree that it may very well be the next big thing, I'm pretty sure it will spread like wildfire but I just don't want every single website out there to load, relatively, a lot slower moving forward with this tech.

I think the delivery mechanisms and how these files are loaded in a page should also be explored and tested on.

Just my 2 cents, you don't necessarily need to learn a whole language before building a prototype.

In fact, it is almost certainly better to try validating your idea before building anything. That's the basic idea behind Lean startups.

That said, I do see where you're coming from and if it comes down to it I'd suggest starting with a simpler back-end service/API such as Firebase to build prototypes first. It has a free plan, can scale without problems if you decide to stick to it, and it will be relatively much more secure than anything you can write yourself as a starting backend engineer.

We had recently run into issues growing our icon library at Jotform, so we're making the switch to SVG as well.

With SVG, I think it's <symbol> or bust. But once you have that setup, it's a breeze to work with them. We are working with React + Webpack, so we're using svg-sprite-loader but there are other npm libraries that work with task runners. I highly suggest using svg sprites with symbols. It basically offers everything an icon font can and more.

I had written about it if you'd like to give it a read: Our Icon Workflow

Hi, author here. Definitely agree with the TLDR, you definitely shouldn't use React just for an icon workflow.

With that said, there's no reason why this can't be done on php or any other serverside technology. Libraries for generating SVG sprites already exist on npm, I'm sure it can be done on php as well.

React happens to be our chosen framework, and plays nicely into our method because of its component-based logic. It might get a bit more tricky, but again, it's possible to implement a very simple component logic in any JS framework.

Hey Austin!

I agree with everything you say here but I'm curious to hear your thoughts on a specific issue.

I choose to design for my specific audience and product

First off, I do realize that this is very product-dependant and may not apply everywhere, but:

What if you think there's a substantial potential market on mobile for a given product with similar usage statistics (e.g. 80% desktop)?

How would you know if you're missing out on a big market by catering to existing customer base only?

Obviously, research would be needed to validate hypotheses, just wondering how would you react to such a dilemma.

Thanks.

Hey Gregory!

1. Thanks! There were many sleepless nights :)

2. There were a few different versions of that headline, most notably one with a typographic arrangement, sort of like a mid century sign painter style, and another one with swashes/decorations. All of them felt a bit too much and cluttered so I decided on the simpler one. ¶ The current hover effect is kind of a result of the design choices made while designing the projects list itself. I have tried a lot of variations on there, ultimately decided against having big images or big cards for each project. ¶ My opinion is that deciding on which project to click on is mostly an arbitrary decision, there's no real driving factor other than a match with the project industry and a potential recruiters industry. So I decided to ditch everything else and keep the project name and scope only, with a very light touch of iconography to spice things up a bit. ¶ I do realize that they may not be sending a very clear cut signal about being interactive, that's why I wanted the hover animation to be a bit over the top in order to reduce the chances of a visitor missing those links. But, for what its worth I'm not super confident in those, I may update them soon. Any suggestions? :)

3. It seemed like a good idea then but I'm not so sure. The idea was to define marked areas for the state a recruiter might be in. Kinda like: Not convinced -> go to top left. Convinced -> go to top right. What do you think about this?

4. I did something to prevent the double scroll, then decided against implementing it because it required people to click on the previewer to see the screenshots. I'll be revisiting this in the future.

5. Because I couldn't find the time to implement a lightbox :) On my todo list.

6. I have read a few of the articles a while ago but I do need to go over them again. Thanks for sharing this!

7. Lagavulin 16 :)

Do you think that double scroll is an issue?

I noticed it as well and I already have a solution for that, but then decided not to do it because it requires the user the click on the previewer. it's basically a click to preview thing.

My reasoning was that recruiters would already have a very limited amount of time for reviewing my work, therefore I did not want to elongate the process with an extra click.

What are your thoughts on this?

Oh wow, thank you so much for taking your time to write this up, I really appreciate it!

You've brought up some really good points, I'll definitely be reworking some parts and spend more time on the copy.

I haven't run into the scrollbar overlap issue, do you mind sending me a screenshot?

Thanks a lot man!

Did that put you off at any point?

Personally, I want visitors to click and drill down into case study pages because I think the content I have in there is really too dense to be boiled down into a single image or visual.

On the other hand, I am worried about not being able to generate enough interest and excitement for the visitor to drill down, so there's that. I would love to hear your thoughts on this :)

That's a very sweeping statement.

Yeah, sample sizes are usually minuscule because user testing is expensive. You need to either cash in or have dedicated researchers.

But it doesn't make it any less useful. ANY conversation you can have with your customers is immensely more valuable than anything else you can do for your business. User testing is a way to do just that.

Empathy will take you so far. We all make tons of assumptions along the way and you just have to validate your claims at some point. There's just no other way forward.

If you really champion empathy, you get off your high horse and start doing user testing & conducting interviews to get to know your customers.