An architect's guide to human-centered design

If you don't design for the emotional needs of your users, they will develop their own negative emotions around your product or service. Positive emotions are the grease for human decision-making, and enterprise architecture adoption requires a great deal of it to succeed.

As a developer, software architect, and educator, I am constantly looking for the best framework to communicate how human-centered design applies to enterprise architecture. In this article, I explore one of my favorites methods: The 5Es. The 5Es come from work at Doblin, now a Deloitte business, founded by Jay Doblin and Larry Keeley in 1981. Back in 1997, Larry presented the 5Es at one of the first TED conferences, sharing just one of their many innovations around systemizing and democratizing design. [1]

The 5Es of Entice, Enter, Engage, Exit, and Extend can describe any number of interactions your users experience while using your services. It often includes the emotional state of the user as well as the physical actions they will undertake during their user journey. Throughout the use of 5Es, I focus on the user's perspective in a way we rarely see as software architects. Let's explore the 5Es, and see how they intersect with enterprise architecture.

Entice

The Entice step asks us to uncover and think about the ways our users are made aware of the features and capabilities of our offerings. Intentionally enticing our users ensures a fit between the user and us. While it sounds obvious, it can be difficult to get out of our own builder mindsets and think in a user-centric manner.

Here are some questions to help you get to that place for enterprise architecture adoption:

• Is getting access, registering, or creating a user account available to all users, if required?
• Does it appear that the service or system will deliver the capabilities a new user needs?
• Am I thinking about the emotional state of the user when they log into this service?
• Am I thinking about the level of training I expect users to have?
• Have I considered system monitoring and management so I can uncover friction or pain points for my user community?
• Am I willing to consider that this is just one of the 100s of computer interactions a typical user will have on this day? What does that mean for me and what I am creating?
• Can the user surmise or naturally discover what is expected from them without needing to summon impossible-to-know expectations of the creator of the experience?

These questions will trigger a conversation amongst enterprise architecture teams and help them consider a bigger picture. The user has other priorities, different emotional states, and often different goals than we have as designers of these systems. The intention of Entice is to consider both the first and 100th time they use the service to ensure it continues to intrigue them. We can know Entice is covered when we can be certain users will be successful rather than hoping they might succeed.

Entry

Once I have thought about how the user will be brought into my service or application, I have to ask them to enter the experience.

Upon Entry, you now have a user. Some questions arise naturally from that point:

• Are users greeted with a unified experience that seems curated for their expected journey?
• Does it appear that colors, fonts, and layouts speak to a human and that show care and thought was used for how they come together?
• For enterprise architecture, is it clear that thought was put into the various systems that will be in use to accomplish their goal?
• Is clear and concise feedback about expectations and use modalities conveyed to the user?
• If errors happen as the user enters, is it clear how to get help and where to escalate if things are not working for them?
• Most importantly, are users given the tools to self-diagnosis and troubleshoot where things might be going wrong?

Various enterprise architecture standards speak to the resiliency and robustness of our IT systems. However, they do not put the human tasked with using or running these systems at the center of our decision-making. Users empowered with systems that feature low friction, toil, and invisible work will be repeat users. Toil is commonplace in enterprise architecture and is, therefore, a great opportunity to differentiate your system from others. Once we allow users to Engage with the inner loop of their/our activity, we have set ourselves and our users up for success.

Engage

Once the user is engaged with our human-centered systems and processes, we must ensure they are successful.

Questions that come to mind to Engage users include:

• Do I curate the experience and put up guardrails so they can't help but be successful?
• Do I ensure that if an error occurs, they are given the next best action for recovery or are allowed to back out of the change?
• In the case of system or software rollouts, can we go back to a last known good state?
• Most importantly, with software rollouts and updates, are rollbacks systemized so that hand-jamming of errors and fat fingering of commands is impossible?
• Can security patches and hotfixes be applied as soon as they are known?
• Do I minimize the amount of information stored in our users' brains, thus lowering the cognitive load expected?

The length of time it takes for your user to deploy an update, navigate around key systems, and successfully complete complex tasks is a great focal point at this stage. Our objective is to design a system where enterprise architecture processes get out of our users' way through sane defaults and clear options. Our goal is to allow for what psychologist Mihály Csíkszentmihályi describes as Flow state until users are done with their tasks.

Exit

At some point, like everything, the tasks the user sets out to do will be completed, and they will Exit the experience you have created for them.

User-centric questions to ask yourself at this point include:

• Upon exiting, what resources are automatically cleaned up for the user?
  • For instance, if cloud resources have been spun up to support the interaction, will they automatically be brought down to zero or be reallocated to another user?
• Do I allow users to save where they are and remember what they were doing to enable them to come back to a task that is not yet able to be completed?
• Are users logged out automatically to support security best practices?
• Have I allowed for a clear delineation between being inside and outside of the experience?
• Do I proactively show them they are done, giving them the sense of accomplishing their mission?

By having a clear end, you help them to attain a work-life balance. Ensuring your user ended the experience on a high note helps them remember the entire experience as positive, even if it had some stumbles along the way.

Extend

Most designs and experiences end here, with the user logging out and completing the activity. However, what can you do to Extend the experience for them while protecting work-life balance?

Extending the experience is critical for creating really sticky and engaging software architecture.

For example:

• DO I allow for a clear delineation between being inside of and now outside of the experience? This can take the form of sending an email after the user has completed their task, letting them know what they have accomplished, and giving them key success metrics.
• Another after-the-activity action can be nicely reminding them they have some action pending, but also allowing them to turn off such notifications if they do not wish to receive them.
• Another form of extending the experience is learning what they were working on either directly by asking for feedback or by using instrumentation and automation. These can provide insights into what the user was doing and uncover friction, toil, and invisible work that might have occurred.

Note: A challenge and opportunity for you—when was the last time you asked your users for feedback?

In the context of design and empathy, I challenge you to watch in silence as your users try to use the systems you have designed for them. The insights gained from your silent participation will be priceless to you. It will speak volumes to your users about your commitment to them as humans as you thoughtfully observe and think about their needs.

Conclusion

The 5Es can be used as a roadmap or guide to help you think about creating compelling experiences for all users of your systems. These users can include the typical external and internal users as well as the stakeholders you need to satisfy when creating systems. Using the 5Es as a guide to design compelling and complete journeys for your users is important to show your users and stakeholders that you care about and are thinking of them.

Interestingly, as enterprise architecture designers, we historically miss out on the first and last of the 5Es, Enticing and Extending the experience for our users. Organically and by definition, our users will always experience the middle 5Es of Enter, Engage, and Exit. However, by holistically using the 5Es, we can design a robust, complete experience. As enterprise architecture continues to evolve, by using the 5Es, we have the opportunity to imagine and create a curated journey that delights users.