Design and engineering must work well together if we want design cemented in the overall software development process.  Many perceive design as being oriented towards a waterfall approach, costly, and a “nice to have, but not necessary”.  We must change these perceptions by repeatedly producing better results through close work with software engineers.  Agile processes, whether strictly or loosely followed are the most promising framework for design and engineering to come together and pave the way for future software products and superior user experiences.

And since there are often fewer design resources than engineering resources, it is easy to develop a design-engineering bottleneck. The best way I have found to avoid/remedy this is to develop design artifacts (standards, templates, and best practices) for common scenarios so that many situations requiring design input can be solved without designers. It’s not as simple as developing the artifacts and giving engineers a link to them; it is up to the designers to educate engineering when and why the artifacts should be used.

2) How can we better quantify the value of design and usability (ROI)?

There are several books on the subject and countless online resources, and yet most designers stumble when asked this question.  If we can’t speak the language of executives, i.e. “dollars”, then we will remain “less important”.  And we need more than examples of value delivered from a particular case study: we need standardized quantifiable metrics that pass the executive litmus test.  If we have these already, then we all need to learn how to track and measure them and how to start communicating our value with them.  In addition to asking “how can we measure the value we deliver?” we also need to ask “how can we deliver the most value?”

3) Where does design and usability belong within an organization?

In some software organizations user interface design resides in the engineering or development department.  In others it sits in marketing along with product management.  In some it is actually its own department in parallel to development and marketing.  While organizational structures do vary from company to company, design seems to be all over the place with even less of a standard structure.  Regardless of detailed top-level structure, I would strongly argue that design be parallel to engineering and product management, otherwise design becomes less strategic and mostly tactical, and that is very dangerous.

4) What’s next for software user interfaces?  (CLI comeback? Gestures?)

If you are a designer, you should always be on the lookout for new and better ways to improve user experiences.  I read online blogs, journals, the results of user interface studies, and attend conferences searching for the stepping stones that lead to the next creative and innovative solution.  I’m particularly interested in new software interaction paradigms – designs that leverage the power and uniqueness of our digital medium rather than rely solely on mental models of physical objects mapped to the digital world.  For example, is clicking a button the best solution for the physical and digital world?  Maybe…

If there are any other core issues you feel I have missed, please add a comment for the rest of the readers.

Related posts:

1. Challenges to world class software design
2. What do we mean by software design?
3. Is software design a luxury?

But designing software is tough. I’m not talking about the creative work – that’s our passion and we love it. I’m referring to the “tax” we pay for doing what we love.

So what makes up this tax? What challenges am I referring to?

1) Everyone thinks they are designers

Developers, product managers, sales, and even customers, can’t resist their own needs to create or invent by suggesting ways to change an interface or add capabilities – “let’s just add a drop-down to the top…”. Either in the form of “design on the spot” during a product meeting or customer visit, or a developer going ahead and “fixing the problem” without waiting for input from design, it happens often, and reflects perceptions and lack of understanding of the design role and expertise. It can also reflect poor adherence to process, or lack thereof, and a need for cross-department executive sponsorship and continued support. (I am not suggesting that no one can give input to the design process; many of our best designs are the result of collaborative efforts with product management and sales.)

2) Design is a nice to have

I’m always perplexed by this one, but many bottom-line executives still perceive good design as a nice to have. No, not at Apple or Intuit (I see more design-related job postings from Intuit than any other company – it makes me wonder if they just want to interview everyone they can, or if Intuit has a Wonka factory somewhere full of designers dressed like ump lumpas, all building accounting applications). Apple and others have helped to move this forward, but I still run into the skeptical eye from time to time. Another manifestation of this is when a new product or concept is attempted and the strategy is to “get something working, find some buyers, and then make it better.”

3) Who makes the final decision?

The Biltmore Estate is a remarkable architectural achievement, and is commonly considered the result of a single vision where the overall design was driven and conceived by one person. Frederick Brooks states that “conceptual integrity” is the single most important factor in the development of successful software applications. But often, with software design, there are many stakeholders, business and marketing agendas, and the need to create something as soon as possible. The nature of software design and development within high-tech companies doesn’t seem to lend itself to the purity or grandeur of a project like the Biltmore where the “genius” is given free reign to produce a work of art. It’s difficult to find the right balance between art and business in software design, and this is evident in the careful politicking among the design executive and various stakeholders to decide what gets built and what doesn’t.

4) The difficulty in justifying designs to critics

True, the best justification comes from users, and you can get that (to some degree) from usability testing — assuming you have the time and resources to conduct formative testing. But what about colors? What about visual treatments that are more subjective? What do you do when the product manager says “I hate that blue — why do we have to use that blue?” (I recently emailed a color wheel to a large group of employees at our company – that was a big mistake.) There are many cases where I wish I could just say “just do it that way, trust me!” My boss suggested that I respond with a standard “thank you for your input” for things such as this.

Well, those are some key ones, but I’m sure I’ve missed several. I invite anyone who reads this to submit their own design challenges. This is a work in progress and I intend to update it with the best ways to address these challenges.

Related posts:

1. Career Paths for Software Designers
2. Four questions every software user interface designer and usability professional should be thinking about
3. What do we mean by software design?

Adam Polansky from boxesandarrows describes a method for prioritizing product ideas called “Faceted Feature Analysis”. I particularly like the idea of giving independent voices to development, business, and user experience as part of the process. – Russ

http://www.boxesandarrows.com/view/faceted-feature

Related posts:

1. Successful designers must influence product direction and strategy
2. Prioritizing Design in Successful, Legacy Applications
3. Challenges to world class software design