You’ve been wireframed!
So I’ve recently gotten involved with a group called EmpowerHack who develop tech to aid female refugees both in transit and once they’ve actually arrived at their destination. I’ve dived into a website redesign project for charity Breaking Barriers, whose aim is to help refugees find meaningful employment once they arrive in the UK. Our challenge is to make the website more appealing to the refugees themselves as it is currently aimed at corporate partners and volunteers.
Last night, I attended my first design meeting and it was great. We discussed the UX and information architecture extensively, tossed around ideas and scribbled sketches on scraps of paper. I felt like I really understood what was needed and along with the rest of the team had the impetus to solve this particular problem.
I didn’t offer to do the wireframing because I’d never done it before, at least not with actual drawing software. However, it appears that it was written in the stars that this was one learning curve I’d be clambering up this week, as lack of manpower and time left our project manager in the rather desperate position of being forced to ask me to wireframe one of my concepts from last night.
I approached the task with Google Draw — a tool I was using for the first time — and a healthy dose of trepidation. As is often the case when faced with a blank page, my mind promptly emptied and minor panic set in. But not for long. Hadn’t I drawn this already (albeit inexpertly, my draftsmanship could use some work) at our design sprint? Didn’t it make perfect sense then and there?
I set to work drawing some boxes. Then realised what I really needed were three boxes the same size, so I deleted a few boxes, then copied and pasted. Then tried with varying degrees of success to lift images from the existing website to fit in the new design. And so on and so forth. It took a while, a good couple of hours at least. Probably much longer than it ought to have done…I’m given to understand that wireframes need to be cobbled together quickly and don’t need to look too pretty as the aim is to show the client how the website will function rather than the look and feel.
All of which makes perfect sense. Except…if you have two wireframes and one of them looks sexy and the other one looks, well, a bit messy, isn’t it going to be hard for the client not to be swayed by the look and feel?
Well, I got it as neat as I could and so far none of the team has gently suggested that another member could brush it up (though to be fair, there probably isn’t time), which I’m choosing to take as a good sign. But doing the wireframe taught me two things. Well, I say taught but really, these were points that I had considered but had yet to experience first hand. Namely:
- When I started actually pinning ideas to the screen and flicking back through the brief to make sure all necessary elements of the site were incorporated into the design, I started to realise just how many important details I had failed to take into account in my big ideas.
- I really started to question the wisdom of my layout when it was looking back at me from inside my computer.
Which, it seems to me, must be part of why we do this. Though admittedly, it is a bit galling, plopping down to earth and realising you might need to think a bit harder about your proposed solutions.
In the meantime, I’ve asked a UX friend about wireframing software she would recommend so that next time — and I hope that there will be a next time — I’ll be a bit more prepared and hopefully able to knock something together much quicker.
For now, I’m looking forward to doing a bit of website audit and hearing back from the client about our suggestions so that we can progress with dev. As my first ever actual real life project, there will surely be many stumbling blocks for me to overcome, which I’m happy to share with you to learn from or laugh at.
So stay tuned!
If you like this post, don’t forget to recommend and share it. Check out more great articles at Code Like A Girl.