For as long as I’ve been on the Internet (well, the Internet as my generation knows it ;), developers and designers have usually maintained some type of display of their work and it’s generally consisted of a listing of projects that they’ve completed with outbound links to said project.
I’ve toyed with the idea of going into detail as to how I’ve built certain projects – you can see this in posts such as how I built Category Sticky Post and Tag Sticky Post – but I’ve never gone all in as I’ve never sold on if it was of any interest to others.
But yesterday, Smashing Magazine ran a bit of a motivational post on Retiring The Portfolio Screenshot and focusing more on “case study” type posts.
This got me thinking about beginning to introduce a case study on WordPress projects.
Retiring The Portfolio Screenshot
I highly recommend reading the article in full, but I wanted to capture a few of the key points here in order to give some context in what I’m planning to do moving forward with my own work:
- “Opting for a more detailed approach to displaying your work opens the door to a more creative approach to your portfolio.”
- “Many clients these days are showing an active desire to actually share more resources, processes and code.”
- “Next time you’re adding a project to your portfolio, perhaps consider writing it up in a bit more detail and turning it into a case study.”
Interesting points, right? So here’s where I’m planning to take all of this.
WordPress Case Study: How Projects Are Built
Obviously, I’ve done a few of these types of posts already:
- Building Category Stick Post and Tag Sticky Post
- Building Single Post Message
- Building Comment Images
Initially, I wrote these posts as a way to share a little bit of my approach to creating some of the smaller plugins, but I’ve never done any in-depth posts on contract jobs or on some of the work done at 8BIT and I’d like to change that.
I’d love to begin introducing a new type of post where I share case studies based on the work that I’ve released (contract-permitting). Each of these types of post will include the following content:
- Vision and goal of the project
- How requirements were gathered and scoped
- Planning the architecture of the project
- Planning the design of the project
- Preliminary screenshots, sketches, mocks, diagrams, and/or designs
- Development-based challenges including anything from writing code to capturing and squashing bugs
- Final version information and where you can find the live version of the product
Ultimately, I hope to have a consistent outline – perhaps even a template – that makes drafting these posts even easier. Obviously, they have potential to be quite long.
Is it worth it?
I think that sharing your thought process online is productive if for no other reason than documenting your work, but what’s to motivate me to publish it online instead of writing it down in a personal notebook?
Sure, I always enjoy seeing what others have had to say, learning from their mistakes and successes, and trying out new approaches and/or techniques, but I also know that some of my posts that provide insight on how I approached a given project have had the lowest engagement with only a fair amount of traffic.
So I’m wondering if these types of posts are of interest to others? In the comments, let me know your thoughts. Additionally, I’d love to know what you guys look for in a case study on WordPress projects and if you plan on doing the same.
I think it’d be neat to have as many developers as possible sharing their process and their final work especially in the WordPress space.
I think this is an awesome idea and appreciate you sharing it as it has gotten me thinking about how I should present my work on my own site. Makes a lot of sense to share details of your work behind the design and reasons for decisions. Gives confidence for potential clients.
Noted!
Planning to do this with a project that I’m wrapping up later this month, although I think Brady brings up a really good point in that by the end of a project, we may not be showcasing our best work.
Regardless, perhaps that’s just one more point to discuss.
Hey Tom – yup, I’d personally love to read more about dev/designer’s processes when approaching a project. Often times there’s great stories to tell; lessons learned, challenges along the way – that a screen shot can’t tell.
And it’s not just those “Blah company was looking for a re-brand and we decided to give this a shot” descriptions, it’s the more personal, informal ones that are interesting to me. Thanks!
Sure thing, Zach.
Agreed, too – this wouldn’t be “Acme Company was looking for a rebrand and I was delighted to deliver.” Negative.
This would basically be a developers take on everything that went into making a project: From managing requirements and scope to staging and deployment strategies, and from handling architectural decisions to actual implementation and the tradeoffs therein.
I could certainly see that the posts on how you approach something have the least amount of long term traffic, but I think it has to do with the audience it reaches. The audience for that has to have some sort of technical chops to start with so they can follow your workflow and have something to compare it against. If they’re not building sites of the same caliber (apps instead of blogs) then they may not even have a way to evaluate your process, since they don’t have one.
I’d love to read the posts. Most often the thing I miss about working solo is no way to really bounce the way I approach problems off others.
This is smart – good point.
Completely understand. I’m fortunate enough to divide by time between working with a team and working solo, so I get the benefits of both worlds, but I definitely recognize the challenges that come with doing it alone.
Cool stuff – hopefully doing this will help start some good discussion certain development decisions.
Dooo it! Love these kinds of posts. My portfolio has been in this format for a couple of years, though maybe not in the detail you are considering. To add details, I usually just write a blog post and link to it from the portfolio item. Some of my more popular blog posts have been posts about projects. Sometimes they’ve stirred the pot a bit too: http://bradt.ca/blog/migrating-from-typo3-to-wordpress/#comments :)
Such is the nature of popular posts, right?
People are always going to share their opinions – be it opposing or not – which is what makes blogging fun, but it’s lame when they go about it in a rude or pretentious way.
At any rate, thanks for the comment – at this point, I think it’s something I’m going to consider doing.
Count me among the interested!
We’ve actually be considering doing something similar with our projects at Blazer Six, but like most everything else, we haven’t paid it much attention due to the focus on client work.
Unfortunately, it seems like by the time I finish most projects, I see all of the decisions, tradeoffs, and areas where things could be improved and don’t feel it’s representative of my best work. Upon revisiting after awhile, the perceived shortcomings usually aren’t so glaring, but the reason for making certain decisions and creative solutions aren’t as sharp, either.
I can completely identify with this. In fact, I think most developers can. Because of that, it makes it difficult to want to share a lot of stuff we do at the risk of looking less capable.
Maybe that’s even more of a reason to share more detailed posts :).
I can understand the fear of putting projects out there for all to see that may not be up to par in our minds. From being on the other end as well and researching development teams to hire, I would much rather see openness from the team or developer on how they built a certain product and the methods that they used. It gives much more confidence for the person looking to hire a developer.
I would think listing some of the things that you would do differently next time and why would be a decent way of acknowledging stuff like that. Though I guess you do have to wonder what a client might think if they read you’d build it different just after you get them to pay you.
Please do.
Noted. :)
I would love to ready more post along the lines of “how we did it/solved the problem”, think it would be a fantastic way to learn more cool stuff!
You’ve got it – aiming to start this as soon as I have a chance.