If you work in web development, chances are you work mainly as a contractor—so you need a portfolio website. And the pressure's really on. Developer? Demonstrate that you can learn quickly, work with uncertainty, and use novel tools. Graphic designer? It better blow me away. Product Designer? All of the above.
You know, but, no pressure.
So when I set out to build a portfolio website, I wanted to do it the right way.
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 ended up just linking to the most recent pdf version of my resume in the nav bar.
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:
Next, I made a simple HTML mockup to test it out in a browser:
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:
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.
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.
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.
But of course the real test is: does it work on real users? I set up FullStory and Google Analytics so I can see how real people interact with the site when they visit, and I'm making a habit of asking for feedback when I speak with recruiters and potential employers.
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, and how the site has changed over time.