I'm not a designer. I wish I was, but my background is in computer science and writing; the first project I ever released was a hypertext magazine with a logo drawn in MS Paint.
Design isn't, of course, just about the aesthetics of a product; it's about how the product serves its intended purpose, and how the user feels while they're using it. It's about building with empathy.
I think Apple was the first to really make that last clause part of their ethos; they've been building hardware products that focus on their emotional impact for decades. It was easy to conflate this with their premium price sticker, so I think a lot of engineers missed the point until the iPod (or perhaps even the iPhone) came out, but now it's hard to avoid.
Engineers, myself included sometimes, often make the mistake of thinking about a product in terms of its requirements, where requirements are a check-box list of desired features. The result is something that technically does what it should, but is counter-intuitive, or emotionally unsatisfying. That might sound somewhat waffly, but if you're using the same piece of software day in, day out, those moments of friction add up. Ideally, if you're using something often, it should be a pleasant experience that allows you to quickly obtain the desired result.
Designers are trained to do this. Unfortunately, in small projects or lean startup situations, you might not have the luxury of a trained designer. You should hire one as soon as you can, of course - it's a skilled, professional job, and in past startups I've worked on the designer has sometimes been the most highly-paid member of the team (a decision I stand behind). Nonetheless, when I don't have one, like I don't on idno, I have some tricks that I try and employ to minimize the fallout.
Trap to avoid: "I'm not a designer, so I won't try and design."
Lazy thinking at its finest. If you're a software engineer in a startup, you're not writing code, you're building a product. The code is not the product. If you've written beautifully elegant code but the product is awful to use, your work has been for nothing. (Unless your primary goal was to write some neat code, which is sometimes worthwhile too - but that's not a product.)
A second version of this trap, by the way, is to trick yourself into believing that design doesn't matter, or that it's superficial. It does, and it's not. Design goes to the heart of why you're building a product.
The way I avoid this trap is by trying not to code first.
Telling stories
I find it helpful to tell the story of what my user does on their journey through my product.
I'm not a hugely visual person. Diagrams are often hard for me, and I find I absorb text more easily. (I do sometimes make Sharpie sketches to test ideas.) Other people are different, and prefer to draw flowcharts, storyboards, comic books. Obviously, do whatever works for you.
eg, here on idno:
- I want to update my status to let my friends know I'm going to be at the Albatross tonight, and invite them to come.
- I unlock my phone and push my homescreen icon for werd.io.
- The phone's web browser starts. The system remembers me, so I'm already logged in, and presents me with some touch-friendly icons for different kinds of content depending on which plugins I have installed. On this site, I have Status Updates installed (along with Posts and Photos).
- I push the Status Updates icon.
- The content pane swaps to a text field, which invites me to type my status update of any length.
- I type my status update, and push a big "post" button.
- My status update is posted to my site at werd.io, as well as to third-party services that I've linked my account to, like Twitter and Facebook.
- I put my phone away, knowing that my friends will reply to me on the services that are convenient to them.
Now, I can look at that story and decide if any of it is inefficient, or feels wrong. Is it burdensome to expect the user to have a homescreen icon for a web app, for example? (I think they probably won't.) What happens if I want to send the message more privately, to a few select people, but who still want to reply to me on the sites of their choice? (Watch this space.) I bet you might think of other criticisms, so it's worth me sharing my user story around a bit, to gather some feedback.
And then, once I've got some idea of what I'm going to do, I need to figure out what it looks like.
Making it appealing
It's much easier to make an application look nice than it ever has been in the past - which is just as well, because we've got more form factors and platforms to consider than we ever have before.
The answer, of course, is to keep it simple. And aligned.
Simple grid systems are an incredibly useful concept in design. There's been lots written about this, also for non-designers, so the cheater's version is this: make sure your screen elements align with each other.
In idno's default theme, I cheated by using Bootstrap, the responsive front-end framework that originally came out of Twitter. (We're actually in the process of going back and using it for latakoo's new interface, too.) Bootstrap provides a twelve-column grid that shrinks on smaller screens, so that something that works on a 30" monitor can also work on a 4" phone. So that's the carrot: the fact that you don't have to develop a bunch of different interfaces. But it's a bribe. The biggest thing that Bootstrap gives you is a much better-balanced interface overall. It's a great way to encourage better-designed pages.
You don't have to use Bootstrap, of course, but I think its principles are sound. (There are also a bunch of alternatives.)
So that's the layout sorted. How can you cheat with things like icons?
Typography, done well, is iconography, and it just so happens that there are a bunch of free fonts out there to help you out. For type itself, it's worth thinking about what looks good across browsers, is easy to read, and also is well-aligned internally to itself. Google's Apache-licensed Roboto font is my favorite right now; it was designed for Android, but looks really fantastic across browsers in a variety of weights.
Using fonts for icons means you don't need to worry about retina displays or creating versions at different pixel sizes. Bootstrap ships with Glyphicons, which is paid-for for other purposes. I've happily paid the money, but because idno is an open source redistributable package, I needed something with a compatible open source license that I could redistribute with it. Font Awesome fits the bill perfectly; I've been using it across everything I do, and I couldn't be happier.
So, great. I've got satisfying user stories; a simple, grid-aligned layout; beautiful icons that work well on any device. I'm not going to talk much about color, except to say that I find Adobe Kuler to be pretty useful.
How do we make it work?
Making interactions not suck
Going into formal interaction design would take a textbook, and someone else would have to write it. I'm not an expert, remember; I'm a cheat. I just try and stick to some simple rules.
Talk to the user. Always give them strong cues about what to do next, and/or about what they just did. (And while we're here, although it seems obvious: never do this with Javascript alert() popups. They're intrusive, and the design isn't under your control.)
Think about how your eye moves. What pops out at you when you first see a page? Where does your eye go once you've interacted with it a bit? How do other peoples' answers to these questions differ when you try it with them?
Minimize clicks. If you can edit a field in-place rather than having to click through to an edit screen, for example, that's great - but only if you've made it obvious to the user that this is something you can do.
Treat the browser as an interface too. If you're breaking the back and forward buttons, you're doing it wrong. If you're making a one-page-app immersive Javascript-heavy experience, use the Javascript History API and make sure you can get and set the state of your application through URLs saved there. Twitter does this pretty well, for example. And if you can't do this: make your app out of separate pages. There's no shame in reloading the page; really, there isn't.
Don't repost forms when the user hits the Back button, though. You can avoid this by sending a Location: HTTP header once you've performed your form action work.
Understand that the user has a bunch of different devices. It's okay to use cookies to save user session information. It's totally not okay to save any other user or content flags in anything other than a back-end database. The user's state needs to be consistent across all the devices they use.
And finally, an oldie but a goodie: Don't target a single browser. In the old days, we'd see applications built for Internet Explorer only; these days I'm seeing more and more Chrome-only apps. If you're doing this, stop. Making applications work cross-browser is less intensive than ever before - and nobody's going to blame you if you don't include pre-HTML5 browsers in that mix. Enterprise developers may need to target IE7-8; everyone else can relax a little. And IE6 is just a distant memory at this point.
So this is how I cheat.
The above isn't design, really, but I find it helpful to have simple rules to follow that make my applications a little easier to use. Designers are worth their weight in gold, but I hope some of these ideas help you with your projects where hiring one is out of bounds.
I'd also love to hear your ideas. Write your own post, link back to this one, and I'll see the ping. Thanks!
Share this post