engaging user experiences
for web apps

ksd. portfolio

Working with a Not-so-great Mockup


You’re staring at a mockup that graphics, or some other stakeholder, gave you. And you’re thinking to yourself… “This is not gonna work. No way. This will not achieve the overall objective. Plus, it feels like a big fat print piece. The web is such a different experience than print. This should go here. That should be there. This panel won’t sell anything. How on Earth do they expect me to code THAT?! Ugh, and the colors are in CMYK!”

Unfortunately, you can’t say anything because, as archaic as your workflow is, it’s your workflow. Someone who may, or may not (usually the latter), understand web provides direction that you must execute. And you’ve tried in the past, only to receive pure defensiveness as the response.

Wait, y’all are still using mockups? Created by folks who don’t understand web?

All kidding aside, I feel your pain. I’d also like to offer some insight and options on what to do next.

1. Is this a battle that you want to pick? Are the stakes high enough? Is the project big enough? Are your graphics people really that defensive? Are your stakeholders that weak? If so, then you may want to just execute this and lay low until something bigger and better comes along.

2. Execute the mockup anyway, under the assumption that parts will be redesigned, rearranged or toasted altogether once the data rolls in. This works best if your stakeholders keep a watchful eye on their analytics, and are open to change, which they should be. (Don’t forget to talk to them about this before you build the darn thing :)

3. Call a meeting with your primary stakeholder(s), and explain why you think your proposed changes are necessary. You may have to do some homework to explain your reasoning — pull up past analytics, review your audience personas, or research outside case studies — but it’ll be worth it. This works especially well if your stakeholders respect your abilities, are open to your input, and truly want what’s best for the project.

Notice I didn’t say call a meeting with graphics? It all begins with your primary stakeholder(s), so let her, or them, decide whether or not to pull anyone else in.

If all goes well, things should unfold naturally from there.

Sound like a plan? Let me know how it turns out for you.

Until next time,

1/2 Scale Mockups by Juhan Sonin. Used with permission under a Creative Commons 2.0 license.

Design Crush: Dangerdust


Dangerdust is an “anonymous artist duo with a fondess for chalk dust”.

All Calls and Meetings Must Start and End on Time


Setting boundaries was a big theme for me in 4Q14, and after a 30-day journaling exercise back in October, I was inspired to finally write a business policies document. The first item that showed up: all calls and meetings must start and end on time.

Ouch, right? But here’s there deal: I’m a calm, cool, strategic designer… that happens to attract a lot of hot messes. The stakeholders, themselves, are very organized and orderly, but for whatever reason, they inherited this thing of a digital presence that went haywire, and look to me to perform a serious overhaul. Miracle, really.

With that comes an unspoken expectation that I maintain a buttoned down relationship with time (you can’t hunker down unless you button down, right?), and I’m okay with that, ’cause… like… I do.

Plus, I hate it when meetings run over, don’t you?

Until next time,

Guardian of Time by Alice Popkorn. Used with permission under a Creative Commons 2.0 license.

« Older Entries ::

ksd. want to work together? great!

Please fill out and submit the form below.

We'll look everything over, and visit your url.

Then be in touch to schedule a 60 minute, one-to-one call.

Know that it’s our highest intention to do what’s best for you and your digital presence.
Smile, it’s gonna be okay :)