Software Interface Design

As part of a recent management summit at my company, we were asked to fill out an RMPT matrix for our departments (I head up Product Design).  An RMPT matrix consists of (R)esponsibilities, (M)etrics, (P)rocesses, and (T)ools.  I have been intending to develop better metrics for both measuring and guiding our design efforts, and this exercise served as a catalyst to get me started.  Bear in mind that metrics help you focus your efforts and measure your progress, but you are also held accountable to them.

For (R)esponsibilities I specified the following:
1) Improve our products & innovate
2) Provide the UI design for new features/functions/products
3) Approve any UI design work done outside of Product Design
4) Validate our UI designs and explore user needs through user testing

Given those responsibilities (and that’s important because your metrics are linked to them) I then came up with the following metrics and met with my team who helped to refine them:

For a given period (e.g. a business quarter):
1) Number of layouts delivered
2) Number of interactive prototypes created
3) Percentage of product design requests completed by commit date
4) Number of users tested
5) Number of product improvements made
6) Number of products insights documented

Discussion:

1) We struggled with what to call this and how to word it specifically.  We started with “Number of designs delivered”, moved to “Number of screens delivered” and settled on “Number of layouts delivered.”  We chose layouts because designs seemed a little too broad and didn’t really give any indication of what we would actually be delivering.
2) We prototype when feasible and want to both push this effort as well as measure it.  Again we struggled with the wording (i.e. “prototypes” vs. “designs”, etc.).  We wanted to make it clear that we are measuring the number of interactive, non-static prototypes.
3) We recently implemented a Product Design Request System where we track the growing volume of design requests and deliverables to development and product management.  We are holding ourselves accountable to deliver on these requests by our committed due date.
4) We test designs on users as much as possible and want to both measure this and push ourselves to do this as much as possible.
5) Here’s where it gets a little interesting.  This one is admittedly qualitative and may need further refinement.  With that said, it is easy for us to remain reactive and work day to day by responding to requests from product management and development without ever taking the initiative to improve our products by combining our research with our unique expertise in usability and design.  This metric is meant to drive us to be proactive and take initiative to improve our products and to track those improvements over time to further illustrate our value.  To make this metric more objective I plan to tie in efficiency measurements and satisfaction scores (SUS).
6) With our considerable user “face time” we are in a unique position to collect “insights” into product shortcomings, needs, and opportunities.  We often take copious notes when doing user studies only to leave the notes sleeping silently in our Moleskines.  We meet regularly with SME’s (subject matter experts), developers, users, and various other stakeholders.  This metric is intended to remind us to document, publish, and take action on the “insights” that we collect.

My reason for publishing these metrics is to get feedback and to learn what metrics other designers work with.  Let me know if you think an important metric is missing or if you disagree with these metrics and why.

Good user interface design has traditionally been a low priority in the world of network management applications (except for a few companies like my own that seem to get it).  But a recent interview with Cisco’s new CTO, Padmasree Warrior, may be a bellwether of changing priorities:

What’s Cisco’s most immediate technology need?

I don’t think it’s a Cisco need as much as an industry need. If you think about what’s happening with the industry, you can think of it as either a convergence or a collision. Convergence because we are truly merging content, communications, computing and commerce. It’s a collision because different industries come at it form different angles. Google and Amazon come form the application down into the infrastructure; infrastructure companies are going up. Wireless and wireline are converging as well. So it changes the landscape of who competes with whom in the future and who becomes your friend.

So what I think what Cisco needs more of in terms of technology and talent is moving from infrastructure to more providing the applications associated with the infrastructure. You have to think about how users interface with the technology. So user interface becomes a very important aspect that we have to think about. As the enterprise gets more consumerized, it has to be very simple, it has to be one click. It’s user interface, usability – how simple is it to set up. It’s that kind of focus that we need more of.

Original article: http://www.networkworld.com/news/2008/062508-cisco-cto-warrior.html?page=1

Padmasree, you give me hope!

I love cigars. I smoke about 1 per month as a treat. That may seem like nothing, but I really enjoy it. About 2/3 of the way through a good Rocky Patel, there is a moment of clarity. Greens become greener, blacks become richer and edges become sharper. A little Laphroaig doesn’t hurt either.

It is usually at this point that I come to some realization. Tonight that moment was defined by frustration regarding misconceptions of software design.

I evangelize design daily. I argue for the importance of good design, justifying the investment in time and resources to design and build smarter. But recently I was told a story about the iPhone that illustrates one of the sources of the cautiously skeptical expressions of many business executives that I meet with.

Hardware mistakes are expensive; software mistakes are (relatively) cheap!

According to one person, much more design and testing work went in to the hardware of the iPhone than the software, and the reason given was because it is much more expensive and unacceptable to ship defective hardware than it is to ship flaky, buggy software. (I cannot verify the accuracy of this claim and truly wish I had real data to support or deny this.)

At Dux2007 in Chicago, I attended a workshop where I asked the group why we don’t design software like we do hardware? Why don’t we spend more time in prototypes, mockups, etc. One of the attendees, a software designer… said “because it’s cheap to fix software problems - all you have to do is make a download available that resolves the bugs.”

That’s what so many executives are really thinking, aren’t they? Build it, test it, get it
out the door, and then ship fixes as necessary. Time to market, fix later.

And herein lies the mistake: fixing bugs is not equivalent to fixing design.

True, bugs in software can be fixed easier and cheaper than bugs in hardware. But we’re not talking about bugs–we’re talking about DESIGN. You can’t fix a design with a download! Design is the essence of the product, how the product interacts with users, the personality of the product, the metaphors, etc.

Attempting to fix design in an update results in confusion, retraining, potential loss of trust, etc. The changes are too significant. Therefore redesign is often delayed until the next major release of the product, resulting in additional costs, potential loss of customer loyalty and the opportunity to “lock them in”, etc.

So, yes, software bugs can be remedied easier than bugs in hardware. But design problems in software are no easier or cheaper to resolve than hardware design flaws, and therefore we (software designers, creators, builders) must adopt better processes, principles, and expertise towards designing better software products from the start.

Design is a broad term.

Some claim that everyone designs, and depending on exactly how you define design, that may be true. Not surprisingly though, many professional designers react uncomfortably to this. It helps me to distinguish between being creative and designing. Creativity is a free-form process that anyone can participate in. We are all creative in some way or another. But professional design is a discipline where experience, talent, techniques, tools, and skills are applied to synthesize and articulate fuzzy creative ideas into something usable.

There are many facets to that “something usable” though: the interior, the exterior, how it looks, how it performs its function, and so on. With regard to software there is database design, object-oriented design, web service design, interface design, navigation design, and visual design, just to name a few.

Why differentiate? Why distinguish between database design and visual design? It’s all design right? Because the talents, techniques, and tools required vary drastically among them. And we have people who refer to themselves as “designers” mixing with software engineers or programmers resulting in confusion about who is responsible for and designing what.

To help this issue, we can group the various design disciplines without over generalizing too much. “Front-end” and “back-end” are common terms used to separate the interface from underlying code – the code that makes everything work. It’s not bad I suppose and it has the advantage of already being used and understood (to some degree). But more appropriate terms would be “interactive design” and “functional design”.

Interactive design encompasses visual design, interaction design, user research, information architecture, information design (not database – the user representation and visualization), and usability. Interactive design is about the user experience, what the user sees and interacts with: form and behavior. Alternatively, functional design is about the underlying architecture and foundation to support and deliver the user experience.

Historically, we’ve done a good job on functional design. That’s what software development has been all about. I can’t count the times in the past I’ve heard “just slap a GUI on it and we’re ready to ship!” (You would never hear that in automotive design, would you?). As users’ expectations have increased thanks to experience with well designed software (they didn’t know what they were missing) and the natural evolution and maturing of software development, interactive designers are slowly being recognized as critical to world-class software development.

So, by software design we mean interactive design and functional design; equally important, but drastically different.

There are two career paths for software designers: the path to creative leadership and the path to executive leadership.

Which path is right for you? Let me outline some of the pros and cons of each:

As a “creative leader” you will drive design from the top and be expected to contribute directly yourself. You will have flexibility and you will be unencumbered by the management duties typical of high-ranking executives, freeing you to “create.” You will be expected to produce, to evangelize, and possibly to write or speak at conferences. However, while being seen as the “brains” behind design, you may also be somewhat dismissed by corporate executives as having very little “business” knowledge, and therefore very little input into corporate strategy and sometimes even product strategy.

As an “executive leader” you are expected to understand the business-side; market drivers, profit/loss, etc. and most importantly be skilled and effective in management — a task many up and comers are often shocked to find so difficult and taxing. The more people you manage, the less you contribute yourself. The executive leader enjoys a more standard position in the corporate power hierarchy and therefore will wield more strategic power and influence.

Creative and executive leaders hold varying titles depending on the company. Some examples include:

The choice of which path to follow can be difficult if you want to remain an individual contributor and focus on design, but also want to have strong political influence in product strategy and mix with the rest of the company’s executive team. There may be hybrid roles that combine these two to some degree, but I question their ultimate effectiveness.

So, ultimately the question you have to ask yourself is whether you want to create and lead through design, or build and design through leadership? Or, more simply, do you want to push yourself as a creative or push yourself as a business-leader?

Two noteworthy articles, and harbingers for the rise of the design executive were published this August:

Wanted: VPs of Design (Businessweek, Aug-07)

Enter the chief design officer!: hail to the chief! (ACM Interactions, Aug-07)

Motivated by these articles, I did a quick Google search on “vice president of user experience” and found this role at several well known companies including Google, Yahoo, eBay, Microsoft, and Oracle, as well as countless lesser-known and smaller companies. I didn’t bother searching other possible titles.

It’s apparent that companies are beginning to recognize the value and need for design leadership as an integral part of the executive team. More so than ever before users demand more from products, and if a company is looking to achieve competitive advantage, innovate, and be an industry leader, it must elevate design as part of its strategy.

Ben Erwin, one of the product managers I work with (and a good friend) at NetQoS writes:

Maybe I’m the only one who has this problem? It figures. It’s obvious that the design team for my product line struggles with showing value to our company. But can you really blame the company? After all, product designers are sissy artists only concerned with colors and whether or not the horizontal navigation properly aligns with the banner bar. That was sarcasm…so please stop crafting the hate mail message that just popped into your brain. As a product manager, I have the upmost respect for product design. They have treated my customers with some very sexy (technical term for us ignorant folks when describing good design), well-designed software that continues to receive “oh’s” and “ah’s” from the market.

But those “oh’s” and “ah’s” fade fast. They just don’t seem to stick in the mind of sales, marketing, and software engineering. This lack of “stickiness” is primarily because customers keep banging the drum for more tangible features – features they think they *want* but not necessarily features they *need* (but that’s a whole new topic for another post). Not a week goes by where a sales person walks in my office and politely demands some new widget report. If I can’t deliver the report, XYZ Co. won’t buy our product, therefore the company won’t meet its revenue target for the quarter, therefore we all lose our jobs, and therefore we’re all homeless. No one ever comes into my office making the homeless argument because XYZ Co. wants better workflow in the product or is halting the deal because of the lack of aesthetic appeal in the UI. Sure there are complaints about these items but it’s never the priority. The priority is what the customer thinks they want before purchasing the product. That’s their buying criteria and subconsciously all of the sissy design stuff can come later.

To make matters worse for our product design team and their fragile egos, our products are legacy and very successful. This success was built with little to no expertise in product design and this success continues today, although we have injected some product design expertise into product development. Therefore, it’s difficult to separate what’s really driving the success. Is it the new, streamlined, and sexy interface that product design contributed to the product? Or is it the new widget data collection module we implemented too? Maybe it’s both? Unfortunately, the both argument dies quickly with the reminder of the company’s success before implementing design expertise and garnering the “oh’s” and “ah’s” from customers.

All of this rambling really boils down to a simple question: What is design’s impact on the bottom line? And a few follow-up questions: How do you prove it? We all know it is part of the bottom line somewhere but can you tie product revenue to it? Without question the customer’s experience with your product improves with the addition of capable product designers who focus on the aesthetic appeal and usability of your product. But that experience is hard to put dollar signs against. When the company thinks back about how we closed the XYZ Co. account, it’s because software engineering cranked out the widget report in the nick of time without product design slowing them down. And thank goodness…otherwise we’d all be homeless. Praise software engineering and sales! By the way, why do we need product design again?

Again, maybe I’m the only sucker out there looking for answers. It could be an issue of my product’s market. Maybe product design becomes an obvious competitive differentiator as the competition begins to catch up. Hopefully I’m not alone; otherwise you just wasted a lot of valuable time reading this post – sucker! Again…that was sarcasm. However, I do see a lot of successful, legacy products on the market that are just plagued with poor design – they just ain’t sexy. Are these companies going to do anything about it?

Bottom line, I have a lot of respect for Microsoft and many of the outstanding people that work there (e.g. Bill Buxton).

But the new ribbon sucks.

I’ve been using it daily for months (Word, Powerpoint, Excel), and I consistently stumble on the same functions over and over again. I doubt I will ever master it. And I’m an interface designer!

When I want to center text both horizontally and vertically, I can always find the horizontal centering, but have to search for quite some time to find the vertical centering.

I consistently to this day scan all of the available options in the ribbon looking for things.

Just yesterday I couldn’t figure out how to change the paragraph style for some text without looking for 3 to 4 minutes.

When I want to print a page, I have to remind myself that it’s under the big Microsoft circle button. And there are so many more…

Bottom line, for me at least, nothing is automatic. Nothing is natural. Learnability is poor. It’s as if I’m looking at a bag of goodies and my eye has to scan through all of them to find the particular piece of candy I want.

If the problems were all a result of change, that would be one thing. But I’ve been using Office 2007 long enough to exclude change as a problem. If the changes were learnable I would have certainly learned them by now. I believe the problems stem from the following:

1) visual density/complexity

There is just too much to process on the screen. It’s a Swiss Army Knife with every tool exposed (well, not all of them). Not only is it too much, but the density, the proximity and variety, make it difficult to process quickly or to associate a function with a location. For example, it’s impossible to mentally associate upper-middle with paragraph styles because upper-middle is too broad and would include many other functions. My mind must process the ribbon each time rather than jump to a location.

2) anticipated functionality

The designers chose (through testing and usage data I’m sure) what functions to display prominently and where to display them. Whatever criteria they used leaves me with less than half of what I need visible on the screen at any given time to accomplish what I need to do. So I wind up searching for what I need — everytime. In my experience, anytime I’m asked to anticipate what users will want to do, I hesitate. True, very often you have to do it to some degree, but it’s challenging to get right. And the degree to which this was done with the ribbon, in my opinion, made it an impossible goal to achieve.

We (designers) all make mistakes. I recently designed a navigation system that I thought was innovative and efficient. In testing it failed miserably and I had to redesign it. What amazes me given what I know about the Office redesign, and the amount of work that went into it (along with the great minds that contributed), is that they must have gotten good test results and I can’t fathom how. I personally would have failed.

I would love to hear comments from others on their experiences. I haven’t heard many positive remarks personally (except regarding the context-sensitive right-click menus, which I think are excellent).

If consistency is your goal I doubt you will ever produce world-class designs.

The importance of consistency, and what consistency really means with regard to software design, has to be one of the most misunderstood and misapplied principles. I am constantly tortured with “well, Microsoft does it like this – why don’t we just copy that? It would be consistent with what users expect.”, and “let’s make this control look like this other one to be consistent”.

With this modus operandi, how can you ever expect to innovate?

Consistency is not about copying existing designs to shortcut necessary creative work (Note: I’m not talking about looking to other designs for inspiration). True, this can be used effectively, and may even be a good idea in some cases – there are many great designs out there worthy of mimicry! But it should not be a standard practice. Should every car look like a Honda? Should every tool in your garage have the same handle?

Should form follow function, or form follow form?

Maybe we should create a standards committee that specifies how all buttons should look and behave; then when someone develops a new software application, they can go to a website and download all the controls they need to build it. Over time all software products will look and behave exactly the same and our users will be much happier, right? I don’t think so.

And even more importantly, consistency does not mean sacrificing usability for the sake of code reuse! Again, I am a practical designer; I understand the various business and engineering considerations (time to market, cost, etc.). I’m not advocating reinventing the wheel. But I certainly don’t think that a bicycle, motorcycle, van, or high-performance sports car should all share the same wheel design either! Code reuse should be leveraged whenever possible but it has to be weighed against other considerations such as basic usability, existing metaphors and mental models, etc.

So, how can one apply consistency correctly? By thinking in terms of “conceptual integrity,” a slightly more abstract concept coined by Frederick Brooks in The Mythical Man-Month. CI means that the software system as a whole should reflect one vision and should fit together seamlessly and flow naturally. This will require consistency throughout the system, but it will not be the driving force. The usage of the system is the first consideration and consistency is applied to support this.

Form follows function and then goes through the consistency/best-practices and usability testing ovens to create the final product.