Tallan Blog

Tallan’s Experts Share Their Knowledge on Technology, Trends and Solutions to Business Challenges

On User Experience Design

There are many people who believe that product design is a less important part of the things we build. They almost believe that it can be left as an afterthought. I’m sure most people have heard the phrase, “Lipstick on a chicken,” or as I post this soon after the ’08 election season, the phrase, “Lipstick on a pig.” They believe that “beauty” of the product is far less important than the “workings” of the product, and so the engineering schedule and the project management behind it give the design process little play.

On the other side of the fence are those who argue that the beauty and design trumps the workings. I suppose they get this idea from the mainstream media and advertising companies who dress up products and package them such that no matter what the workings, even if flawed, design makes it imminently sellable. These people may even believe that “art” trumps all, though I think at this time, that number is probably declining, and the word art, the concept, is declining in use. Art has nothing to do with it. It is not a concept we need talk about in design.

“Design is about making something work right.”

Of course, I’m talking about all product design, whether that product is a vacuum cleaner, a child’s toy, a magazine, or a website, or more aptly, to use the examples from Tallan’s industry, web applications, and software. I hope I don’t have to convince you that software, whether public-facing or internally used, is still a product and is governed by all the same conditions by which physical products are governed and judged.

So, in the battle between product design, and product features, who wins? Who’s right? My answer: Both are only half right. It depends on what is being worked on at the time. If you’re creating the design, the workings of the product should be the trump card that governs how you design the product; and if you’re working on the underpinnings, the actual features, the engineering of the product, you’re working toward the design. They’re both equally important, so that to deny either one the appropriate time in the engineering process is to skew your product’s focus and to doom it to poor use and broken functionality. Not doing justice to the feature set will make your users bad-mouth your engineering work. And not doing justice to the design will make your users walk away from the product because it’s not very usable. The design is not the end-result. Design is the beginning of the user experience.

“A good user experience means continued use of the product.”

Why another blog on UX? Because it is clear that still not enough people understand the impact of user experience on the bottom line. We don’t do design work for the beauty of it. Sure, it’s a great by-product of the process, but aesthetics are only a by-product, not the actual thing. If you design something right, you almost – almost – assure that it will end up looking nice too. User experience doesn’t stop at design. Design is a process. It’s almost zen-like in that you go through the design process to create something well-designed and usable. But that’s only the first step – or, rather the zero-th step. The process of creating the design is the beginning of designing the user experience. In the mind of the client and the end-user, the design becomes the user experience (with proper engineering), and so it is the product.

This blog is about the user experience, from a 360-degree view. Design, users, technology, business needs, the whole thing. While I’m thrilled to be working with some of the brightest people I’ve ever had the pleasure of working with, members of Tallan’s UX team are not developers in the same way that our technical development colleagues are; we’re less technical and more “big think” during the design phase, and then we shift into micro-detail during implementation. Most of the developers at Tallan take care of back-end coding, and have technical expertise that I personally will never get my head around without abandoning my own professional goals. But in the world of application design, software design, and coding, UX translates to “Front End”, and a good UX requires the front end to be done right. A good UX team balances graphic design, copy, illustrations, software tools, and technical knowledge, with understanding of user expectations, standards interaction and feedback, and some psychology to create the front end for the software, processes, and applications being coded by developers.

“…the browser is the most hostile programming environment you can come across.” -Douglas Crockford

We deal mostly with software running in web browsers. Douglass Crockford, the “Javascript guy” at Yahoo!, has said that the browser is the most hostile programming environment you can come across. I subscribe to that, whole heartedly. Sometimes the things we have to do escape logical reasoning, because we don’t have the playbook for every browser’s behavior and logic. We rely on the Internet to find some things out, to report our own findings, and sometimes to experiment by trial and error, within the scope of the browser environment, but luckily we work in an industry where the community shares its knowledge without reservations. We have to contend with that hostile environment and solve the technical issues related to that environment to successfully implement the user experience.

So if you’re reading this, regardless of whether you come from the world of software, hardware, or some other technical field, or like myself who has spent his entire career until now in small publishing companies designing publications, we urge you to think about design, and process, and the appropriate way to join a feature-set to usability and user experience. And we hope in that thinking this through, you will discuss your thoughts with us here at FrontEndDoneRight.com.

Share this post:

No comments

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>