Cross Device Mockups

Before a design concept is developed enough in your mind to warrant hacking together a prototype, what is the easiest way you’ve found to communicate a seamless, unified, familiar app experience across a variety of different devices?

I always start with sketches – just pen and paper. Sketching is a great medium for exploring a bunch of ideas quickly. Sketches however are not always ideal when trying to communicate concepts to others (especially within a distributed environment like at Automattic).

I’m a big fan of Balsamiq. Of all the available options it’s become my go to solution when trying to communicate in that “middle ground” between sketching and prototyping.

If you’ve not tried Balasamiq, I’d encourage you to take it for a spin. One tip that is sort of hidden in Balsamiq is the existence of a secondary skin:

By default, Balsamiq uses the slightly more sketchy/scrappy Balsamiq skin. Alternatively, you can select the straighter/cleaner wireframe skin for mockups. I much prefer the wireframe skin.

As for mocking up designs across devices, here’s a hacked together balsamiq starting point that I’ve begun using to communicate designs:

Balsamiq source file

The idea is that each device in a single row shows the same state. Multiple rows/states can be shown on top of each other to communicate interactivity, or a certain flow.

Great UI’s can’t be rushed

Why?  Because even simple UI’s are complex.  There’s:

  • The need to understand who’s using your product
  • The need to understand what users are trying to do.
  • The need to understand what scenarios the UI will handle
  • The concept brainstorming stage
  • the concept fleshing out stage
  • interactive prototyping
  • Feedback throughout the design process
  • The front-end code
  • The back-end code
  • The speed of the app
  • The layout
  • Responsiveness
  • The copy
  • Typography
  • Colors
  • The page hierarchy
  • The interactions
  • White space
  • Motion
  • Personality to convey
  • A story to tell
  • Feedback states
  • Error states
  • Accessibility
  • Small delightful details
  • Internationalization
  • Retina considerations
  • Considerations for decisions vs. options
  • Browser testing
  • Device testing
  • The brand to consider
  • What did I miss?

When designs are rushed to ship, for whatever reason, chances are some of these items will fall through the cracks.  Bottom line: great UI designs take time to craft. Great UI’s can’t be rushed.

Early on, even great user interfaces suck

And that’s okay…

In fact, that’s the way it should be.

Consistently great UI designs must be crafted through a process.  This process will vary from designer to designer, and will likely change over time.  Here’s the process I lean towards these days:

  1. Gather data (who is this for, what are they trying to do, what scenarios should be considered)
  2. Based on the data, I sketch out lot’s of rough low fidelity concepts
  3. I’ll spend some time stewing on these concepts
  4. I’ll then select one concept (the one that best fits all of the criteria outlined in step 1), and flesh it out in more detail (usually still sketching with pen and paper at this stage)
  5. Get feedback
  6. Build out a rough interactive prototype (usually coded by hand, but I’ve been playing with Macaw and I’m liking it for rough prototypes)
  7. Get feedback
  8. Code it up right and add polish
  9. Get feedback, make tweaks – rinse and repeat this step until everything is just right

Myth #1: as you get better at design, you can skip some steps

Great UI designers do not skip steps just to save time.

Myth #2: the sooner you can get to a hi-fidelity design, the better

Great UI designers do not jump to high fidelity designs sooner than is necessary.  In fact, they tend to delay it as long as possible.  Great UI designers recognize the benefits of lo-fi designs, and leverage those benefits extensively.

Up until around step eight (more than half way through the process) it’s perfectly fine for your designs to still look unfinished.  The longer you can stick with lo-fidelity the better.  There are a couple of reasons:

  • Lo-fi concepts take less time to create
  • Since they take less time, you can create more of them, giving you more options to choose from
  • It’s easier to scrap a design that is lo-fi and start over
  • It’s easier to iterate on lo-fi designs
  • It’s easier to solicit candid feedback when people don’t think you’ve spent as much time on the concept

Early on, all UI’s suck, and it turns out, that that’s the way it should be.  If you outright skip steps in the design process, or if you hop straight to hi-fi mockups, your designs will tend to suffer as a result.  Great UI designs follow a process, they take time to craft, and early on, even great user interfaces are going to suck.

Note: inspiration for the title of this post came from Ed Catmull who said “Early on, all movies suck”, speaking candidly about the state of early movie concepts at Pixar.

Startups, what if you never hired dedicated support people?

I’m curious, are there any web companies – with 10 or more employees – that do not have at least one dedicated support person?

Hiring a dedicated support team is one of those things that every company seems to do without thinking about it, as if it were a requirement. But what if you didn’t? What if the founders, designers, and developers in your company continued to support your users indefinitely?

It would likely seem unnatural at first. The founders would have to lead by example. Else, I’m positive it would not work.

But I’m curious, with direct daily feedback from actual users:

  • would the designers design better products?
  • would the founders stay more in tune with users, thus prioritizing feature development more effectively?
  • would developers be more motivated to find creative ways for users to resolve their own problems?
  • would designers & developers instinctively fix more bugs?
  • would the overall product and user experience be better as a result?
  • would it be sustainable & scalable?

NOTE: I’m not trying to diss anyone in dedicated customer support roles. To the contrary, many of you are some of the hardest working, untiringly empathetic, and all around coolest people I’ve had the pleasure of working with (Both at Automattic, and Campaign Monitor).

My big hypothesis here is that by forcing founders, designers and developers to share the support load, and not pawn it all off on someone else, chances are:

  • founders and designers would have a much clearer vision of what they should be building throughout the life of the business.
  • your product would be better, because designers and devs would experience the pain users go through, and fix more things along the way.
  • your customers would get answers to their questions faster, because your developers – seeking to automate repetitive tasks – would invest more time in solutions for users to solve their own problems. Thus reducing the support load by reducing the number of support tickets that get created in the first place.

I’m mostly just curious if this has ever been tried.