by Judith Dinowitz, Master Editor-in-Chief
Do your sites and applications provide a satisfying, uniform experience across all platforms? Dave Hogue, Vice President of Experience Design at Fluid and speaker at this year's D2W conference, explains what (and who) it takes.
What is experience design (XD) as opposed to traditional application design?
Traditional application design is probably a phrase that we don't use very often in the web world. It comes from the software world, where people are thinking in the desktop model. Design an application to complete a task, package it, send it off, and it sits on the user's computer. But modern experience design crosses the boundaries of devices and includes both the web and apps. It's not just using an application to do a task. There's also a social component. We access the web and use apps at work, at home, and on the go. We might be standing in line at the store, killing time while waiting for the bus, or watching TV while we're also playing a game or emailing a friend or browsing the web.
Experience design is about being personal. It's more than just the interface, and it's more than just the functionality: It's really how these devices fit into our daily lives — how we?re using them, how we're applying them. The big difference between XD and traditional application design is that we're not just thinking about what people see on the screen, we're thinking about what they experience when they interact, who they are with, what they are doing, and how their computers and devices are responding to them. It's a larger ecosystem of factors, not just an interface or functionality.
How would you typically use experience design when creating a web site or app?
First, although a person may have the title of
"Experience Designer", we're not talking about one person creating an entire application alone. The field of XD (also referred to as user experience, or UX) involves multiple team members with different skills. When companies, especially small companies or startups, are looking to hire, they describe someone who's a master of everything, from design to coding — we refer to those people as
"unicorns" because they are non-existent. It's an idealistic job ad, and no one like that really exists, so they should be hiring a team.
So who's on this team?
UX design involves, first, UX researchers. These people conduct research with users, watching them interact, looking at what they are doing on a daily basis and finding the pain points in their tasks and tools. They help us understand the target audience, their needs, and their expectations. This is essential for revealing or uncovering the opportunities for a web site or app.
Then there are two types of designers. One is the visual designer, whose primary focus is on appearance: brand, color, topography imagery, iconography. They also work very hard on nuanced details of the interaction, such as motion graphics and transitions. For example, when you?re using your smartphone and you see things fade in or out, slide into or out of view, open in layers: these are the behaviors of the interface, and they help people understand how the web site or app works as well as providing feedback about their interactions.
Right. Because if it doesn't look good and work smoothly, who's going to want to use it?
Then there's the interaction or information designer. They are responsible for the structure, organization, and workflow of the web site or application. They ensure that web site or app meets the needs of the user.
We can compare it to designing a house. An architect creates a blueprint and decides where is everything placed, what is the scale, how all of the systems are connected, making sure there is good structure, good organization, and that the house is going to function for the people who live in it. That is the equivalent role of the interaction designer on a project.
So the interaction designer would probably work closely with the researchers.
Definitely. The entire team should be working together and collaborating. Experience design is the responsibility of everyone — it's not a single role.
This also includes the developer, who works with the designers to create prototypes, and who eventually creates the code for the actual web site or application. They take the prototype out to the users to see if this is what they need, what they expect, and then the application is refined based on observation, interviewing, and testing. You polish the design, and you fix anything that isn?t working correctly.
So although you may have people with the title of an experience designer, they're rarely (if ever) doing all these things.
So we're talking research – design – develop – test – get feedback – develop some more... It's a cycle.
You can compare the UX design process to the concept of agile development, where iteration and collaborative team effort are essential. The idea is you work to get something functional, you bring it to your customer, you monitor the usage and feedback, and then you continue with design improvements and development.
Are there any websites or apps you've done that you're particularly proud of? And please tell us why...
We work at Fluid on a wide range of exciting projects, from mobile apps to kiosks to websites and web applications. Most of our clients are retailers and financial services who have web sites and apps where reliable, efficient functionality is essential, yet they need the experiences to be enjoyable, engaging, and satisfying. One of the most interesting is an interactive DIY magazine for the iPad called Craftsman Torque that includes articles, media, and shopping for weekend projects. We've created in-store touchscreen kiosks for Vans and The North Face and a self-service wagering kiosk for horse racing tracks. Perhaps the most complex web application was a complete re-design for the Charles Schwab customer account management site, where billions of dollars of investments are managed every day.
Can you tell us a bit about the hands-on class you're doing on Wednesday, May 16, on designing responsively? What do you mean by
"Responsive web design"?
One of the challenges we have now is that there are so many different devices people are using to connect to the internet, and each device has a different screen size. Historically we really haven't had to deal with that. Until relatively recently people dialed up, and they sat at their computer and browsed.
We now have a new problem: websites that work on your computer don't work or look right on your smartphone or tablet. They're often not usable. The website doesn't adapt to the size of the screen on which it is being displayed.
In this half-day class, we're going to cover how to design responsively. We will discuss responsive web design (RWD), where the web site adjusts itself to the device's screen size. We'll go over the key things that we need to consider to design a responsive web site, such as screen sizes, layout changes, and handling navigation and functionality.
So this is on the fly? Does it involve creating multiple versions of a web site — like a display page for print, for web, and for a smartphone — or is it something more dynamic?
Definitely more dynamic. It will quickly become unmanageable to design and build different web sites or apps for each (or even selected) devices. The goal of RWD is to design a flexible, adaptive web site or app that can be coded just once and which will be usable on any device. We need to design for the different screen sizes so that we can define how the web site or app will respond, but we should not be building different experiences for different devices unless it is absolutely necessary.
The D2W conference is focused on workflow. In your opinion, what is the key to a good XD workflow?
I can summarize that in one word: collaboration. It's all about collaboration. We can use both XD and responsive web design as examples. The best end product comes when all of the members of the team are working together through the duration of the project. When the visual designers, the interface designers, the researchers, and the developers are all involved in each stage. You get the best product at the end when all the people who are providing all of the different skills are working together.
Even if the designers are not conducting the research, they need to be aware of it and informed. The developers help us build the prototypes, so they should go with the designers and researchers to see how the prototypes function during testing, what users say, and how they react. The team should be able to say:
"I understand what needs to be solved by design" and
"I understand why it was designed this way." Everyone should be hearing and seeing things like this.
Are you a big believer in frameworks? Or in any particular framework/tool for designing applications?
Let's talk about the value of a framework for prototyping. Traditional design documents are static; they're just pictures. It's difficult to explain complex interactivity with a picture. The frameworks allow us to quickly built a prototype, so even if it doesn't look like the final product, we can show how something could work rather than just a picture of what it looks like.
Can you give us some insight into what attendees should expect if they come to your session,
"Understanding Complexity, Designing for Simplicity"?
It's a variation of a talk that I gave at SXSW recently. The whole goal is to discover where complexity comes from in our products. When we understand where our process leads to complexity, we can learn how to design simpler, easier, more enjoyable experiences, without sacrificing quality and functionality.
The session covers things that developers will identify with, that all of the designers will identify with. It crosses boundaries and talks about product design, industrial design, as well as digital design. There are many parallels in the design and build process, and complexity happens in each of those different channels. It's not just for designers or developers; it's for anyone who?s involved in creating and building things. We are all creators and builders and thinkers so we all need to understand how things become more complex than they need to be.
Any words of wisdom for our developers/designers in the audience?
Never work alone. Make the opportunity to collaborate even if you're the only person on a project for the simple fact that the more brains you throw at a project, the better the final product will be.
Thanks, Dave, for the interview.
My pleasure, Judith. I hope to see everyone at the D2W conference!
Judith Dinowitz is the Master Editor-in-Chief of the House of Fusion magazines and journals, where she enjoys serving up ColdFusion and Flex goodness on a weekly and quarterly basis.