Billy Hollis and Mark Miller are two well-known .NET developers who care about UI design -- and they want you to care about it, too. At the DevConnections conference in March in Las Vegas, Billy and Mark took a break from their busy schedules to converse about the importance of UI design in today's application development. This article documents that conversation, with the discussion ranging across topics such as how radical changes in the business-technology ecosystem precipitate evolution in UI design, the use of gradients and other design concepts to make UIs more intuitive and natural-looking, how developers and designers can collaborate, and prioritizing features for optimum user experience. For more information on UI design, see "The Evolving Face of Web User Interface (UI) Design" and "Design Your User Experience for the Metro UI."
The Asteroid That Hit the .NET Ecosystem
Mark Miller: So as I'm thinking about UI and the principles of UI design...you know how Einstein was searching for that unified theory of everything?
Billy Hollis: Yeah.
Mark: I'm kind of trying to get that. I'm trying to get a sense of what the variables are. What the pieces are.
Billy: Well, I've struggled with that, too. Especially because if you don't have that unified theory, then explaining that to developers becomes enormously...
Mark: ...much harder. Right.
Billy: Because developers don't like this idea that things are done by intuition or feeling. They expect "verbalizable" reasons for everything.
Mark: Sure.
Billy: The best unified theme I've come up with has to do with evolution. I have a background in biology, and I've found it applies to the technology space a couple of ways.
One is that evolution and biology help explain most design principles. Take inattentional blindness, which has to do with the fact that people often don't notice what they're not looking at even though it's in their field of view. It has to do with the way the eye is wired. The fovea has high resolution; the rest of the eye does not. So you can explain the design principle in terms of raw physiology.
Two, the reason why developers should care about this so much, is the whole idea of evolutionary ecosystems isn't just for natural ecosystems. We talk about .NET as a business ecosystem. So if you have a business ecosystem, certain things are needed to survive in it. If that ecosystem changes in a radical way -- the asteroid comes down -- then the things you need to survive in the new ecosystem don't necessarily match exactly what you needed before. You need to adapt. And I think the ecosystem that we're seeing now, as a result of all the Apple products coming out, all the touch-based phones and the rising expectations...I think the ecosystem is just different.
Mark: Yeah. So where you're talking about evolution, you're talking about adapting to change. You use that in two ways. One, to justify design principles -- here are the reasons. The other is to talk about what is happening now -- how we're in a state where the applications have to adapt.
Billy: My biggest comparison tends to be on the IBM ecosystem in the 1980s. I remember when IBM pretty much just ruled the world. In 1985–1986, mainframes, minis, PCs -- it didn't matter, they ran it all. They dominated everything. Ten years later, they were pretty much irrelevant. Nobody really cared about IBM anymore. And mostly that was because there were these waves of change. The asteroids hit the industry. PCs, LANs, and the Internet made the way they looked at the world no longer relevant.
Mark: So it might be good to call it as it is. There is an asteroid that just hit the ecosystem; we first saw it coming in 2007, and it's in the form of touch: multi-touch displays.
Billy: Exactly. That's the biggest asteroid. I don't think it's the only one. I think cloud is another one, for example. But I would say that we've already had the big one, and that was touch.
Mark: It's good to call it like it is, because if you don't, you're pretending the asteroid hasn't hit.
Billy: Yeah.
Mark: And you're trying to hide under that rock of the old way of doing things.
Billy: And you think things will somehow go back. That after it settles down, it will go back to the way it was. But it won't. The asteroid has changed the ecosystem.
UI Design Concepts: Gradients and Proximity
Mark: One of the things I've heard you talk about before is gradients. Why do I want to look at a gradient? Why is that interesting to me?
Billy: That was one of the first things I tied in to biology, when I realized that the natural world doesn't really have monochrome in it. The visual system isn't tuned to monochrome. It regards monochrome as artificial. Even if you look at something that is monochrome in the real world, like a wall that is all painted one color, the lighting effects will give it a gradient look.
Mark: Yes.
Billy: And because of that, the eye assumes that something that has a gradient is natural, it's part of the real world. And something that is monochrome is artificial. It's on a computer screen. So effectively, a gradient fools the eye into accepting something as natural that is actually totally artificial. By putting a gradient into a user interface, you make it feel more relaxing and more natural.
I do a test where I have elements of my UI that I demonstrate and then hide, and ask, "What color was this element?" And they tell me a monochrome color. And I say, "Look again." And it was actually a gradient. But they don't see it until you point it out to them.
Mark: I like it when that happens. When something occurs that is not noticed until you come back and say, "Look at this again."
Billy: Right, and that's a really alien concept to developers. They think everything ought to be conscious. When we're dealing with human psychology, things just aren't like that. A lot of things happen at a subconscious level. It should be an intuitive experience for the users, and that's a big leap for a developer to make.
Mark: From a developer's standpoint, everything is intentional: the placement, the positioning. Everything.
Billy: Right.
Mark:
I wanted to show you something. It's a discovery I noticed in regard to gradients. It has to do with highlighting information. So the challenge is that I
want to highlight a piece of text on a document. What I discovered is if I put a hard edge near the piece I want to highlight, and a soft edge on the
outside, it's as if I'm essentially increasing the contrast, even though it's still black text on a white background (see Figure 1). It's an optical
illusion.
Figure 1: Using gradients and hard edges to highlight text within a document
Billy:
It is, but it corresponds to the way the visual system works. We use a variation on that as a highlight mechanism in items in a list. You have something
data-driven that is going to vary. Well, you can certainly change the entire background of an item -- and that's pretty obvious. A more gentle way to do it
that isn't so obtrusive, but still easy for people to pick up on when they look at it, is to have a gradient that starts very gently about three-fourths of
the way down, and then becomes a little bit darker as it approaches the bottom of the item. It never becomes completely opaque (see Figure 2). It always
shows through. But just a little bit of gradient on the bottom of the item tends to work better than shading the entire item with a solid color.
Figure 2: Using gradients to highlight items in a list
Mark: It's interesting. We're talking about subtle changes. Edward Tufte has a concept called smallest effective difference.
Billy: Right.
Mark:
I always imagine the ransom note -- which has all the letters in different fonts and colors all over the place (see Figure 3).
Figure 3: On the left: the opposite of smallest effective difference (SED); on the right: another way of phrasing SED
That ransom note is the
exact opposite of smallest effective difference. Part of the essence of good design includes understanding the mechanics of how the human body operates. I
love your connection with evolution, because we operate based on that. One of the concepts I talk about is proximity. The idea that if items are together,
we conclude [that] they are contextually related. And if items are apart, we assume they are not related. See the photo in Figure 4, which shows a
violation of the proximity guideline. It takes more than a moment to determine the correct path to Fort Worth.
Figure 4: A violation of the proximity guideline
And then you have problems if, for example, you have a chart on one side and a legend on the other; these items are contextually related, and yet they are placed far apart. The eyes are traveling back and forth. It's a violation of that proximity guideline.
Billy: That's right. The human visual system is tuned to think that things that are close together must be related. So if things have to be close together, and they are not necessarily related, then you have to fall back on some of the other principles. For example, if there's one group that has one color and another group that has another color, then that overrides the proximity guideline to give the eye a natural way to divide those into two groups.
Mark: Right. I would use that if I had a Save button right next to a "Delete Everything without Undo" button.
Billy: (laughing) Right.
Development vs. Design
Mark: Did you want to speak on the differences between development and design?
Billy: Well, everyone finds their own path on that. It varies a lot from team to team. I've never been a proponent of one-size-fits-all solutions for any aspect of development, but in particular, in design, people's methods of doing things seem to vary a lot. The common element to me is collaboration. I've never seen a really good design process work that was heavily sequential. Some people talk sometimes about a designer/developer workflow, and there seems to be an implicit idea that designers have a certain role, work on certain things by themselves, and then give the results to the developers who work on different things by themselves. I suppose that could work, but I can't imagine that being optimal. You get a group of three people together, you're going to get 10 times as many ideas and innovations as you would with one person working alone.
Mark: I totally agree with you. I think this idea of sequential workflow is going to yield poor results. I strongly favor the idea of people working in parallel, and independently of each other as well. Instead of having designers and developers in the same room, I could conceive of a world where developers can write an application and specify the important pieces of information on their UI as well as the less relevant pieces of UI, and then the designer comes in and applies skinning and maybe positioning, and then we're done.
Billy: Because the designer isn't going to have enough domain knowledge to make that distinction. The developer has that domain knowledge.
Mark:
That's what I'm thinking. So, for example, maybe you're designing some output that shows glucose levels. I might have a label titled Glucose (see
Figure 5).
Figure 5: Example of two different skins automatically adapting to the relevance of each piece of on-screen information
To the right I might place another label showing a number that tells me the actual glucose level. The number is more important than the label.
As a developer, I could specify that. There could be a property called Importance, and I would set its value to High for the number label and to
Medium for the Glucose label. The designer would build a skin (or the developer could apply an existing skin), and the skin would automatically
adjust emphasis to match the importance of each piece of information on screen.
Billy: Sometimes you have different roles. So sometimes I find it incumbent on the designer to produce more than one design or to be able to shift between two different modes. And that kind of division of responsibilities you're discussing works reasonably well if what you're trying to figure out is on a screen-by-screen or role-by-role basis.
But sometimes you need to step back to a bigger picture. Consider a corporate system with hundreds of screens and lots of roles, and parts that need to change and evolve over time. It needs a different level of design with more intense collaboration. You have to figure out the best way for users to navigate the system, how to keep up with where they've been and where they need to go next, what work items they need to work on next, and so forth. That's where I see collaboration being particularly important. Because no one person knows it all. It's too big.
Mark: I agree with you. The skin suggestion works well in a static moment in time. But once you start looking at transitions across time, even something as simple as shifting focus from field to field to field, someone has to come in and decide what's the order, what's the position, what's the sequencing. And I think that is, to some degree, a collaborative situation where designer and developer work together. Neither has historically been well-trained enough to be able to do that on their own. Few designers have had courses on concepts like focus. Developers know focus, but they're missing some design knowledge.
Billy: They don't know the principles of how the visual system works to determine what's an effective focus mechanism and what isn't. And actually that's an area that's evolving a lot because we have better technologies today.
Deceptive UI Practices
Mark: What's your opinion on dark patterns of UI -- exploiting UI techniques for evil? Such as buying an airplane ticket and later realizing you also unintentionally purchased insurance for the flight.
Billy: I condemn that in the very strongest terms, because it's deceptive. Certainly, if you understand how the human mind works, and you understand how to draw people's attention to things, that implies you also know how to hide things.
Mark: Yeah.
Billy: But that's not ethical to do. That enrages me. If that ever happens to me, I never, ever work with that company again.
Mark: Right. So, you know the first thought that comes to my mind when we talk about deceptive UI practices is the idea of displaying the EULA in all uppercase letters in a fixed-pitch font inside a tiny window next to a big fat "I Agree" button.
Billy: Right.
Mark: The first words that come into my mind after thinking about that is "Class Action Lawsuit"...
Billy: (laughing)
Mark: ...on behalf of everybody who's ever agreed to a EULA. Because it's hard to read, they're making it intentionally harder to view, they're making you scroll down, and that big fact "I Agree" button is taunting you. It's almost as if they know...
Billy: They know.
Mark: They're trying to get you to say yes.
Billy: But you can also spot the companies that are above that sort of thing because they'll typically have a summary at the top: "Let's tell you the three most important things about this EULA...the fine print is below, but here are the things you need to know about our EULA."
Mark: I love it when that happens. Brilliant!
Meeting the High-Res Challenge
Mark: I wanted to follow up a little bit on the nature of the meteor impact. I would describe it as two-fold: On the one hand, you have multi-touch and the phenomenal success of devices exploiting this technology. The second part is retina display [i.e., very high-resolution display technology, such as that in the latest versions of the iPad and iPhone]. Take a look at the iPad display that's just come out. From a developer standpoint, essentially we just took a number and made it bigger.
Billy: It's higher fidelity.
Mark: But the challenge now is that there are no monitors (as of recently) that could show you the entire contents of the iPad on screen at once. We're getting to a point where we're packing in a lot of pixels. There's a consumer trend for that.
Billy: Yeah.
Mark: And I think that you could also have a deer-in-headlights response to that. "Well, I'm just going to ignore that and pretend it's not here." But it feels to me like retina displays are about to just hit all over the place.
Billy: I think that could very possibly be the case. People want things to look natural, to feel natural. It's an unconscious desire, but people do respond to it. We discussed gradients earlier. Another aspect is a 3D-ish appearance. The higher-fidelity you get, the easier it is to completely fool the eye into thinking that it's seeing 3D.
Mark: I can imagine a UI where the buttons are 3D. Not a deeply extruded 3D, but a subtle 3D. And software that takes information from the camera about the lighting in the room and in real time projects subtle but realistic shadows and light-source reflections on the elements of the UI. I think such a UI would feel incredibly natural if done the right way and would certainly be very interesting to play with. Move it under the light and really see the texture of the surface of the UI.
Features and User Experience
Billy: One of the biggest UI design challenges is context switching: trying to find a way for the user to naturally switch contexts from this information to that information. And the more you map that onto the real world, the more options you have. Particularly in the health care industry, where you're working in many cases in a real space in the real world, the ability for the machine to respond differently when it's pointed at the patient versus the diagnostics machine next to the patient, it has enormous possibilities.
Mark: I love that. It's fun. When we're talking about great UI/UX, there are two camps. One camp says pack in a lot of features; the other says keep it simple. It's basically iPhone versus Android. Full disclosure: I'm responsible for an application that is packed with features.
Billy: Yes!
Mark: Packed. I've probably violated every reasonable count with regard to what is in there. However, I actually can see both perspectives as valuable.
Billy: It depends a lot on context. Let's take the typical user case: Let's say consumer and routine business application user. For them, it's not about features; it's about the overall experience. Particularly in the consumer space, we should have been persuaded by the iPod, which turned an industry upside down. I live in Nashville where the music industry is -- talk about an asteroid coming in and destroying an ecosystem -- the music industry has changed beyond recognition in only eight or nine years because of that device. And it was the first consumer device I'm aware of that was a huge success based on simplicity, elegance, and ease of use.
Mark: Right.
Billy: So that overall experience effect starts in the consumer space and goes upward into the business space for general workers who are just carrying things out. They have a job to do. To the extent that the application maps onto their job, maps onto the workflow they have, they need absolutely the minimum number of features to do those things. Extra stuff is just clutter for them. Now as you move up, you move into a class of applications where features start to matter more. And typically you're talking about people who start to specialize more and take higher degrees of training, like doctors and pilots in the real world. A cockpit is an extremely complex place to be, but you need everything in it. It's all there for a reason. It's just that you expect people will take a long time to be proficient.
Mark: Right.
Billy: So for me it's not a matter of one or the other. It's more a matter of a continuum. Now we're geeks, and we tend to have the capacity to assimilate features and technology more than the average person does. We shouldn't let that deceive us into always creating applications with a lot of features.
It's easy to end up with too many features. If you go into a group of people and say, "We thought of an interesting feature, what do you think," someone in that group will say, "Yes, I love it." But you can't depend upon your user population to guide you. You have to prioritize based on the feature's business value versus what's cool or what's only used once in a blue moon. And then when you're done, you present the entire package to the user. If you create a package that's arranged in a simple/elegant way that fits users' workflows, they will gravitate to that overall experience much more so than they would gravitate to something that has a long list of features.
Needed: More Design Expertise
Mark: Agreed. So one of the tools available to web designers to test UI is A/B testing. This can be used for both good and evil, but ultimately can tell you if one design is more effective than another. When I think of A/B testing and I expand that out to a more general example, I think of Facebook and MySpace.
Billy: Right. Yeah.
Mark: If you remember the MySpace pages, they would be radically different. You could look at two different MySpace pages and think you were on two different websites. Meanwhile, Facebook prioritized content. Important information was easy to see. These companies were neck and neck for a while, and then it all changed. To me, that's exciting. What we're seeing now is recognition that the asteroid has hit. As a result, more and more people are coming up out of the woodwork claiming to be design experts.
Billy: Yeah. There's certainly demand outstripping supply right now in this space.
Mark: We're seeing a prioritization on design. We're getting a new class of persons coming up who are here to connect with the graphic designers and the developers.
Billy: Yeah. Interaction design.
Mark: Exactly. I love this. I love hearing people say, "Here's my design expertise and this is what I do."
Billy: I love seeing that as well. When I do my workshop and there are maybe 100 people there, typically over the course of time I will discover that somewhere between five and 10 of them alter their career trajectory -- sometimes radically. Occasionally one or two out of that group will feel an affinity for this, and they will move much more heavily into that space.
So yes, the supply is there. The problem is that it takes time. It's not like technology. You don't assimilate and learn how to do this in three months of intense study. It's experience over a span of time. A growing intuition over a body of knowledge, a discipline, that's not really structured the way technology stuff is. You can't just look it up on Google. The answers aren't there. You need the breadth of experience and the exposure to design principles to know what works and what doesn't.
That kind of expertise takes time to develop. I'm guessing that the average person with a fair aptitude doesn't really become good at it for about two years, growing continually better from there on. Even then, you won't get everything right instantly because design doesn't work that way. You'll go, "Oh, I've got five possible ways to do this -- now let's get this to the people who will help us find the one that is right."
But I've seen some of the floundering when people first enter that space. Let's say there are 100 design principles they ought to know, and they learn 10 of them. And now they're just emphasizing those 10 to the exclusion of everything else. What they produce is clearly better than what they used to do -- but by the standards of a mature design process, it's not that good. It's like kids making mud pies. They need to grow beyond that.
To do that -- especially in the early phases, they need somebody who will push them. They need mentoring. And we just don't have a big enough group of mentors to help bring these people along. And we don't have enough examples out there. We don't have the sites that say, "Here are interesting examples of design principles in action; here is the way to think about this; here's what works in this industry versus what works in that industry; compare and contrast." We don't have that out there, because it's in nobody's particular self-interest to do that.
Mark: It's expensive to do.
Billy: It is expensive to do.
Mark: And no real clear benefit for individuals to putting that information out there.
Billy: That's right.
Mark: So hopefully this article will serve as a starting point.
Billy: (laughing) Yeah.
Billy Hollis is a consultant on UI/UX design and rules-driven business systems. He speaks at major conferences worldwide, and he has written more than 10 books. He offers training classes in UI design and XAML technologies.
- Email: [email protected]
- Twitter: @billyhollis
- Website: www.billyhollis.com
Mark Miller is chief scientist of the IDE Tools team at DevExpress. He is a C# MVP with strong expertise in decoupled design, plug-in architectures, and great UI. Mark is the visionary force behind CodeRush and is a popular speaker at conferences around the world.
Learn more about UI design and development:
