Design

Prototyping

A year ago, I moved into the UX department of a large agency. As a front-ender, I was going into a part of the business where I’d have to learn new skills and leave a lot of the old ones behind. Or so I thought.

For ten years now, I’ve worked with HTML and CSS daily. I’ve got pretty good at it. I’m pretty handy when it comes to making a responsive website and find designing in the browser much easier than delving straight into Photoshop.

These were skills I thought would be of limited use in the UX team. I’d be able to offer advice but it was unlikely I’d do much “coding up”

But the attitude changed when I saw how much could be achieved by actually building stuff to demonstrate stuff with UX in mind. It was then we started to look at maybe moving from the traditional method of PSDs first to HTML wireframes or prototypes.

The plan we had was to build up in layers. You start off with minimal content, just grey boxes would do and you would build up in detail as you got more. With the introduction of design styleguides and more detailed HTML wireframes, we were convinced it would add more value to a project and what the client would be expecting and when.

It made perfect sense to us to build this way.

Dan’s Magical Land of Designing in the Browser

  • Step 1. Sketch with everyone
  • Step 2. Turn sketches into HTML and CSS prototype (Basic)
  • Step 3. Style Guides
  • Step 4. Introduce style guides into the prototype
  • Step 5. Show client
  • Step 6. Feel happy client loves the prototype
  • Step 7. Build the actual site
  • Step 8. Get site featured in .Net magazine

Now I’ve missed out a fair few steps here. I’ve not even touched on content. Ideally, you’d have the content before you start. You’d know what needs saying and where and that makes your life so much easier. But life isn’t like that so you have to assume the prototype is either existing content, lorem ispum or you have indeed been given the content…but I doubt that.

The trick to get the whole process working is everyone sees value. The client sees some pretty stuff, they see progress and they see or hopefully see you know what you are doing. You get to charge for a prototype and a style guide. It’s a win win.

Alas it never really took off at the agency, for various reasons. Reasons that I’m sure everyone faces. We learnt a lot from the process but it really needed the buy in from everyone. Either it was the client not quite understanding why they had seen a polished homepage design a few weeks back and now all they saw was grey boxes and unstyled text, or it was due to the schedule and a designer had ended up designing stuff away from the prototype which then meant things were out of sync.

To make it work, we realised that things would have to change. It’s a completely new way of working and it only takes one thing to mess it up.

A month or so ago, I moved jobs moving into a smaller agency where I’d have more control on the output. Like the last place, prototypes were just something they read about in .Net magazine but it was now my role to implement them if I saw fit.

Which I did or still do.

I’ve been to a few conferences over the past 2 years and one thing I am more than certain on is that I am on the right path with my way of working. It’s not as easy to get to the magical land of designing in the browser like I thought but we’re getting there.

Since joining, I’ve built two prototypes, each better than the last one I made. We’re starting to look at components and making a library. Why reinvent the wheel every time. Having a codebase of things you know work is invaluable. It saves a shed load of time too plus it looks great on your github account.

I’ve recently started using Hammer for Mac again. I’m able to really strip the prototype down into mini partials for everything. This allows me to sit with the client either face to face or on the phone and switch out pretty much anything quickly.

So what do the clients think of them Dan?

We’ll find out soon enough hopefully. Hey, I’m under no illusions people won’t get it every time, just like they don’t get what responsive is. But I firmly believe over time, you get more polished at showing this kind of stuff and having belief in it is a big plus point which of course I do.

So are the days of full PSD site reveals over with? I hope so. My biggest gripe with PSD reveals is that so much time is spent refining something that will likely be binned or stored in a design folder somewhere while a front-ender recreates everything again in CSS and HTML. Why not just do that from the start? Or at least set the mood with the style guide. You can make stuff look polished after that and still add value and in Photoshop too.

To end with, prototypes are pretty cool from my point of view. They might not be everyone’s cup of tea especially clients and non technical designers but the potential is there to cut costs or at least allow you to allocate budgets elsewhere in the project, save time and solve problems you might not normally see up until the end of the project.

Are there downsides? Yes, most certainly. Content is still the most important thing on the website, that will never ever change and until we sort that problem out, a prototype is still a lot of guess work and could go wrong. In my magical land of designing in the browser, the content is delivered by an owl on project day 1.

We’re not there yet.

  • My worry is that there seems a lot between step 1 and step 5 (show the client)?

    • Like I said in the article, I missed a lot of steps out 🙂

  • Vincent Koopmans

    The issue with this in my opinion as a Designer is, when you design a product you do not start with a style guide, that is a deliverable at the end of the design journey. You sketch, iterate and improve the same as UX does. And preferably in context thus not in individual components.

    • No but that is something you deliver at the end of a phase. Sketching is important.

  • driesdelaey

    Hey Dan.

    Here’s an obstacle I’m experiencing while prototyping:

    to gain some speed (thus time thus budget) one could use a framework (like there’s (too) many out there nowadays). The thing is, we don’t want this bloated code in our production site, so we’ld have to start over in production.

    or we could just write plain custom html/css/js – ready for production. Here I wonder (it might be just me) if we don’t put a hole lot of time & effort in a ‘design proposal’ – which the client might not even like (although if a client really doesn’t like what you’ve made, you haven’t really listened to him/her to start with 🙂

    Even in the last case, the clean code will need to be re-applied to whatever the CMS outputs (or ofcourse, you know – we bend the CMS in what we want it to output)

    Don’t get me wrong, I DO want to get rid of PS for designing (full comp) websites (for full comp-designing, ofcourse I’ll use it for you know … editing graphics 🙂 But it’s certainly a dilemma I’ve been struggling with for quite a time.

    So my question: do you write production-ready code (which you implement in a CMS) or use a framework(-bloated) code which gets trashed when starting development?

    (btw, show us a date on your blogpost please 🙂

    • Hello

      I try to write production ready code but I’m finding the amend phase is rushed and I end up rushing stuff rather than make it clean. That’s a personal thing though.

      Date? On this blog post? That’s out of my control sorry as it’s not my site. I just had the article published here 🙂

Subscribe to our mailing list