Amy Seals (http://www.projectsend.com/) works with Standing Cloud, a tech startup in Boulder, CO.

Dani: UX activities in Drupal projects often get lumped in with project management activities, so many UX designers find themselves thrust into project manager roles as well. How do you find your time split up when you’re working on a team?

Amy: In theory, it should be sort of half-and-half, but I spend a lot more time on the Drupal side, doing the overall strategy. But then, day-to-day on a technical level, I end up in project management.

Dani: Which do you prefer?

Amy: I prefer the overall strategy. Watching something develop, and reacting to users, and anticipating their needs is what I prefer to focus on.

Dani: I think one of the biggest dangers in combining the UX and project managers’ role is really on the clients’ side. They don’t necessarily get what a UX designer does...

Amy: Yes, I’ve seen that.

Dani: ...so, the fact that the project manager is discussing things like personas and user testing—things that are part of designing the user experience—they tend to lump all of that into project management and not think about how it relates to the user experience workflow.

Amy: Exactly. I think it’s easier for people to see tactical things because they can see and measure immediate impact. Of course, you’re going to have some short-term impacts as a result of UX work, but it’s really kind of a long-term vision, and adaptation.

Dani: How successful have you been at selling the idea of UX design to your clients?

Amy: In my experience, the more complex the technology, the more willing a client is to trust your judgment about what needs to be done. Back in the early days, everybody knew what a website was, and there were these preconceived notions of how a website should work. With Drupal, there’s so much complexity and capability that clients look for more guidance. But they also want to see results, so it’s kind of a catch-22 in terms of how complex the system is and what you deliver within a reasonable time period.

Dani: Have you found any challenges with rapid iteration with Drupal, or clients having unreasonable expectations in terms of when things will be ready?

Amy: I’ve run into both ends of the gamut. Right now, our development cycle is about two weeks, because we are using Agile; but other places I’ve been, there’s a tendency to forget that Drupal is very flexible, and very customizable, and you know: it is the web. It doesn’t have to be perfect—and you shouldn’t expect it to be perfect—because your users have yet to interact with it.

So we’d have these really long development cycles, and everybody would be really focused on these minute details that may or may not impact the overall user experience yet. There is this tendency towards trying to get things perfect, without really understanding what that is, or whether it can be done.

Dani: Some clients focus on incredibly minute details, and it is so much trouble getting them to understand that minor aesthetic details may make little difference to their user.

Amy: I find that breaking the project into smaller pieces, or smaller deliverables, has helped offset some of that focus on minutiae. Clients get overwhelmed with big-picture stuff, so they focus on very small details; if you can show them something like wireframes, for instance, or a user flow for a piece of technology, they can look at that, and think about it, and you can build on that instead of trying to constantly release these finished projects—or having the idea that you need a finished project in order to get client buy-in.

From a client perspective, I understand the desire for something that’s more “finished”—you’re committing a lot of time and money, and you want to make sure that what you get is what you need. If you don’t see it until the end, it’s a little scary.

Dani: What kind of user experience deliverables do you tend to build into a project? What kind of documentation do you build into a design cycle?

Amy: It depends on the project, and the client, of course, but some standard pieces are wireframes—those are a given for me. If you’re starting something from the ground up, I tend to actually deliver UI [user interface] pieces, whether it’s in Photoshop or something else.

If you have a project that’s already underway, and you already have a look and feel set, I tend away from working in Photoshop, because it’s more important for clients to get in and see how a user will use it, and be able to assess that, as opposed to spending time on visual elements.

For complicated functions—like if you have a process that’s ongoing, whether it’s an account creation or something else—I tend to do user flows as well, even before I wireframe, so that you and the client can make sure that you’ve covered all the pieces of that process. From a project management standpoint, it helps map out the project as well.

Dani: Have you ever worked with wireflows, where you create a user flow, but you’re actually sharing samples of the screen, and the information required on each screen?

Amy: I’ve done a little bit of that. Based on the projects that I’ve worked with and the level of technical experience my clients have, if I break it down to blocks, like wireframes, it often works better than wireflows. I’ll sometimes do a combination, too—I might do wireframes of a smaller component and say, “here’s a screen which flows into this [other screen], and these are the components affected by this action, etc.” But I’ll keep it really minimal, so it strips out the noise.

Dani: Do you find that clients can’t deal with the noise?

Amy: It seems to get in the way. Like you were saying, they’re worried about a specific color of blue, and not really thinking about things like what a specific piece of content needs to say in order for the user to understand what’s really going on—or even whether there’s consistency within the interface.

So stripping out the noise, and getting down to the fundamentals of the interaction, I’ve found, helps. But when dealing with developers, it’s a different scenario. They understand what’s going on, and there tends to be less worry about that sort of noise.

Dani: Now, the flip side of that coin: do you find that it’s very easy to strip out some noise, but insert the noise that Drupal gives you?

Amy: There is a certain level of noise that’s inherent in the product. It’s one of the things that’s important to moving Drupal forward, and really building the long-term usability of the product from a community and from a client standpoint: educating your user about what to expect, and what things are important (and what things aren’t). What noise is Drupal, and what noise is not? Slowly educating people on that is very important, because these are very powerful tools and you can lose track of them.

Dani: I also think it’s important when talking to clients to know what they need to know versus what you need to know. There’s this bare minimum of information that the client really needs, and half of the panic attacks that I see clients going through seem to come from somebody talking to them about all of these very Drupal-specific things.

Amy: I agree completely. I hadn’t really thought about that. It’s almost like you define your technical requirements for your developers, and then you have to translate that for your customers, and pick and choose what you show.

Dani: You have to translate Geek-Speak into Client-Speak. You become multi-lingual in a certain way, but it’s especially true with UX. You have to be able to bring a bunch of people who don’t necessarily speak the same language into the room together and say, “Okay, this is what we’re doing.”

Amy: I started out doing a lot of CRM, ERP and e-commerce, and integrating multiple platforms. So one of my roles has always been one of translator. And it’s important, because you have to be able to articulate and communicate those things, and you have to be able to set a precedent for what the client needs to approve or check, and what they’re going to be accountable for in the process.

There is a tendency with complex systems for some people to say “let us take care of the details; we’re experts.” We don’t understand that the client needs to be accountable for the product from a very detailed point of view. They’re not going to be worried about whether or not this page is delivered with Views or whatever, but they need to understand at a base level how things might work, because ultimately it’s their product.

Dani: I also think that there’s an expectation sometimes on the client side that you’re the expert—you’re going to have this figured out. And even with very complex systems, I’ve had clients who had stacks of documentation that they were surprised I hadn’t read yet.

Amy: Exactly. They understand their customers, and so it’s that middle ground, where you’re a translator—but also, you have to be very much like a filter. The client is going to tell you a lot of things, so you have to decide, as a UX person, what is critical to convey through the interface to the user? It’s a very overarching role, both translation and filtering. You’re bridging the gap between a business, its customers, and the development team, and that sometimes can be a very big bridge.

Dani: So what have been the biggest challenges for you in terms of bringing UX to your team and to your clients?

Amy: Helping people understand what UX is: you’re not just concerned with what this page says, it’s how you’re saying it and how that’s reflected elsewhere in the site. It’s how that user is going to go from here to here to here, and what they’re going to expect when they click something.

Dani: Do you feel that there are any UX techniques that are particularly useful with Drupal over other technologies? Or do you find that the process is about the same?

Amy: Because I tend to break things up into pieces—site flows and personas, or pain points and that sort of thing—Drupal actually helps because it’s very much an evolving product. If you’re implementing a new module, for example, there are various pieces at play, so it’s easier to explain to a client that they’re not going to be able to see instant implementation, because there’s so much more to it than just turning something on.

Drupal also helps create the expectation that a website is not a fixed thing. You get it out there, you mold it, and you shape it, and it changes as your needs and your strategy change. Drupal is very flexible and open, which makes it easier to drive that message home.

Dani: Even as a designer, there is a sort of re-education process once you get into Drupal. I came from the Wordpress world, and it felt like you would put up a blog, put up a few other pages, and then you were good to go. With Drupal, you had to get into that space where you were now talking about discrete sections of the site almost as a specific chunk of functionality. You really do have to, in order to engage a very rapid and iterative and, indeed, agile, process, understand that you can’t have a project plan that says, “Okay, on the week of the 14th, we’re going to do all of the content types for the site.”

Amy (laughing): Exactly.

Dani: And I’ve seen project plans that were like that, where on the week of the 14th we were going to do all of the content types, and on the week of the 20th, we’re going to do all the Views.

Amy: It’s very integrated, so you can’t break it up like you’re used to doing traditionally—you know, “We’re going to build something manually to update the content with PHP, so we can self-contain this little project and you don’t ever have to think about the rest of the site.” Drupal really forces you to think about the site holistically every time you do something.

Dani: You have to think about how things fit together, how content is organized, how it’s formatted, because all of that feeds into your workflow.

Amy: Yes, because there’s so many hooks in and out. From a user flow standpoint, it’s great, because you can’t really ever self-contain an area of the site. There’s this need to keep it constantly in check—how the piece you’re working on is impacting other areas of the site. That’s fantastic from a UX standpoint. It does make managing pieces of a project much more complex, but it’s a great self-check for managing that entire user experience, and managing it over time.

Dani: It’s also good for establishing design patterns. There are ways that Views work out, and it’s not because that’s just what Earl decided to do after a couple of Mountain Dews, it’s because this is the way it’s supposed to look.

Amy: And you can reuse those things too. It lends itself to reusing components very easily, so you don’t have to start from scratch every time you do something.

Dani: So what do you think of as your role in the Drupal community, or rather the role of UX in the Drupal community?

Amy: I see it as, for lack of a better word, advocacy. I’m not a coder. I don’t know how many UX people, if they specialize in that, are coders by nature; our biggest role is getting out there and advocating for the use of the product: being able to articulate why it works and how it works and being that translator between the two worlds. And really pushing the product forward: getting people using it, and using it well so that the community can continue.