The case for lo-fi wireframes and concepts
A story about the parallels between managing stakeholders and stoking IC creativity
Whether you’re working for yourselves on original IP or working with external clients or partners, ample communication around the design process early on is essential for managing expectations, tuning the UX, and avoiding costly scope changes in the future.
I’ve learned that the devil really is in the details.
Stakeholders come in many different flavours, and there is a science to presenting design proposals that can be understood by someone with zero design knowledge while appealing to a designer with years of experience at the same time.
I have made the mistake of trying to impress at the beginning of a project by creating beautiful mockups that also served the purpose of wireframes: communicating how something will function. Because style and function were negotiable, mixing the two together proved to be a fatal mistake.
I spent time making the screens look as final as possible, with stock images that I intended to replace with custom illustrations. I designed two UI elements in one particular style but also presented 5 or 6 additional style options alongside it. I laboured over the details and made it clear that they were merely suggestions and open to discussion. The clients had only a few small comments here and there, mostly unrelated to the functionality, and they seemed to be enthralled with how things were going.
I took this to mean that they understood everything that I had told them: that some parts of the design were placeholders, some needed to be voted on, some functionality was set in stone due to the nature of the platform, and others were flexible.
I was so wrong.
I began replacing graphics with new ones, developing the rest of the UI style (I had only presented buttons and typefaces), and what I ended up with was something that looked quite different from what I presented at the beginning. I sought out and hired a talented illustrator and we worked out a style that we thought would suit the product much more than the placeholder stock images. Thinking we had sign-off, we hadn’t arranged any other meetings with them and I spent quite a bit of time with our team working towards more and more final designs. When we felt ready, I presented it to them, and it couldn’t have gone worse.
It was deeply upsetting and confusing to the client.
Even though my initial presentation was clear, the problem was that I had presented too much information all at once. But because I didn’t receive any signals otherwise, I thought I had the green light to proceed with everything I said we would do. But all they could say now was that the product looked so different from the initial designs and that this was completely unexpected. In hindsight, the caveats on unfinished work that looked very polished were probably difficult to keep track of, and they likely made a lot less sense than I thought they would.
The more projects we started for new clients on the same platform, the more I learned that it doesn’t matter at all what you say about the visuals and precisely what stage they’re at. A small percentage of people who are familiar with the product design process will pick up on the info, but most will not. Presenting high-fidelity, polished designs signals to the audience nothing more than, “This is it!”
Ultimately, this is what I learned:
separate visuals demonstrating functionality from visuals showing aesthetics
anything to do with functionality and UX should look as basic and unstyled as possible
assuming sign-off and working for months without communication was irrefutably and obviously a bad idea
The Parallels
Even if a client relationship is not a factor and the team is experienced, mockups and specs with too much detail can also lead to sticky situations. When presenting a spec or an idea to a designer to work on, similar rules apply but for different reasons.
Much like in user testing and survey making, too much leading information can be a trap. Sometimes people who write specs (be it UX designers, product managers, or game designers) are skilled with design tools and can bust out extremely detailed wireframes and layouts for UI artists to do their magic on.
I’ve noticed a strong correlation between providing a more detailed wireframe and the UI designer taking much less creative freedom.
It’s easier to build a nice-looking layout based on detailed wireframes without taking risks or experimenting. That labour appears to have been done already. It’s actually problematic because what designers should usually be presented with is a visual problem to solve, not an outline of a solution.
Low-fidelity scribblings or the nastiest-looking wireframes bring out the most innovative and creative solutions and allow individual contributors to develop their problem-solving muscles, much in the same way that polished mockups at the wrong stage of the project are more likely to stifle and confuse the design process overall.