Tag Archives: design

What Do You Do?

From time to time, we’re all asked that standard question: “What do you do?” And as I start to explain what Square Lines does, it often gets summarized thusly – “Oh, you do tech design and development and stuff.”

Well, yes and no.

Yes, we do those things. In fact, we bill ourselves as “Design & Development,” specifically so that people get a quick sense about what part of the world we occupy. But that’s not really the best description of the scope of what we do.

We are, in the truest sense, solution providers. Over the last decade or two, that phrase has become so pervasive as to be meaningless in the tech world (which is why we don’t really plaster it all over our website). But for us, it really is the case.

So what’s the difference? Well, if all you want is a quickie web design, you can get that for free. Just find one of the tons of templates out there and call it good. Of course, your site will be from a cookie cutter, may not work the way you want, and certainly won’t represent your brand as well as it should, but hey — it’s free. You get what you pay for.

What we do starts with listening and thinking – two skills that the cookie-cutter chop shops don’t have. What is the problem that you’re trying to solve? Who are the audiences? What do you want them to do and to feel? How will this work be changing over time?

By getting a sense of the big picture, we can look at a whole array of options — some might even call them solutions! — whether it’s web design, app building, or something entirely different. The goal is to meet the client’s needs and solve the problem, not just to churn out another bland product that looks and works vaguely like everything else out there.

So what do we do? Design and development, yes. But really? We provide solutions.

Working With Style Guides

We work with clients big and small, so we run the gamut when it comes to design constraints. Sometimes, the client wants to start from scratch and gives us just a few parameters, while other times, we’re just making some minor changes to an already-established brand.

Somewhere in the middle is where we often find ourselves dealing with a style guide. This is a document from the client that outlines (in varying levels of detail) how their brand is represented across all media. Often, it has things like when and where to use the corporate logo(s), official colors, fonts, and that sort of thing.

We are used to working within these bounds, so that’s not a problem. But sometimes, the style guide can go just a little too far.

For instance, we worked with a client at one point whose guide specified the minimum size of the logo for display on the web at around 500 x 300 pixels, and that it had to remain on screen at all times. Think about this in a mobile perspective — that would take up most of a phone screen, and if it has to be onscreen always, then the content is doled out in 5-word increments!

It was clear in that example that the company hadn’t thought very clearly about the different devices and media that might be in play. Conversely, the reverse can happen as well — where the style guide is so vague that you’re not sure if you’re following the rules until you discover later that you’ve broken them.

Sometimes, we find ourselves in the position of creating these guides for clients, and while that can be tricky, it’s a useful reminder of the challenges involved.

What we’ve found is that even when a style guide is clear, it’s no substitute for good and open communication with the client. Sometimes what’s written isn’t what’s in practice, and it’s always good to get the straight skinny.

Patterns Everywhere

As humans, we see patterns all over the place — how do we read? We identify patterns of letters. How do we navigate around our world? We see visual patterns and respond to them in our habitual ways. In fact, there’s a common phenomenon called apophenia, where we see patterns in randomness all the time (even when there really isn’t a pattern there).

So why not put this pattern-seeking behavior to good use? When doing design or development, there are also an array of patterns out there. In terms of development, this may be a broad framework pattern, like Model-View-Controller, that specifies how one can build the basic structure of an application — or something smaller, like how a variable can be structured.

But patterns exist in design as well — and I don’t mean the textured backgrounds or patterns that dress up a layout. Rather, as in development, these can be broad structures (like a layout pattern, for instance, a grid-based layout), a navigation feature (like double-tab navigation), or a functional aspect, like a captcha.

So why are these patterns important? Well, the more comfortable you are with the patterns, the easier (and faster) it is to bake them into projects. Even better, as you get more comfortable, you begin to extend the patterns and do new variations that help evolve design (and/or development) in new and interesting ways.

And therein lies the potential problem with pattern-based design or development — it can make it too easy to stay within the same set of parameters, and things stagnate. Nobody wants to see that you build the same old thing for every different client or need. If you hew too closely to the patterns or use them by rote, you are losing a lot of creativity.

But knowing the patterns and how they work is one of the best starting points there is — after all, if you’re going to leap off into the great design/development unknown, why not start atop a foundation of years of others’ expertise. You’ll get a lot further that way.

Know Thy Tools

A while ago, I was reading an issue of Dr. Dobb’s when I came across the assertion that programmers waste a significant proportion of time because they don’t know their tools well enough. And I think that’s probably right. But it doesn’t go far enough.

Earlier on the blog, there’s a post about the importance of having a broad and deep toolset. But both the Dr. Dobb’s comment and the earlier post focus on the development side of things. I think the assertion is just as true on the design side as well, although the perils may be a little different.

When developing, if you’re working in an IDE and you don’t know the intricacies of how it works, you’re definitely going to be working more slowly than you need be. When designing, if you’re working in a design tool and you don’t know the ins and outs, you’re restricting the scope of your creative output. That’s perhaps an even more catastrophic outcome!

Think about Photoshop, for instance. That tool is both broad and deep, and it gets moreso every cycle. Now that it will largely be available as a subscription only, the changes will just keep on comin’. But if you don’t know how the filters work, you may no longer have those design choices in your visual vocabulary to work with.

In contrast, if you don’t know how to do multi-file grep-based search and replace in BBEdit — something that is roughly comparable in terms of complexity and importance, I think — you have a bunch more work to do to get to the outcome, but you can still get there.

Regardless of the specific poor outcome, the lesson remains the same: know your tools. Whether you’re an information worker who lives in Word, Excel, and PowerPoint; a coder who lives in emacs, BBEdit, or Notepad++; or a designer who lives in the Adobe or Corel worlds, you’re probably missing out.

Besides, how can you complain about the limitations of your toolset if you don’t really know what they are? Think of the fun you’re denying yourself!