If you work in web development, chances are you work mainly as a contractor—so you need a personal website. And the pressure's really on. Developer? You better have impeccable code, with all the newest stuff. Graphic designer? It better blow me away, but it's okay if it's a Squarespace site or something. UX Designer? It better feel perfectly thought out.
You know, but, no pressure.
So when I set out to build a personal website, I had to be careful about doing it the right way. I originally conceived of it as a straightforward portfolio site, but I realized later that the right way to tell the story of a design is, well, to tell the story.
With any design project, the first question is, Who is this for?
In the case of a site meant to showcase your work, the intended audience is definitely recruiters and potential employers. As far as I see it, a recruiter or potential employer is looking to (a) be wowed or (b) be scared off when they visit a potential hire's site. They're looking for a reason to advocate for you, or a reason to drop you. Which means the things you highlight need to show that you're thoughtful in your work, clever, and able to get to the point.
So what did I need to put on the site to show them those things?
Asking myself this question followed the typical "EVERYTHING!" >> "Wait... maybe... nothing?" >> "Okay, some things" progression that basically every design goes through. I threw everything and the kitchen sink in, then I took everything out, then I put back just the things that fit.
I boiled it down to really just two things:
Case studies are a pretty open-ended opportunity for me to talk about my experience and thought processes, and a contact form is pretty self-explanatory.
I originally added, and later removed, an "About Me" page, an explicit "Resume" page, and some miscellaneous other links. I figure, if this site is for professional reasons, you don't really need an "About Me" page. There are plenty of those scattered across the web already, and I've got a pretty unique name if you want to search for me. As for a Resume page, it seems like standard resume or similar services are perfectly functional already.
I started out by quickly mocking up some ideas in Sketch. I started with some of the basic conventions of an article-based website: a header section with static information, with a feed of article tiles below it. I sketched it out as some header text at the top, and some boxes below that:
the initial Sketch mockups, for browser and mobile
Next, I made a simple HTML mockup to test it out in a browser:
the first HTML mockup for this site, with bonus flying kick stock images
I started playing around with what article pages world look like. Originally, I thought maybe I'd carry the card notion from the homepage forward into the articles:
original article design
And... one of the first things I realized was that this was terrible to look at. It needed to be simpler. So when I moved the whole thing to a remote server to start developing it, I gutted the article page and left it as plain text on a blank page.
Once I moved the initial html mockup files to a remote server (in my case, I use DigitalOcean), I started testing the design.
To test in iOS, I used the Simulator app that comes with Xcode for macOS—something I really can't recommend highly enough! Simulator emulates an iOS device on your mac, but the magical thing about it is that when you turn on the dev tools in Safari, you can use the dev tools to inspect the DOM in iOS Safari in Simulator. Which is to say, you can finally figure out why the hell everything is coming out wrong in your carefully planned design when viewed on a phone.
this site, in Simulator on macOS
I think Safari's dev tools will also let you inspect the DOM in Safari from your live iOS device, as long as you're signed in to the same iCloud account and using the same wifi, but it's more reliable and less hassle to just use the emulated device.
Because I wanted to include a contact form, I knew the site would need to have a real backend. Plus, being a collection of articles, I figured it would be easier to manage them with a database, rather than hard-coding everything.
Seemed like an excellent excuse to teach myself how to set up a LAMP stack.
After I got my backend in order, I basically just kept iteratively testing to get to where the site is now.
At a very BASIC level, the loop went like this:
10: Make changes 20: See if the changes make sense 30: GOTO 10 40: Be satisfied with it
For example, I thought early on that the article tiles on the homepage would include a lot more information—not just the article title, but a little summary, plus the date it was published. This all seemed great when the design was hypothetical. With junk data or greeking in Sketch, it made a lot of sense. But when I actually put real data in there, I realized that it didn't matter. All that stuff was a lot of noise! It also wasn't very discoverable, beinh hidden in a hover. So I just took it out.
Another example is code blocks like the one above. I knew I wanted to include some code blocks in articles, but it took several refinements over the course of writing these initial articles before I knew exactly how I wanted them to behave, and how I wanted them to be arranged within the text.
I've also been very lucky that my wife is also a UX designer, because I can bounce ideas off of her, and pester her with new ideas.
I've put the entire codebase for this site on github, where you can see (for better or worse), that I actually did all this myself.