Episode 27: A Task is a Task

A Task is a Task… Or is It?

On the latest episode of Appian Rocks, I sat down with Sandro and Marcel to tackle a long-standing debate in the Appian world: User Input Tasks vs. Database Tasks.

At first glance, it seems simple—tasks are things people do in a process. But should we store and manage them inside the process model or in an external database? That’s where things get complicated.

What Actually Is a Task?

Marcel kicked things off by questioning whether every process step is a task. In short, no. A process can involve automated actions (system-driven) and human tasks (where someone makes a decision). In Appian, these are typically User Input Tasks—but sometimes, we need a more flexible approach.

User Input Tasks vs. Database Tasks

– User Input Tasks (UITs): Managed by Appian’s process engine, providing built-in assignment, escalation, and tracking. Great for structured workflows.

– Database Tasks (DB Tasks): Stored in a database, offering flexibility but requiring custom-built task management. Often favored by developers from traditional backgrounds.

The key takeaway? UITs handle structured processes well, while DB Tasks are better for case-driven workflows. The problem arises when teams mix both approaches, leading to complexity and redundancy.

When Does It Matter?

If you’re managing millions of tasks (like Joe Longworth in Episode 20), UITs might struggle, and DB Tasks can scale better. But for most use cases, UITs prevent unnecessary complexity—unless your process is inherently dynamic.

Another challenge? Cross-application task lists. If every Appian app implements DB Tasks differently, you lose the ability to provide users with a single, unified task list.

What’s the Right Approach?

There’s no one-size-fits-all answer, but here’s our advice:

– If UITs work for your process, use them.
– If your workflow is case-driven, DB Tasks might make more sense.
– Don’t mix both unless you really know what you’re doing.
– Ultimately, good Appian practitioners challenge assumptions. It’s not about what’s easy to build—it’s about what truly optimizes the process.

What do you think? Drop us a comment, and check out the full episode for the deep dive!

Episode 26: Terminating Processes

The podcast delved into the critical role of UX design in Appian projects, highlighting the direct link between user trust, satisfaction, and the overall success of an application. It emphasized that while building functional systems is essential, creating intuitive, user-centered designs is what ensures long-term engagement and trust. Poor UX design, whether in the form of unclear processes, lack of transparency, or unexpected system behavior, can lead to frustration, distrust, and ultimately, disengagement from users.

A key focus was the importance of understanding user behavior and designing systems that align with their needs while anticipating their challenges. Users come to systems with habits and expectations, often shaped by their previous experiences. While it’s essential to consider these habits, it’s equally important to recognize when these expectations might hinder efficiency or innovation. For example, if users are accustomed to a manual confirmation process but a single-click solution is more efficient, the transition must be managed carefully. Clear communication about why a new approach is beneficial can help users adapt while maintaining their trust in the system.

Transparency and communication were recurring themes in the discussion. When processes or tasks change unexpectedly—such as when a task is canceled or a process terminates due to an error—users need to be informed promptly and clearly. The group stressed that system actions, especially unexpected ones, should never leave users guessing. Notifications that explain what happened and why, alongside safeguards like preserving any work completed before a task’s cancellation, contribute to a system that feels reliable and user-focused.

The conversation also highlighted the importance of designing with empathy. UX design isn’t just about creating interfaces; it’s about crafting experiences that make users feel understood and empowered. This involves asking questions like: What is the user trying to achieve? What challenges might they face? What might frustrate them? For instance, when users are multitasking or working under pressure, a system that proactively supports them—such as preemptively filling in data fields or guiding them through complex workflows—can make a significant difference in their overall experience.

Another point raised was the balance between automation and user control. While automation can streamline workflows and reduce manual effort, over-automation without user input can erode trust. Users need to feel they have some level of control and visibility over system actions. For example, automating a task without providing users with an option to review or intervene can lead to dissatisfaction if the automation doesn’t align with their expectations or needs. The team discussed the importance of striking this balance to ensure automation enhances the user experience rather than detracting from it.

The discussion also touched on the need for iterative design processes. UX is not a “set it and forget it” discipline; it requires ongoing evaluation, testing, and refinement. As users interact with a system, their needs may evolve, or unforeseen issues may arise. By actively collecting feedback and incorporating it into the design, developers can ensure their systems remain user-friendly and effective over time.

Ultimately, the episode underscored the idea that good UX design in Appian projects goes beyond aesthetics or technical features. It’s about creating systems that feel seamless, intuitive, and empowering for the users. Thoughtful UX design fosters trust, builds engagement, and ensures that technology serves as a true enabler of productivity and innovation. The conversation emphasized that when UX design is prioritized, the result is not only a better user experience but also a more successful and impactful application.

Episode 25: Highly Regulated Appian

In this episode of Appian Rocks, I, along with my co-hosts Marcel and Sandro, explore the intricate challenges of using Appian in highly regulated environments, particularly within the financial services sector. We kick off the discussion by defining what constitutes a highly regulated environment. Essentially, it is one where external stakeholders impose specific requirements that go beyond the functional needs of the software being developed. These requirements often include compliance with various laws, best practices, and standards related to data protection, auditability, and traceability.

Marcel draws from his extensive experience in financial services to provide valuable insights into the regulatory landscape. He emphasizes the importance of understanding the sources of these regulations, which can stem from formal laws or best practices that organizations are expected to follow. For instance, regulations may dictate how data is handled, how processes are audited, and the level of traceability required for software development. This understanding is crucial for Appian developers, as they must balance functional requirements with the need for regulatory compliance. Failing to meet these standards can have severe consequences, including the potential loss of a company’s license to operate or facing significant fines.

Throughout the episode, we stress the importance of engaging with compliance teams early in the development process. This proactive approach helps ensure that all regulatory requirements are clearly understood and integrated into the software development lifecycle. We discuss the challenges associated with traceability and documentation in Appian, noting that while the platform facilitates rapid application development, it does not inherently simplify the compliance processes that must be followed.

One of the key takeaways from our conversation is the need for a robust compliance framework that aligns with the organization’s existing practices, particularly those used in high-code environments. We encourage developers to leverage the knowledge and expertise of compliance officers and other stakeholders within their organizations. By actively engaging with these individuals, developers can ensure that all regulatory requirements are met without compromising the efficiency of the development process.

We also touch on the importance of documentation and the need for clear communication regarding compliance requirements. It is essential for developers to document their processes and decisions thoroughly, as this documentation serves as evidence of compliance during audits. We highlight that while Appian allows for quick development, the complexities of regulatory compliance require careful planning and collaboration.

Moreover, we discuss the trade-offs that organizations must consider when implementing Appian in a regulated environment. While the platform offers the advantage of rapid application development, the associated compliance requirements can introduce additional overhead. Organizations must weigh the benefits of using Appian against the potential challenges of meeting regulatory standards.

In conclusion, we remind our listeners that while Appian simplifies software development, navigating the complexities of regulatory compliance requires a strategic approach. It is essential to foster collaboration between development teams and compliance officers, ensuring that all parties are aligned on the requirements and expectations. By doing so, organizations can successfully leverage Appian to create innovative solutions while remaining compliant with the necessary regulations. This episode serves as a valuable resource for Appian professionals looking to understand the intricacies of working in highly regulated environments and offers practical insights for navigating these challenges effectively.

Episode 24: Illusion of Control

Welcome to Appian Rocks, the podcast for Appian professionals. Today’s episode delves into the “illusion of control,” a cognitive bias where people overestimate their ability to influence events, even when their control is limited. This concept is particularly relevant in Appian, a business process management platform designed to automate many tasks traditionally handled by humans.

The hosts, Marcel and Sandro, introduce the episode by explaining how people naturally desire to control their environment, often believing they can control aspects even when they cannot. This overestimation can be seen in everyday examples like pressing a pedestrian button at a traffic light or monitoring a progress bar during a download.

In the realm of Appian, this illusion becomes significant because the platform streamlines and automates processes, often reducing direct human control. For instance, tasks might be routed automatically based on algorithms, which can lead to resistance from users accustomed to manual processes and direct intervention in their workflows.

Balancing this automation with an understanding of human psychology is crucial for creating a comfortable user experience. While automation is beneficial for efficiency, it can make users feel disconnected from the process, leading to distrust in the system. The challenge is to design Appian applications that retain a sense of control for users. This can be as simple as ensuring intuitive and visually appealing interfaces, making users feel engaged and at ease.

Stefan joins the conversation, providing practical examples like “Save” and “Refresh” buttons. Despite modern software’s capability to autosave and push updates in real time, users still look for these buttons because they offer a tangible sense of control. These design elements are crucial for user satisfaction, as they mimic the control users perceive they have.

Marcel illustrates the illusion of control with everyday software experiences. Progress bars during file downloads provide users with a sense of monitoring and involvement, even though they can’t influence the process. In video games or cloud-based applications, users often tweak settings or press save buttons frequently for the comfort of being in control.

The term “illusion of control” isn’t dismissive; it’s about respecting users’ psychological needs. Control is a profound need, and providing interfaces that accommodate this can enhance user experience and trust in the application. The conversation shifts to the implications for change management. Introducing new software that automates tasks can be daunting. Trust in the system is crucial, and maintaining elements that provide users a feeling of control can facilitate smoother transitions and greater acceptance.

Sandro raises a key point about distinguishing user requirements from the illusion of control. While users may express a need for control, often it’s a deeper requirement for trust and understanding of the process. Consultants and developers must listen carefully to discern whether the desire for control is a fundamental need or a manifestation of this cognitive bias.

The episode wraps up by reflecting on the necessity of balancing automation with user comfort. By integrating elements that cater to the illusion of control, designers can create more user-friendly and trustworthy applications. This approach not only respects user psychology but also aligns with the broader goals of digital transformation.

In conclusion, addressing the illusion of control in Appian development isn’t about manipulating users. It’s about creating applications that are both effective and psychologically comfortable, bridging the gap between efficient automation and user satisfaction. This nuanced understanding is key to fostering trust and adoption of new, automated processes in any organization.