While exploring the design and experience for ActionEgine, we focused on how the agent will integrate into an engineer’s workflow intuitively. Rather that treating the agent as a standalone tool, we approached it as an extension of developer’s intent — something that acts in alignment with their goals rather than requiring explicit instructions.

Our design is driven in the Human-Agent Experience (HAX) principles — Clarity, Control, Recovery, Collaboration and Traceability. These principles emerged from studying how people interact with agentic systems — what works, where trust breaks down and how collaboration succeeds or fails in practice. Designing, guided by these principles led to adaptive interfaces that allow the agent to suggest actions, request confirmations or execute tasks in familiar workflow.

Here are a few examples illustrate how these principles shaped the agent’s behavior:

1. Observation while training the agent

As users train the agent by demonstrating tasks, the observation process unfolds directly within the conversational UI. Rather than relying on a separate panel, the interface integrates step-by-step updates into the flow of dialogue. This makes the agent’s leaning visible, editable and open to intervention.

Clarity through transparency: Each recorded step is shown with enough context to make the agent’s understanding legible and open to feedback. The panel helps users understand what the agent is learning, reducing ambiguity

Traceable learning path: Users can review the evolving workflow structure as it forms, ensuring each step is accurate and intentional

Collaboration: Training is a shared process, where the agent builds workflows not in isolation but in response to real user behavior.

2. Agents ask for help

When the agent encounters ambiguity during training, it doesn’t make assumptions — it asks for help. The example below shows how the agent pauses and asks user for clarification.

Control through clarification: Users can explain, correct, or guide the agent mid-training, ensuring the workflow reflects intentional, accurate logic.

Collaborative learning: When the agent gets stuck, it initiates a natural conversational prompt, treating the user as a partner rather than a passive source of data.

Recovery built in: If a misunderstanding occurs, users can easily revise or backtrack, ensuring that mistakes during training don’t accumulate or affect the final workflow

This interaction reinforces the agent’s role as a collaborative learner, where users remain in control and guide the agent toward a more accurate understanding of the task.

3. Workflow optimization: User-Driven adjustments before finalizing

Before automating a workflow, the agents ask user to review and modify the steps it has learned. This interaction ensures that the automation reflects not just what was agent observed and recorded, but what the user intends. In the example below, the agent presents a draft version of the workflow, and the user steps in to make a small but important adjustment.

Control over automation: Users remain the final authority, they can edit, delete, or reorder steps before the workflow is finalized.

Clarity of execution: The agent summarizes the learned workflow in a clear, structured format, making it easy for users to audit what’s about to be automated.

Collaborative refinement: The agent’s draft becomes a shared object that both user and agent can iterate on, transforming automation into a co-designed workflow.

With ActionEngine our goal is to design an agentic system that automates workflows with Human-in-the-Loop. The agent works collaboratively with users to perform tasks — keeping the process visible, asking for help when uncertain, and allowing users to intervene, correct, and refine steps as needed. This ensures that automation remains transparent, controllable, and aligned with human intent.

As a designer for the low-code app at GEP — Quantum Studio, I have been deeply involved in its creation and evolution from inception to its current scaled-up state. Quantum Studio stands out because it is specifically designed for creating Supply Chain & Procurement apps, used by both developers and admin teams. Designing a tool for users with varied skill sets and requirements has been challenging, yet insightful, leading to several important lessons. I share a few key ones here.

1. Understanding the Impact of Legacy Architecture
   The GEP technical architecture significantly influenced the design of our low-code studio. We had to cater to users with varying technical expertise — developers, admin users, and citizen developers. Continuous communication with all user groups was essential to understand their unique needs and challenges. Given the learning curve associated with such tools, it was vital to provide intuitive interfaces and ample support. Regular user engagement helped us refine our approach, ensuring the platform was both powerful and accessible.
2. The Importance of Collaborating with Engineers
   From the outset, close collaboration with engineers was crucial. This partnership allowed us to identify technical constraints early and design with those limitations in mind. Many of our engineers also used the platform, offering valuable feedback from a user’s perspective. This dual role provided deep insights into performance, scalability, and usability, ensuring our solutions were robust and user-friendly.
3. Embracing a Scalable, Research-Driven Approach
   Our research-guided approach prioritized critical problem areas and defined a clear roadmap. Initially, the tool was overly focused on developers, limiting usability for non-technical admin users. Through comprehensive research, we realized the importance of catering to both technical and non-technical users. This led to adding features intuitive for admins while still powerful for developers. Continuous user feedback and usability tests refined our design, ensuring it met the diverse requirements of all user groups.
4. Fostering a Culture of Continuous Improvement
   Finally, fostering a culture of continuous improvement was crucial. We encouraged regular feedback and maintained an iterative design process. This culture ensured that the platform evolved with user needs and technological advancements, maintaining its relevance and effectiveness.

Conclusion

These learnings have been instrumental in creating a low-code platform that empowers developers, simplifies management for admins, and enables citizen developers to innovate with ease. Reflecting on this journey, it is evident that understanding user needs, close collaboration with engineers, a focus on scalability, balancing customization and standardization, robust user support, and a culture of continuous improvement are key to designing successful applications.

I got the opportunity to work on two of the most interesting projects, one was redesigning The Met website for accessibility and the second was designing a multi-modal tool called Craft, to enable people with limited mobility in arms to create art in Virtual Reality.

What is inclusive design? Inclusive design embraces diversity to create experiences and find solutions , making a product useful to many more people including the disabled community.

Here are some of the things I learnt while designing for inclusivity —

Inclusive design includes most people — The Microsoft Inclusive design toolkit defines it perfectly — solve for one, extend to many. Inclusive design is about involving as many people as possible in the solution you have designed. For Craft, we had decided to solve for people with limited mobility in their arms, currently very few accessible VR solutions exist. Our idea was to use eye gestures and voice commands to draw in VR for people who were unable to use the hand controllers. Currently all existing tools like Tilt Brush, Blocks, Quill, Medium, all require the use hand controllers.

We tested our solution with people who were designers with no disabilities and people with disabilities. The response we got was very different from what we expected — most users gave us the feedback that a multi modal tool would make it easier and quicker to draw in VR. Our assumption here was people who could use controllers would find it hard to use eye gestures and voice to draw.

Small things make a big difference — While redesigning the Met Museum website for people with visual imparities I spoke to a user with low vision. When I asked him to describe his experience with his favorite websites, he picked Facebook. What he told completely took me by surprise, according to him whenever he got a notification about someone commenting on Facebook post, he went to the post, took a screenshot of the post, went to his gallery, zoomed in the picture to read what the comment was. This is how complicated something so simple had become for a person with visual impairment.

Another common issue that people with visual imparities cited with Facebook was, how the company’s AI worked to give images absurd and meaningless alternate text, which when read by the screen reader gives little information. For example an image of my friend John visiting beach in Miami would be described as a Man on a beach with blue skies. This issue requires a solution that fixes the AI for alternate text for images, I wonder why it is hard for Facebook when their AI can auto-detect and ask you to tag users in pictures.

Lowering the barriers — An important part of the design process is understanding the user and what they need. Great design makes a product accessible and easy to use for its users. Inclusion means a lot of different things to different people, but evaluating barriers and removing them to include more people is what makes a product extraordinary. The key here is to identify exclusions and find a solution for them. For example — how can we make Virtual and Augmented Reality accessible for people with visual impairment? Again quoting Microsoft toolkit — “experiences are rooted in interaction with people and objects in the world around us. Seeing disability differently and understanding exclusion helps us extend a solution for one person into a solution for millions of people.”

The true essence of design is in designing for all, keeping in mind the need you are creating a solution for.

Based on our past findings, we realized the methods used by us previously had some limitations. These limitations included not being able to track the usage of machines, the time people spent in the space and what exactly they were doing if they were not using the machines. The research found that a lot of people spent a lot of time in the MakerSpace to study, meet teams and work on class projects. There was also some behavior research could not capture, since the researchers could not be present at the MakerSpace throughout the day. It is then we found out about a Parisian Fablab that built an interactive tool called Cairn to study interactions. Cairn is an interactive apparatus that enables data collection, visualization and analysis.

Originally, a cairn is a human-made pile (or stack) of stones. It comes from the Scottish Gaelic: càrn (plural càirn). They have been used for variety of purposes, from prehistoric times to the present. In modern times, cairns are often erected as landmarks. We decided to introduce Cairn at the New York University MakerSpace to track data and usage, while making it fun and interactive for the visitors. The table was not only a good tool to collect data but a was complying strongly with the ethos of the NYU MakerSpace of collaborative community and making things.

The Cairn we built - shown in the picture below - is actually a board game like table, on which visitors create their own Cairn based on what they are doing at the MakerSpace and how much time they spend in the space.

The design of the table underwent several iterations. To make the table more intuitive we decided to laser cut it in the shape of the floor plan of the space. We sketched it out on paper before building the actual prototype.

Apart from deciding on the shape of the table it was necessary for us to decide on the data that we wanted to record and based. From our previous research and keeping its limitations in mind we had some ideas on what we wanted to track and that helped us come up with the categories we wanted to add for the Cairn pieces.

Here is how visitors create their own CAIRN in a simple way by taking one small rod and piling pieces that describe their activity on that particular day. Then they place their Cairn on the table in the area where they worked along the line that describes the number of hours spent.

Currently we are in the process of laser cutting the final version of the table and coming up with methods to analyze data. I will be writing more posts in this series — one to explain how the table was prototyped and iterated, second on how we are going to record and analyze data.

Her posters provoke you to think and expose the injustice worldwide. Luba’s posters finely reflect on the human behaviour, hypocrisy and injustice. Something that really struck me were her series of posters on women inequality. Luba designed these posters when one of her Iranian followers asked her to address the issue of women rights in Muslim world. In this series she created images which showed how the everyday situations are different for men and women. The artist stayed away from the image used in western feminist posters, depicting women fighting for equality. I am sharing pictures from this particular series -

Another design called — Sudan, was designed by her when she watched a documentary about the impoverished country. Right after the documentary there was a commercial break promoting low calorie food. This made Luba design the poster below, throwing light on the striking contrast -

Another one depicting income gap -

Lukova’s powerful and brilliant posters are minimalistic but highlight the critical social justice issues that currently dominate us, including health care, women’s rights, LGBT rights, immigration, corruption and gentrification.

Check out more of her work here and here.

Almost 2 years into working on software products, here is the most important lesson I have learnt:

Do not blame people when they fail to use your product properly

What we call an error could be bad communication and interaction — There is always a reason why the user is reacting to your product in a certain manner.

Introspect, talk to users, test and figure out what could be the reason of the error. This is a simple formula we use at SHEROES, deep diving into problems users face. Here is an example:

86% of our users reported that they never received a response to the jobs that they were applying to. Now, this is clearly a problem arising because of lack of communication from a company’s end. But to think of it — the user reported this issue because they expected a reply. Why did they expect this reply? They were making an effort in filling their profile and applying to jobs.

Nowhere did the product communicate to them that they will receive a reply only if their profile is shortlisted or liked by a company. On the other hand, companies aren’t obliged to respond to the candidates who aren’t suitable.

The result — lack of replies from companies frustrated users looking for jobs and question the platform’s credibility.

Simple fix — A notification to the user when they applied, they will hear from the company only if their profile is relevant. And giving an option to companies to shortlist or reject application. While this is a very ad-hoc solution and we are experimenting with better ways to improve the interaction and communication for this particular solution.

Difficulties people face are signifiers of where you can improve. What might seem like a simple task to a developer or designer, can be a cumbersome task to perform for the user. Another example from SHEROES –

We designed a system to upload events in our backend. Everytime someone uploaded an event, they got confused and lost. The developers assumed it was fairly simple and easy to navigate. We designed it according to what we thought was the correct method whereas it was not a simple to use system for the users. Based on feedback from everyone, it was concluded, what we had earlier accomplished in five screens was possible in one.

Interaction between product and a person can be a collaboration. Machines are machines and human are humans. But behind machines there are humans — if building a product think human not machine. A small example — replace error messages and warnings with help text. Error and warnings can put down the user. Build a product that understands your user and not the other way round.

While this is something we are working on at SHEROES and still feel we are far from building a product that fully understands our user. But the only way to get there is — research your user.

Got any thoughts on how we can get better? Leave a comment below.

The overnight journey was comfortable and we mostly slept through it, waking up to a freshly bathed mountain, a cloudy and beautiful Mcleodganj welcomed us. The Himalayan glory was at its best, we were a beaming happy group of three girls looking forward to the trek. The idea was to trek and camp overnight at Triund overlooking the Dhauladhar range.

It seemed like a perfect getaway, until…we met our guide for the trek and it started raining. Not raining exactly, there was a hailstorm and this is what the street in Mcleodganj looked like:

We decided to wait for the rain to stop, it is never a good idea to trek on a slippery mountain. On the guide’s advice we entered a random café, which had a very homely warmth to it. And believe me or not — we had the best honey, lemon and ginger tea there. It is a pity; I have no recollection of what the place was called. They had amazing Tibetan bread, omelettes, lemon and curd cheese cake to satiate our hungry souls.

The guide was a little bemused at the sight of three grown people acting like kids. He suggested we carry some rum since it was going to be cold, wear tons of clothes and take rain coats to save ourselves from rain. To our surprise Triund was still covered in snow — that is something we weren’t expecting in the middle of March.

Meanwhile it stopped raining and by 12 noon we were on our way to the starting point of the trek. This was the first view of the Dhauladhar range from the starting point:

Four hours long, the trek had breath-taking views, the beginning was easy and seemed more like a hike. Most of the first half we engaged in conversations with our guide, who spoke about his treks and experiences in the mountains. Here are glimpses of the trek:

Half way through, we were exhausted and needed a break, I blame my bad cold and blocked ENT to being tired. Fortunately, we stopped at what they call the magic view point for food and hot tea. Just when we were about to head uphill, it began to rain again and the raincoats came to our rescue.

The guide told us, rest of the trek was going to be harder and there would be snow towards the end. The idea of wading through snow seemed fascinating and a little scary at the same time. Scary because, the guide explained we could be victims of what they call the Photostat. If one falls or skids through the snow, their complete imprint is left on the snow, and the local guides fancy calling it Photostat.

As we neared the end, it did get a little hard, there were times when we slipped but fortunately the most dreaded Photostat didn’t happen. Our socks and shoes were all soaked and our feet were freezing. Here is a small tip — wear proper trekking shoes and not jogging shoes. The trek had been rocky and snowy, and we were running out of patience.

When you have no expectations, and no clue of what awaits you and the nature throws a beautiful surprise at you — life can’t get better. That is what exactly happened when we finished our trek. I fall short of words to explain the serenity and beauty of that place. The view of the Dhauladhar range is spectacular and you tend to forget the arduous walk looking at it. I’ll let the pictures do the talking:

We spent most of the evening, walking around in the snow, exploring and enjoying the sunset, we fortunately got to live in this tiny little cottage with no electricity supply or basic amenities. That can be a little overwhelming for three Delhi girls out for an adventure. The thought of spending the night in a cottage under stars and around snow-capped mountains made us forgot everything else. The place gave us city dwellers immense relief, we got the peace we were looking for, away from madness we are used to.

The guide arranged for some hot food and Maggi, which came as a relief in the cold, windy night. We snuggled in our blankets and fell asleep after some random conversations.

The next morning the snow had become ice and we intended to leave by 10:00 AM, the walk downhill was going to be quicker and we had more company. A group of Bangalore boys joined us on our way back. By 12 noon we were back to Mcleodganj, hungry, yet again. We entered a café called — Carpe Diem, which served good food.

The thing about Mcleodganj is, you will find good cafes and warm people everywhere. It is a traveller’s paradise, that leaves you with a feeling of going back. You miss being under the stars, and the peace that prevails. Even the freezing feet and wet shoes seem like a privilege right now.

That evening we were on our way to Delhi after an enriching trip and hoping for many more to come.