I've been busy working on visual design bits for work projects this summer. My method is simple:

1. Sketches and storyboards
2. Static mockups (HTML/CSS, some Javascript)
3. Live mockups (to test integration and interactions)

Uncovering what a feature means is fundamental to the method. It exposes the nouns and verbs of the problem, and hints at the useful metaphors. The freeform nature of sketching and developing storyboards based on this language helps me focus on figuring out what the things mean, as well as finding their shape and rhythm. I end up working on several different approaches before it's obvious which ones are workable for the client and product.

Moving to static and live mockups transforms these ideas into reality. I aim mockups to be as close to production quality as possible, as anything less distracts from thinking and the discussing the designs. These distractions are the worst sort too, derailing any shared thinking on how an interface should be.

The method is important. It's worth practicing, and I do on a weekly basis (I'm always designing something).

Recent examples

I haven't posted much ongoing design here, mostly as I haven't been that proud of it (or haven't been the primary designer on the projects). As my hone my craft, and as I work on more interesting projects, I will talk more about my work. This is a good thing.

This is part of an updated reporting project. I found that the bold graph elements and combined (and pivoted cell data) improved readability of the table. Realizing that different types of columns had vastly different visual needs (as they were different things) improved the clarity of the data overall.

The simplified application chrome is part of an ongoing improvement project. We're reducing the size of the chrome (or bling), so that the guts of the application are much more prominent. The previous design had about 35% of the page dedicated to this chrome, which is now about 10% of the overall vertical space. We've hit the basic brand colours and shapes, improving the clarity of the product name itself and removing unneeded navigation.

I've also simplified the sign in form. Nothing revolutionary, but we've reduced the size and amount of noise significantly.

Learning is doing

This summer's design projects reinforced a number of principles for me:

• Process is bullshit. Method and practice, however, are crucial to execution and skill.
• Freeform thinking before structure. Sketching beats regimented tools for creativity.
• Make it real as soon as you know what it is. CSS/HTML designs look better than sliced or faked graphics, and you can get to testing usefulness sooner.
• The little tools and techniques matter. Icon fonts are awesome sauce. LINT, minification, and LESS improve quality by reducing duplication and effort.
• Small design steps are easier to finish well. Increment methodically. Build testing into your core habits, into your product.
• Simpler writing tools result in better writing, and writing really matters. Simpler tools are better. Simpler editors, markup, and hosting.

Hammering at the methodology and practicing each of the individual skills shows results quickly. I'm able to prototype a new set of features in a few days now, assuming functioning creative mojo. Iterating design with shorter design stints makes for more polish. Wax on, wax off, and all that.

#Design

I've become passionate about design. It's a subtle craft that says something, things that can't normally be said with words. It suggests things. It implores us to think in a particular way. It encourages us to go here or there. It is enough of a metaphor to be easily recognized, but not so much that it becomes tacky, unless of course tacky is the thing you need. Design is the artful side of craftsmanship, the soul of a thing.

I was talking about design the other day with a friend. “How do I get into design,” he asks? He already has the passion for design, he sees design, but he lacks the processes for finding, honing, and pushing designs along into to production.

How do you get into design? You need to see it first. Feel it. Then you do it. Again, and again, and again. Floundering, failing, and fumbling your way through at first. Is there any other way to learn to ride? To swim? It's a craft that requires balance and grace, and some amount of time to learn to execute well. And that's okay.

How do you get into design indeed! Find your passion, as it fuels the process. Passion is simple too: focus your frustration, awe, and excitement for a thing into a narrow band of optimism and spunk. It can always be better, and it can always be solved. It's just a matter of seeing it, boiling it down, and then actually doing it.

Passion starts with comprehending that a thing isn't working well enough. Then you imagine what it could be, what else has been done—-what hasn't been done yet—-and let your mind iterate over the possibilities. You eat. You sleep. You shower. You read. And at some point you see it, as if it were magic.

You'll see many visions of what it should be (many of them good). Later you'll learn which visions are better, and which are worth chasing after. But find your passion first, then learn to listen to it, to ignore it when it's wrong, and to trust it when it's onto something.

An example

I love reading. Great inspiration can be found by streaming in the things other people write. Books are especially excellent, as the format turns out thoughtful, polished experiences. Buying and finding books, on the other hand, is something I often find frustrating. It's an investment of time and money that can result in a growing pile of carefully bound recycling. Books you feel compelled to keep (but likely will never read to completion).

Now there are bookstores and libraries that make finding books a better experience. You know the sort, comfortable chairs, brilliant selection, and a staff that know the product and who love to read. These shops are gems.

Enter Amazon.com. It's a store with incredible potential. A huge collection of titles. Reasonable shipping, easy book downloads, and a sturdy site to run it all. But it doesn't work well and it's not very inspiring.

My favourite book store isn't much to look at, but it's organization is incredible. The shelves were built by the owners in a way that showcases the right books, providing an archive for depth, all while being easy to navigate. The owners themselves are avid readers, having read most everything I've asked them about. They haven't just read most of their inventory, they usually know exactly where it is or when they'll get it in next. And if you want a recommendation, they remember what you've read so that their recommendations are only a few steps from clairvoyant.

Amazon isn't much to look at either. In fact it's downright noisy. Dozens of things mashed into every page, making it difficult to find what you want. While their selection of print books is excellent, many of the books are not available for download. The result is an experience that isn't fun or inspiring. In fact, I often avoid it until I'm absolutely out of reading material.

Amazon could be so much more. It should be the comfy bookstore you want to browse. It should be the eclectic owners, their pristine organization, and the recommendations that leave you wondering if someone knows just a bit too much about you. It should be effortless, not leaving you wondering if something will be available for your mobile device in your region. It should feel like the perfect bookstore, melting away to trade your money for a lifelong experience of losing one's self between the pages of whatever turns your crank.

But it isn't. Buying books online is mostly worse than queuing up at your local mega mart, innundated with impulse items, inexperienced staff, and bright, over-saturated displays and lighting. Limp, uninspired, grating a bit on your nerves. You shop there when you have to, but the result is uninspired.

The first part of design describes that feeling, the way a thing should be front to back. The real world things it needs to bring to you, to make you feel. And the real bits of functionality that it absolutely must have.

The second part of design is in describing and making it happen, but that is something best talked about after digesting the first part. So go on, digest.

#Design

I know a few generations of developers. I find they tend toward different ways of thinking about software design, based on the languages and decomposition tools that were available at the time they formed their thinking. Their tendencies shift over time too, but often their imaginations are limited by whichever mode of thought they're working in at the time.

By design I mean the approach to solving a problem with software, including software architecture and low level design (not product, visual, or UX design). These are another universe around how we think about solving people's problems with software, a topic for another set of posts.

I realized the other day that design thinking follows an evolutionary path. It progresses to solve larger problems in better ways, and is based on layering and combining the various tools and techniques available.

A maze of twisted pathways

1. Flowcharts and pseudo code
2. Data diagrams and relational algebra
3. Eventing and state diagrams
4. Object diagrams and trees
5. Layered architectures and approaches
6. Partitions and service maps

The thinking moves from direct low level constructs toward more abstract solutions, based on less obvious symmetries and fissures. A flowchart, for example, is a direct mapping of instructions. A set of services and domain partitions is far less direct, and often maps to important constrains like scaling, performance, and cost.

Well, duh

It's obvious that our thinking has changed as software becomes more complex. What's interesting is how we get stuck in particular ways of thinking, and how difficult it is to translate between the various design approaches. A procedural solution is a very different beast than one based on intersecting data, and is very different again from a set of disjoint services for the same concepts.

To talk about design intelligently, we need to lay the groundwork for how we plan to cast the approach. More than one design tool can be used, but it's important that everyone participating in the design understands how to think and discuss things cast using that particular approach.

#Design

When you describe a design to a group of people, each person imagines something different. Depending on your story and the individuals, understanding may vary wildly. And if it differs enough, the result is chaotic—unpredictable and often negative.

You need to fit how you show your ideas to different groups of people carefully, and notice when you your story isn't hitting. For your closest team members you can wave your hands and scrawl ideas on a chalkboard. For people you work less frequently, you need more detail: proper drawings and clean wireframes. For non-technical clients you need even more, polished, functional prototypes and pretty drawings.

When you fail to excite people with your ideas you do more harm than good. They imagine something more or less than what you're thinking, leaving them disappointed and confused. You give them a different taste than you intended, which you will have to work to overcome in the future. Instead, you need to spark their imagination skillfully, stirring lively, constructive discussion.

A working example

One of the products I'm working on is a refresh for an ancient financial system. We're working to make it scalable, easy to operate as a web service, and viable as a business for the client. Each of these problems is interesting and fun.

Early in our prototype work I made the mistake of leaking a technical proof to one of our non-technical team members (not the client, luckily). The prototype proved that we could reproduce the legacy calculations accurately, using cheap, common tools and schema design. Technically we were excited about the win, so we showed it around internally.

The problem with technical prototypes is that they lack pizzaz, often intentionally. This piece of the prototype matched the old system design to make it easy to test, but looked dated and out of place in a modern web app. The effect of showing this stage of the work to the wrong people bogged down our shared picture of the product. It killed our momentum and excitement, which took time and energy to recover. The loss was more psychological than literal, but was a cost nonetheless.

The next planned task, of course, was to find the visual styles for these screens, as now we knew that they were technically possible. And the design turned out better than expected, but the win was dulled by the lost momentum and our gains were smaller than they should have been.

More than words

The problem isn't just in the explanation or the path, it's in the combination of people, experience, and approach to the narrative. Each thing you show (and how you do it) matters. Each person's understanding and contribution matters, as they are part of the momentum. Focus what you deliver, think clearly about the presentation, and keep your audience in mind.

There's a bigger win in showing off the right work to the right people: it forces you to deliver better quality earlier. The risk and of miscommunication is real, and the wins—when you get them—are golden. Force yourself to show off better work, make it a personal goal. Challenge your team to show better work too. It pays off in a multiplicative way, and that's good for the things you build.

#Design