12in12: Dev Bones

The Side Project Project: May Recap

By now wildly differing side projects shouldn’t come as a surprise. April’s adventures in paper folding and origami dinosaur army gave way to a swing in the opposite direction with Dev Bones: an all digital development skeleton to kickstart your next website.

Revealing the bones on the Dev Bones landing page

The Project: Dev Bones

Sifting through old projects on GitHub grabbing the same old bits of metadata and basic elements is my least favourite part of starting to build any web project. Dev Bones is the answer to the protests of my inner laziness: providing a skeleton to get started and customised elements along with my most frequently referenced resources. Plus it gave me an excuse to write zombie-themed copy and photoshop skeletons. What’s not to like?

Check it out here: Dev Bones

Reveal the bones!

The Checklist

• Created a customised HTML template for my usual starter skeleton so I won’t have to raid old repos every time I want to create a new site.
• Built up a (small) collection of some common bits of HTML & CSS that I can grab and go.
• Icing on the cake: bundled it all up into a repo on GitHub complete with links to my most frequent references and skeletal themed from head to toe.
• Decided to be an idiot and raid my old Grunt task files to make a second, more fleshed out template (the zombie) with SCSS and scripts ready to compile and minify at a single command. More effort than it should have been and by no means a perfect build but happy because it means it significantly lowers the overhead to get started with those sort of builds and means I’ll have no lazy excuse not to play around with that in future.
• Got carried away with skeleton stock art and built a thematic, transforming landing page for Dev Bones allowing you to reveal the ‘bones’ of the site.
• Brushed up on my grid (both CSS and in terms of traditional planning) skills and working with illustrations in a style outside of my own creations.

The Undone

• On the actual side project, for once, nothing. I got the icing on the cake and more. Content-wise there is much more I would have liked to packed in and testing + build improvements but MVP was more than hit so I’ll have to be satisfied (for now).
• I tell a lie. I would have liked to have included more around animation and transitions.
• As far as my placement report goes, that turned into an utter undone once I found out the due date had been pushed back and, considering my placement is still in progress, I opted to shift focus.

Overall Dev Bones proved surprisingly successful as a side project, especially for one I was unsure about at the start. Not only were most of the original goals met or surpassed, it also reminded me of the joy of crafting sites as mini thematic experiences and sharing content that is (ideally) helpful to others.

My last few side projects have been more inward focused, diving into personal hobbies or craft for the sake of it. That’s all perfectly fine but I had forgotten the different creative itch scratched when creating content designed to be consumed and empower. I had thought this outward focus would be more difficult with current family situations making me more inclined to turn inward and tread carefully while planning knowing I might not be in the best state of mind to finish a project to the level I would like. Dev Bones was an opportunity to get back to sharing learnings & building more in the open the way that I prefer and already I’m shaking up my next side project to be more outward focused.

*point*

Highlights of the Month

On the Side:

• Procrastinating on actual side project by dabbling in sculpture, from a wire ram to helping construct a human-sized, modular nest for my mom’s art project. Writing this, I realise my mom’s projects are cooler than mine. Clearly I need to up my game.
• Getting back to the joy of silly, over the top themes, crafting graphic layouts, building in that unexpected surprise, and making them all work together as part of the story.

At Work:

• Facilitated my first official usability test!
• Seeing the team motivated to respond to feedback from the usability tests and plotting the necessary improvements.
• So many big chunks of work landing in development. Despite all the unfortunately necessary compromises and simplifying it takes to get the first iteration into development, it’s still great to see big changes you’ve helped work on appear in the product.

A few iterations (aka getting carried away with skeletons)

Lessons Learnt

*Warning: jam packed month at work means this is a long one*

Smooth workflow ≠ smooth usage

Learning at work:

The usability testing sessions were eye opening and while many of the issues encountered were known or suspected, watching users actually use the product for the first time was amazing. It is so easy to think of a workflow as those predefined steps and look at the issues within those but that can all break down in practice. The flow might be 4 steps but to users that might look more like 6 steps as they go backwards and forwards and lose context. When it comes to addressing these issues, it’s all the more important to zoom out. Identify the key workflows. Not ‘wizards’, but user workflows. They may start outside a ‘wizard’ or discrete chunk of the UI.

Applying on the side project:

I originally considered breaking the boilerplates down and having a more step by step, ‘choose your path’ approach to selecting the appropriate template, setting it up, and grabbing extra bits but this felt like forcing a workflow on it when I didn’t know how others’ setup process might differ from my own. In the end, I put all the tools out there and suggested a vague structure but left it open.

Preparing the bones (of the not code variety)

Start simple, think modular

Learning at work:

With features being broken down into smaller chunks and changing scope, it can be challenging to balance casting a vision with delivering something feasible to engineering. Vision is extremely important but then comes drilling down to what is strictly necessary and starting there. No point jumping ahead always making more and more complicated visualisations if you can’t distil the essence because who knows how things will change by the time you get to that stage and have gathered feedback.

Applying on the side project:

For Dev Bones the whole point is to be modular so before starting I broke the project into the core MVP (a single skeleton template, development resources) and ‘nice to have’ items (fleshed out template, css snippets, website) which were all modular by design and could exist with or without each other. Each one of those then got broken down again to the essential elements (ex: for the website, the core goal was a landing page to explain the project and link to the source code. Stretch goals were to layer on the detailed section breakdown and ‘click to reveal’ to switch to the bones view).

What do your choices say?

Learning on the side project:

The website was one stretch goal I didn’t actually expect to get to and it had to fit in as time allowed. With the skeletal theme already decided, I dove straight into a quick fire round of sketching. Almost immediately I caught my brain defaulting to sketching icons for each feature of the boilerplate kit or a minimal, black and white design. It was a turning point when I stopped to ask why? What does this say about the project? Does it say it’s another web project with perfect vector icons and 4px radius buttons or does it convey the tongue-in-cheek, rough and ready but carefully considered design of these flesh and bones? That’s when I went 180 on the creative direction to focus on classical, skeletal illustrations and showing off the sketchy bones of code.

Still learning at work:

Don’t fixate on the execution/style and forget what that layout says. Sometimes when taking a sketch to screen I can find it easy to start quickly framing the layout and figuring out how best to flesh out each sketchy element and then wondering why it feels off. Sometimes you need to stop redesigning the layout and look at what the specifics of the layout are saying. Maybe the elements don’t need to change but they are grouped too closely together, implying more connections? A seeming simple or unnoticed thing like a line, similar font size, or a few pixels can change how someone perceives the relationship between elements and the design as a whole.

Getting started with the Dev Bones repo and resources

Don’t forget the beginning

Learning on the side project:

I have a confession: I left the repo write ups in Dev Bones until last (though my semi-excuse was that I didn’t know what content there would be to write up until I was done). Shameful thing to do to documentation but it did force me to take a step back and think about the project from a new perspective. Normally I write code for myself but Dev Bones code is designed for others to pull from so it required approaching from that angle.

Applying at work:

On the job there is a good mix of designing new features but also redesigning existing work. Even with the new, sometimes it’s easy to assume a certain pattern or standard should be applied but it’s important to keep questioning. Keep questioning. Just because that’s how it was done before, doesn’t mean it should stay that way. It only has a chance of changing if someone stops and asks why. By equal measure, just because something was better than what was there, doesn’t mean it’s good or couldn’t be better. There will always be rework. You can’t design the perfect thing right off the bat so stop sweating it

Plan your dive

Learning at work:

Challenges are part of life, especially if you’re a designer and that’s what you’re there to solve. So when I see a problem (or an opportunity), diving in headfirst is not an uncommon reaction. The important bit is not forgetting to plan the dive. Even if something seems simple or has an ‘obvious’ answer, stop, ask questions, and gather the relevant information. Don’t get so caught up in what people are saying that you forget to look for yourself and consider what is actually the challenge? What is unknown? Yes we want to fix the problem as quickly as possible but need to stop and take a breath to get it right. Yes dive in but that doesn’t necessarily mean straight to sketching UI. Don’t forget to consider if the problem you’re diving into is even the right one.

Applying on the side project:

Jumping back into code after a break, my first instinct was to start grabbing bits, playing around, and generally patching together a template for myself from the collected knowledge of past projects. Not necessarily the best approach but it did open my eyes to the potential pitfalls as I realised I couldn’t remember some of the elements (such as using Grunt task runner) and had to relearn as I went. This forced me to consider what it would be like coming to this code fresh and structure the documentation to help. In the end, I spent as much time plotting and replotting the file structures to be logical and easy to use as getting the zombie template to build properly.

My favourite skeleton stock art ever. Just look at that pose! Also what happens when you finish putting together website assets at midnight: bones-copy copy 2

Bits & Bobs

• Obvious always wins. Especially in cases where you have a lot of marginal decisions to make.
• Just talk to people. Practiced rolling up to desks as a first response instead of Slack and got answers so much faster. Just need to balance with not bugging everyone.
• Take your time to provide background, set the stage, explain why, and all that. Take as much time as you need.
• The next steps of usability should never just be UX. It’s a product/team ownership. All need to triage on issues and ask how/why these happened, what to do, and how to tackle them. How did our process allow us to get to this point?
• Everything is a negotiation.
• Usability testing is an observation not a conversation.
• Embrace the awkward and step boldly into it. To quote one of my colleagues from across the pond: “you’re not an asshole so be confident”
• Don’t be ‘shy’ about getting things to spec. Know where to compromise, but don’t be flippant or assume ‘that’s just how it is’ is something doesn’t quite sit right.
• Cast your net wider. Don’t just make the narrow fix in the area you’re working on and forget a way to nip an issue in the bud elsewhere.
• Know what to test and what not to. What comes down to opinion and what doesn’t.
• With forms, start from scratch and forget the interface. Write down what you actually need, in the simplest form. Build up from there only if necessary.

[IMG]

Did you know you can still get that classic audio? Tempted to set it as my new text tone…

Next Time:

It’s been a busy few weeks at work and I procrastinated on writing up this review. Better up my game because next month’s projects will involve yet more writing and designing for a totally new to me format. What could go wrong? Only one way to find out.

To find out more about The Side Project Project, see how it all began here.