Chris Fahey from Behavior Design has an excellent post up discussing the tension that exists on the line between user interface and software design. This is something we deal with internally – that tricky balance to strike with a design-driven approach to building software. What is design exactly? Is it the user interface? Is it the requirements? Does it cover the interactions? Should it inform the architecture / API / construction of the software itself?
The answer to all of the above is “yes”.
If that’s the case, then when mentioned in the context of building software, isn’t design just another word then for all of the inputs to be considered in the process of building software?
I personally struggle the most with the word “design” as a replacement for “interface design”. The qualifier there tells the whole story.
Last, and perhaps controversially, I believe that for software applications (I’m differentiating here from content websites) you cannot separate out the process of designing the user interface any more than you could separate out the process of writing the requirements. They are both part and parcel of the software you are attempting to build and can only be removed from the process to the detriment of the end product.
Richard Ziade said:
I’d even go one step further: in your world you put design INSIDE the software building process. Why? You’ve already encumbered the designer.
How about let the designers do their thing and then think about how to make it a reality. Yes, some things may fall off. How else can you innovate and break new ground? I bet the iPhone is a design-driven product – “make it work like this” – and the technologists scrambled to figure it out.
Christopher Fahey said:
Richard, when I say things like what you just said I get engineers jumping down my throat. But I agree 100%. I like to go out on a limb and say that designers should treat technology as a “black box” where anything is possible.
Of course, it’s also important for designers to know what’s possible. And even to know what’s easy. Lately, for example, in designing for simple, low-cost web site implementations where we know that we will *have* to use an out-of-the-box CMS/blog system (like Wordpress, Drupal, etc), it’s helpful for the designer to know about all the cool pre-packaged features and plug-ins that can be used to build the site easily.
For example, a good UX designer can probably design an awesome customized unique branded photo gallery UI for every new client and project that needs one, designing systems that are absolutely ideal for the particular brand and audience they are targeting. But it’s usually very likely that if the UX designer simply began with an existing “photo gallery” plug-in, and adapted it to their design scheme, that they’d save a shitload of money for everyone.
For common design patterns, then, I guess going with technologies that deliver the pattern might be good. But the more complex and unique the need is, the more likely it is that the user experience should drive the process.
Richard Ziade said:
Very well put Chris. You’re raising a great point here and you’re shedding light on where my head was when I posted my comment.
In short, I was thinking about product. In product, there is this illusion that there are no constraints (or less constraints). Your goal is to blow people’s minds – somehow. When you’re dealing with a client effort where the constraints are everywhere, you’re absolutely right: find the path of least resistance that leads to great things.
I suppose this place – unencumbered creative license to let the design process roam unfettered – is a very rare thing. I thought we’d have it with product, but alas constraints are there as well: costs, timeframes, competition.
I suppose, whether I like it or not, design lives inside of reality. It’s a matter of how much you can get away with; how much of this ideal vision makes it into reality.
Jess said:
Great discussion here. As a designer and someone who pushes the value of a design driven approach to building software and applications I’m glad we’re having this discussion. First off, I agree with Tim’s first point that you cannot (or rather should not) separate out the design process from other components like the development, programming or requirements. But this requires having the right person (or people) on board who can think from this perspective and in the end execute with all these variables in mind. I used to work in a more traditional advertising agency setting. One of the things that drove me crazy was the lack of value placed on technology, which made me realize I needed to switch gears because I valued technology and doing something “the right way” more than I valued traditional Web design. As a designer in this situation, it was common to design the hell out of something and spend a lot of time doing it – then throw it over a fence to our development team and never see it again. This is very bad. My situation is somewhat reversed now in mostly a good way, but it’s still a struggle to achieve that perfect balance of technology and design. However, it is extremely critical to our success. Good design = success.
Design is a loaded word. But, let me speak broadly for a second. Good design sells. Good design makes people happy. Development and design are equally as important, but they only work together if they are integrated. Development and architecture – all of the things that go on behind the scenes are critical, of course. People expect your software to work and work well. But, that’s only half of the story. The execution of the product or application is what drives it home, it’s what’s sells it. If I’m buying a house, I don’t walk in and say, “wow – the plumbing is amazing.” I expect the toilet to flush and the water to run. What I do notice is all of the details and craftsmanship and work that went into the remodeling. I notice the trim, the shiny doorknobs and the granite counter tops.
Successfully building a product or a piece of software is really not that different. The plans and the design are laid out before you build. Every component is well informed of one another. No fences.
To talk specifically about design and the software building process, design touches every piece of the process. It informs how people use what you build and what we’re ultimately selling is an experience. This is why a design driven approach to building software works and is necessary. There are tons of labels for designers these days, but at the end of the day we are building and delivering on an experience and design is what helps us achieve this.