Making visual design work harder

I want design output to work as input for dev handover, stakeholder walkthroughs and marketing materials. I definitely don’t want to have to request dozens of changes and versions before and after any of these meetings. That means the copy and content has to make sense to avoid creating noise.

Visual design is sometimes treated as an independent step in the digital product design process. This can be inefficient as it can mean more correction is needed. Content, information and interaction design are heavily impacted by visual design and so need to be harmonious. The UX is affected by all these aspects. If different people carry out different roles, communication needs to be fluid.

To get the most out of investment in visual design, here are 4 actions I omit at my peril:

  • Create notes for 1 or 2 scenarios end-to-end that tell the story of the screens in question. They should capture the players, triggers and expected results. This storyline keeps the visual design relevant.
  • Provide real-istic data for your visual designers to work with. This is essential to avoid over-simplified mockups that look great but break once coded. Real data is messy. Providing real examples requires a little input early on and avoids additional iterations once live. I say real-istic because we want to protect privacy but design for real-life people and cases.
  • Avoid dummy text in paragraphs. It prevents you from using the same mockups with stakeholders, experts, clients or as marketing materials because it’s impossible to look past dummy text which makes buy-in hard. Dummy text is only ever acceptable at a very early design phase, if at all.
  • Give clear constructive feedback, and steer, in closed door design critiques. Capture the comments and see if there are principles or guidelines your designer needed to do a great job that may have been overlooked in the brief. This may be information you have internalised, data or qualitative insights from users, business objectives and desired outcomes or any other factor that means the design is on course or not to meet the desired goals.

From the other side of the Jira board

20 years in UX, 6 months as product owner.

One product, one team, right?
Sure.
That’s the theory.

UX and dev are not always marching to the beat of the same drum whether down to the team set up, culture or methodology. I have not yet come across the perfect solution to marrying sprints with UX, no matter how lean the UX or outcome focused the dev approach.

I know the pain of coming up with a ‘great’ UX solution: end-to-end, easy to use, covers all the pain points, nails all the details, harmoniously blends with existing flows…

And then the shock of seeing only pieces of it implemented. The famous first phase. The frustration of dev “tickets” missing the whole picture.

Mr Potato Head without the potato body and no mouth.

So now I’m in the other camp. No longer just the UX user-advocate role, but the one who has to say which is the most valuable “piece” because the whole thing would take just way too long and so by the time it was done, nobody would care.

Time, money and value. Maximum value, minimum everything else. Using the leanest approaches I can to try and cover the most ground.

Fundamentally, the question has changed. Before, if it was what would make the best outcome in the most frictionless way possible, now it’s, perhaps, what will make the most impact in the shortest time possible.

It has the feeling of downsizing, like in the movies. Moving from a mansion to a caravan. More austere, some tough decisions, generally not as romantic as it sounds. There’s potential for it to be somewhat liberating, and it is certainly a good exercise in focus. Cut out all the noise and see what is left, and hope it’s still understood and fun as Mr Potato head, and not just as sad and scary like a few body parts.