Enterprise Interaction Design?

Here’s a question for you all …

How does your practice of interaction design differ when you are in an enterprise context from a consumer oriented context?

I’m not interested in the politics, and relationship management or other soft skills that change, but the actual design of systems meant for users within large scale organizations.


In my practice it doesn’t change a whole lot. We treat consumer software users and enterprise users largely the same way, doing research and understanding both the business objectives and those of the people who use the software… Enterprise software still needs to be beautiful, useful, fun, efficient… For something that people are using every day, and have to use, we try to make sure that’s is as good as possible and makes their job enjoyable (as much as we can anyway).

I suppose the biggest difference is that most of the enterprise users have to use the software for their daily work, they don’t have a choice, where consumer software is chosen by the individual. I’m not sure off hand how that’s influenced my design choices, but I’m sure it has in some way.

1 Like

I’ve worked on both consumer and enterprise products and the character of the product may be different, but my practice of interaction design doesn’t really differ based on the nature of the product. I agree with @emenel that people’s orientation to these products are different, meaning the person using the enterprise software doesn’t likely have a choice about using it and the purchase decision is removed from the usage of the product. It seems that the practice of interaction design going to be more influenced by the nature and constraints of the organization than the enterprise to consumer distinction.

1 Like

I think Cooper’s “About Face” highlights a distinction within personas that becomes absolutely critical when designing for enterprise, and that is the distinction between the customer persona and the user (primary, secondary, supplemental) personas. For many (most?) consumer products, the customer is the user, so personas do not need to distinguish between those two sets of goals. For enterprise product design, however, the goals of the customers and the goals of the end users are often extremely different, if not at odds with one another.

In my rather limited experience, I’ve found it to be extremely beneficial to actually segment those people into different personas, and seek to understand their unique perspectives on the product, whether the “customer” is a stakeholder in the case of a custom-built solution for a single organization, or a customer in the more common sense as an IT services manager or someone like that.

That’s maybe all just an additional step internal to the design process, but I do believe it necessarily affects the priorities of the design, I’m just not quite sure if it manifests in a consistent way.

I can’t really say how my own practice would differ, as I only do work for enterprise. I have to imagine, however, that the most significant difference, as @PWLast points out, would be my role as a mediator between the needs and wants of the user and those of the customer. Where the customer doesn’t, I must ensure that I understand their employee’s work context and educate the customer about it. I must also try to convey to the users that some things are done for upstream reasons that are, ultimately, beneficial to the organization as a whole.

To @emenel’s sentiment, I hope that I never fall into the lazy trap of relegating problems as “training issues”. The fact that the users are required to use the software should increase empathy towards them. I feel genuine guilt when something I’ve designed negatively effects a worker’s efficiency or mood.

These are all great points.

I tend to look at the enterprise customer/user breakdown in a similar way to how I approach my client/user relationships, so the fact that I didn’t see it as being that different might just be personal bias from working in a consultancy/external studio.

In both cases we have to consider, and please, both our customer and their business goals, as well as the end user of the product. Even though in enterprise the end user doesn’t get to choose the product, I tend to think about these two cases similarly in terms of our approach. The biggest difference in how we end up positioning and “selling” the product to the different groups involved.

Thanx for the conversation! Great stuff!

For me there are 3 areas of distinction that drive my enterprise work that doesn’t apply to my consumer work:
Scale, Wickedness, and Proximity.

Scale - There is just more of everything in large and for large organizations. You need different tools and different methods in order to manage scale, make connections, drive understanding, find insights, etc.

Wickedness - or interconnectedness of the problem space. It is so much more easy to reach that moment that solving one problem actually breaks a previous solved problem, or alternatively, one solution can’t happen until another solution with completely different collection of stakeholders and attributes has to be solved (dominoes falling).

Proximity - Large organizations and the problems they are solving have proximity issues of various types. Not necessarily or limited to physical proximity. You have issues of workflow and business process management which are whole disciplines of their own with distinct tools of craft. But this is where it gets interesting for me. Almost exclusive to the enterprise context (there are exceptions), you have situations where the problem owners for which enterprise systems are being created are not users of the tools being crafted. Patients are the clearest examples. But there are a host of others. Even if they are members of the enterprise, the problem owners are so far away from (degrees of separation) from both use and purchase that they are just ignored as part of the space. Then when you take proximity and add in scale of purposes through the creation of platforms where purposes then become variate, the intricacies and wickedness of solutions become even more perilous.

To track these flows requires news tools, borrowing from service design and organizational change process.

Questions I have are around:

  1. How do you manage generating insight at scale
  2. What do you use to design solutions of intricate and substantial complexity at the systems and human relationship level?
  3. How do you make sure that multipurpose solutions (aka platforms) meet the needs of a complex set of problem owners, who are seldom the requesters of the solutions themselves?

For me standard IxD practices can’t be where we begin. This isn’t about “user centered-ness” as a core process any longer, but about systems-thinking. This is a whole lot of new.

– Dave

1 Like

Sorry, @daveixd, I think I misinterpreted your original question to be more about the software end product. Where you’ve elaborated this is even more interesting.

I would argue a couple things: Wickedness (the way you’re talking about it) is also a major factor in a lot of “consumer” software products these days, and it’s not getting simpler.

Scale and Proximity are definitely big (and bigger than consumer) considerations for enterprise. For example the purchasers of a solution might be very far from the impact of the problem, but also from the ownership of the problem. The owners might be VP level (for example), and the problem impacts junior employees, but the purchasing is done by IT.

You said in the original post that you wanted to stay away from differences like politics etc… but I’m not sure that’s possible when one of the key differences you’ve identified is the organizational dynamics that create disconnects between end users, purchasers, and problem owners. Finding a solution that fits the enterprise is about applying our lens to the whole system of the organization and finding the right levers to pull.

In my experience the answer to your first question, generating insight at scale, is really about reducing the scale through scope. We use our research to identify pieces of the larger system that we can affect meaningfully (or try anyway), and focus on those while staying aware of the larger system impact. We often talk about taking a network perspective, or “network centred-ness” rather that user centred. The “user” is part of the network, and it might be where you can have the most impact in the short term, but that impact will have effects throughout the system.

We use tools like soft systems methodology, systems mapping, anthropology (not looking at “the user” but looking at the cultural and production systems), and cybernetics to complement our set of design tools and methods… Being able to create a shared understanding and vision, and then quickly prototype small pieces of a larger system and see the feedback is amazingly helpful when dealing with complexity.

There’s a lot of similar things happening in other types of networks that we can look at… One of my colleagues wrote a great blog post about this that might be good fodder for the conversation. http://www.normative.com/deep-convergence-networks-software-people/

I guess where I’m going with this is that maybe in this case “enterprise” is more like “network” … and how can we apply our tools to understanding (and/or modelling) the network in question to define problems, goals, etc in a way that help the solution satisfy different parts of the system at the same time.

1 Like

Not sure about differences but would certainly want to gain an understanding of the current way of work and legacy to be aware of as it relates to new or improved interactions being designed.

Matt, are you finding it difficult to maintain the view of the elephant when you keep split scope into more manageable chunks? This is my issue w/ Lean methods. By constantly doing things at a smaller piece, you never get to understand the interrelationship between the pieces.

When Facebook has 2 Billion users, how is that not a problem of scale?

I’ve done a lot of this work and found few main differences:

  • Much more upfront research work. You often have to become an (fast study) expert on the role the user is playing, often in the span of a few weeks, in order to begin to understand what how the user’s goals, tasks, flow, and success can be defined. A few examples of this from my work are financial research, analyst, and trader, all very different roles. I started reading everything I could find about those roles, then spent time being a fly on the wall, then moved to interviews with key questions, then prototyping, etc. They feel their time=$$ so it has been important to come in focused and knowledgeable. Often this means learning tons of jargon and paying some experts to practice and confirm your new knowledge before entering the client partner’s sphere. This adds time to the front, middle, end of a project. Another design was for something called a “Brand category manager” - this is the kind of person that monitors the success of a supermarket “end-cap” display and other marketing efforts in retail outlets. Already lots of jargon. I love this work with its steep learning curves; it can be quite exciting. I enjoy figuring out how to be a wonk in any field. Immersing yourself in the world of the enterprise user can give you the insight and some empathy to do good design.

  • When doing the research, often the client’s sales teams are involved in granting you access and they can be quite protective of their “customer.” They might think of you either as part of their promotion activities, or possibly a liability that needs to be observed; both are fraught when you are simply trying to do basic research and ask the naïve questions. This can be high-stakes and needs to be treated with care.

  • The bar is lower for what good design looks like. Sometimes partners are not interested in using consumer standards for the look and feel (or even architecture), often they have a more conservative aesthetic and/or are risk adverse. Often the engineers are not up on the latest frameworks (and cannot do what you propose). Often the design you create needs to live in an ecosystem of other software that is not designed well (and the client partner does not want the new piece to reflect poorly on the old). In short, sometimes it is not all it can be. I find its important to master the dual art of compromise for implementation, while also holding the partner organization to a vision of what is possible.

1 Like

Actually, I could argue that Facebook is an Enterprise on many levels. Scale being one of them.
Further, since their customer is not their end-user, you could argue that. However, the end-user regardless of being the customer, is choosing for themselves whether or not to join, so again, no.

They definitely have enterprisey like stuff going on. But in otherways they don’t. Enterprise probably isn’t a bounded concept as much as one with multiple properties that all generate gravitational fields of attraction to it.

If you don’t bring it up, I doubt anyone would have thought of Facebook as Enterprise. However, would you ever think of EMC, Oracle, or SAP as anything but enterprise software companies? Why one vs. the other? Where is the cloudy line of division here. What combination of qualities? (maybe Kristian is answering below)

So, are you saying that end-user choice is a determinant of whether something is enterprise or not?

Are there applications/services that users can opt into in an enterprise setting?

If I choose to use my company’s supplied retirement planning tool, I’m opting in, but if I decide to use my own, then I’m not. So, is that retirement planning tool, offered to employees as an option, not an enterprise application?

I think you are looking for black & white, where there are grays here.
Generally, I would say that yes, end-user choice, or level of choice is a part of the criteria.
As to your example, It is probably a consumer application (the planning tool); however, there are probably other aspects that are related to that experience that are most definitely enterprisey. I.e. the ability to actually create your distribution is most certainly one in a single space.

So while I can plan using fidelity, e-Trade, or whatever I like (though they might not have access to program specific investment options), to enter the details of my choices that I learned I want to make will have to be done in the plan interface itself.

Considering that 401k Management systems for Prudential, Merrill Lynch and Mellon were some of the first Enterprise apps I designed back in the 90’s I’m pretty confident in their being Enterprise. :wink:

other example that are lack of choice are interesting in their blurriness, right? I chose Vz as my phone, but I don’t chose the insurance broker. So I’m forced to use their interface, right? Is that “enterprise”? Definitely on the blurry part of the spectrum.

Jared, you seem to be challenging the criteria, but not offering other properties. Do you not think that Enterprise is a separate collection of contexts similar to say Healthcare, Military, Government, Education, E-Commerce, which are banners we could & do gather as practitioners under? If it does exist how does it exist for you? What properties do you think of when you think of Enterprise?

You are correct. I don’t think that “enterprise” is a thing.

I think there are dimensions, like whether someone chooses to the use the app or has market choice as to which app they use.

But I don’t believe there’s a collection of qualities on a series of dimensions which defines “enterprise.”

I think “choice” is too blurry to be a distinguishing factor, although I agree that for enterprise software, users typically do not have a choice as to whether or not to use it. Scale is not particularly useful by itself either. Perhaps a better criteria would be simply who the software is sold to. I would argue that if I can buy an application in the App Store or on Amazon (or download it for free), it isn’t enterprise software. Enterprise software is sold to a business. By this measure, it is either enterprise software or consumer software. That means my bank’s iPhone app is not enterprise software, but it integrates with enterprise software. What about my bank’s web-based banking application, then? I can’t buy it, but I do use it as a customer. In this classification, I would have to say the bank’s customer facing website is not enterprise software.

On the other hand, there is software that my bank uses to manage me as a customer. They can do all kinds of stuff to my account. That application is not publicly available. I can’t buy it. I can’t access it. That’s enterprise software.

Okay, Dave, start poking holes.

I guess, at the end of the day, I’m wondering what difference it makes if something is enterprise or not?

What fundamental difference does it make to design, process, or outcome?

This feels like it wants to be a “my job is harder than yours because I have these extra challenges” pissing contest. But I’m not sure the Enterprise label makes it harder to create software than any other label, even if we could agree on what gets the Enterprise label.

I’m still not sold there’s a there there.

Perhaps the label might be helpful in providing the shared understanding of Enterprise. I’ve read references to internal software built by internal teams for internal users, proprietary software built by external teams and sold to consumers, and more. To me, those are delivery mechanisms, not the diagnostic.

When I hear the term Enterprise used, I believe it’s in reference to solutions having a direct relationship with someone’s job. With that, Enterprise can be a label used to describe systems used to satisfy the needs of a job. That can be anything from SAP to Facebook, as long as it’s being used to meet those needs.

I also believe Enterprise design is facilitating relationships between multiple systems, organizations relying on these systems, and users. CRM, Learning Management, Workforce Management, Knowledge Management, Performance Management, Multi-channel, Voice of the Customer, etc. are examples of these types of systems. Each example could, by itself, be a rather ‘large’ system with scale, wickedness, and proximity issues. If you consider the daily interactions of an Enterprise user (someone using a solution for their job), one has to understand they are traversing in and out of these systems for any given process.

To reiterate on what Dave mentioned above, the practice of design for Enterprise may differ from that of many consumer products because of these relationships between systems. Designers need to be aware of these relationships, or dimensions as Jared wrote. That doesn’t make the practice more difficult, but many designers don’t deal with these specific dimensions on a day to day basis, so it’s different. There is less literature about the dimensions, so I believe this discussion is about exactly that.

Similar to a consumer context, Enterprise users are constantly looking for alternatives. They have simple, "easy-to-use” solutions in other areas of their lives and are looking to incorporate these types of solutions into their professional lives. Many users take matters into their own hands, finding and using alternative solutions which fly under the IT radar. Eventually, many of those solutions are discovered and shut down; largely due to security and stability concerns. I see this as a massive opportunity lost for organizations. Instead of listening and discovering why users have sought other solutions, many orgs simply make these solutions go away. This is where the practice of design can play a major role.

All that said, my practice of design in an enterprise context means I work directly with business and technology counterparts on a daily basis. What I mean by that is, in order to incorporate design into the end-to-end process, I have to understand the languages my colleagues speak and in turn, be able to communicate design in those languages. For me, this has provided a lot of exposure to many areas I don’t believe I would be exposed to otherwise. I work daily with teams from Legal, Finance, Procurement, Business Strategy, Operations, Public Relations, IT, etc. This has proved to be invaluable, as it affords me constant opportunities to incorporate design approaches into different areas of the business. It’s not special, it’s not harder, the context is just different.

@daveixd (this is a long overdue reply, so the conversation may have moved on…) When we work on “small pieces” of a larger problems it’s always in the context of some sort of larger system map, and the pieces are ways that we can poke the system for feedback. Getting a smaller piece of the solution into the active system lets us see what the ripple effects are, and then we can update/refine our model so better understand the larger scope.

This is where methods like SSM (http://en.wikipedia.org/wiki/Soft_systems_methodology) come into play, letting us do continuous modelling of the larger system while working on different pieces of it.