In my last article I discussed the need for the design team to adapt their process; helping the whole team deliver quicker and getting valuable feedback from the customer as soon as possible. One of the areas I mentioned was the process of designing ‘in-browser’, but ask any designer or design team their thoughts on adopting this new process and you’ll get a mixed response and most probably start a heated debate. So first I’m going to take a look at the current process and identify the problems and waste created, then examine how design-in-browser can help. Only then can we really start to answer the question ‘are we ready?’
The traditional design process
Every design team has its own unique process evolved from the personalities, leadership and skills within the team, yet they all share some new problems whether they are multi-skilled large teams (UX, IA, interaction designers, graphic designers, copy writers) or smaller specialist teams. These new problems raise some interesting questions about the traditional process:
- Wireframes are a massive waste. First we make the wireframe, then we make the wireframe again in HTML. Why not just do things once?
- We focus too much on the visual details before we know the thing works. Are we taking too big a risk on something we don’t know?
- Photoshop files are not interactive. How do we test usability on something thats not usable?
- We’re no longer designing for 1024 pixel screens so we end up designing multiple versions to demonstrate our designs in different devices. Is there a better way to design to fit all devices?
- We hide behind our designs waiting for perfection before we share. Can we help our designers design in the open?
- The traditional static comp is a bad deliverable; hard for clients to understand and confusing as a hand-over for developers. Is there a better way to deliver a design?
- Iterations take time making feedback slow. How can we get faster and more collaborative?
- We’re still slicing up images for the build team. Do we really need to do this any more?
- Documentation – No one likes writing it and it never gets read. Is it a deliverable for the sake of it? Can’t we just see how it works?
The design-in-browser process
A few years ago there was simply no argument for design-in-browser; front-end development was a bit of a hack – we used lots of images (shadows, corners, gradients etc), we had restricted fonts, our typography skills where forgotten, we simply couldn’t build a site without having a design in pixels first. That was the job of the designer. But technology has moved on. As CSS is now much slicker and all of these issues have been resolved, is design in-browser really an option? How can it enable us to work quicker, smarter and better?
- Design-in-browser forces you to make the content lead the design.
- There is no better way to test your design than by actually testing your design.
- Design-in-browser is responsive by default, enabling design for multiple devices without multiple versions.
- We can present rich, useable HTML to demonstrate the design (both visually and in the way it feels to use), rather than static comps.
- CSS allows quick iterations, making real-time collaboration possible across multiple locations.
- Move forward with something more real at every stage, to start building the final product in the design stage.
- The design itself is the wireframe, visual design, sliced up assets and the documentation in one.
Are we ready?
It’s very clear that design-in-browser can dramatically reduce the waste, and improve workflow, but more importantly it gets the whole team (clients, designers, developers) focused on the product rather than the deliverables. But are we ready?
As designers we need to start getting our hands dirty and get making as well as creating. We’ll need to pick up some new skills along the way, such as HTML, CSS and JavaScript. But most importantly we need to understand our place in the overall product delivery process as only then will we realise the true benefits of design-in-browser.