Mockups & Wireframes
- Thread starter RDB
- Start date
Not here, never bothered with a "wire frame" for anything since I quit engineering.
Never seen the point of it for a HTML document layout, coloured pencils a straight edge and maybe a set of french curves works just as well, anything more is bit of a sledgehammer to crack the proverbial walnut.
I don't either. For most clients, I just describe what I'm going to do, maybe show them a color pallet. Some want to see more. For them, I use Style Tiles. Design comps and wire frames are too binding, plus they take up a bunch of extra time you don't need to be spending. I've had a scant few clients insist on comps. I didn't end up working with them. I prefer to convince them to trust me to do my job while reassuring them that I have a design in mind. I find it gives me a lot more room to work through the design and ultimately results in a better, more polished final product.
Last edited:
I agree in principle with both chris and ron, however as I am not solo, but working in a design studio I'm kind of forced to utilise wireframes and mockups.
...so I get from the designers a pdf wireframe of the website structure and a basic webtree to start from. Before it's even got to this point ideally we've discussed the information architecture, the content layout and objectives. However more often than not this isn't the case and I end up with a lot of "lorum ipsum" frustratingly.
in essence this waters down the wireframe to a pointless exercise, as from this point forward the design would dictate the content, and not the other way around - as it should be, and it merely becomes a sketch from which to work from. I'd usually print it out and peruse it on occasions.
However, after I've been delivered a wireframe, I go to work creating the structure of the site, whilst it's design is being done. We work together on the design, I demonstrate to them how the structure will perform at different viewports and they adjust the design accordingly.
They then give me an in-design mockup, i take what assets i need and style it up. once that's done we review the site across mobiles, devices, computers, platforms and browsers - referring to the design. there's usually a few red flags and arguments at this point, still useability should always trump over design.
spit and polish. appease the designers, than compress the hell out of it, because it's probably going to need it.
it also depends on the size and scope of the project. a well thought out wireframe for a comprehensive site is actually very handy...
...so I get from the designers a pdf wireframe of the website structure and a basic webtree to start from. Before it's even got to this point ideally we've discussed the information architecture, the content layout and objectives. However more often than not this isn't the case and I end up with a lot of "lorum ipsum" frustratingly.
in essence this waters down the wireframe to a pointless exercise, as from this point forward the design would dictate the content, and not the other way around - as it should be, and it merely becomes a sketch from which to work from. I'd usually print it out and peruse it on occasions.
However, after I've been delivered a wireframe, I go to work creating the structure of the site, whilst it's design is being done. We work together on the design, I demonstrate to them how the structure will perform at different viewports and they adjust the design accordingly.
They then give me an in-design mockup, i take what assets i need and style it up. once that's done we review the site across mobiles, devices, computers, platforms and browsers - referring to the design. there's usually a few red flags and arguments at this point, still useability should always trump over design.
spit and polish. appease the designers, than compress the hell out of it, because it's probably going to need it.
it also depends on the size and scope of the project. a well thought out wireframe for a comprehensive site is actually very handy...