Our process orchestration platform uses flexible combinations of generative AI, 300+ integrations, and over 2,000 trained experts as managed services to tackle your problems at any scale.
I joined Invisible as a product designer to help them primarily redesign their product. I also did some occasional brand design work.
Designs
DAL
The Digital Assembly Line, or DAL, was the operations facing platform that allowed operation managers and operators to view tasks that have been delegated by the client.
The DAL would look different depending on who was viewing it. Operators would probably see only a few task items. Operation managers would see many more since they were responsible for entire teams and specific task niches throughout the organization. Upper management would literally be able to see everything.
One could click into a task and get more information to act upon. Depending on who was viewing it they could do certain things. Some could only view it and see the step by step instructions only. Others could change the stage of it. Others could edit it.
Agent Dashboard
The agent dashboard allows Invisible's remote team of agent operators to see their schedule, performance score, skill set, amount earned, and tasks they could operate on in the task list.
Client Dashboard
We realised that clients, rather then sending their delegations in by email, could use a dashboard to write and submit designs from. That dashboard could also be used to view the costs per delegation, overall spend, billing history, and chat. There was also a place to change their plan and credit card information.
I designed it from scratch based on several account managers feedback from clients. It was meant to be a very intuitive a user friendly environment serving as a one stop shop for all of a clients needs. The idea was to limit the need for clients to have to delegate via zoom calls and emails. It was about cutting back on the UX friction and time to submitting a properly written and formatted delegation to the DAL.
Process Builder
We had seen that it was very important to start codifying the process of translating a client's delegation into a set of tasks and steps that could be easily understood and operated on by the remote operations team. The idea was to create a logical flow of steps, like a computer program, that could easily be followed by a human.
To facilitate this, I was tasked with designing a process builder sub-applications that would allow a human operator to come in, read the delegation, and translate it into a process by using the ap. They would drag step blocks into task blocks. Filling up each task block with the right order of steps. Logic could also be applied to the flow. Tasks were placed in the proper order and this created a process. Really delegations and processes were one in the same.
The longer term vision of process builder was that one day we would be able to create a massive dataset of processes and use machine learning to create agents that could execute these processes by following these logical programs of tasks and steps.
Insights
1. My AI Suggestion
While doing some extensive UX research with various members of Invisible's operations team, I learned about the various types and vast quantity of repetitive tasks that were being executed by them. I realised there was an opportunity that we could leverage the power of AI. I recalled in July of 2020 when Sharif Shameem used GPT3 to convert a text prompt into React code to build a basic website. Totally mind blowing.
So I thought that if that was possible, then surely there'd be a way to get AI to do some basic data entry tasks at the very least. I thought that maybe out of the box, GPT3 might not be able to do it, but that maybe if we created our own custom datasets and train our own model, then we'd have a chance.
My idea was to develop a background program that could live in a user's browser or OS that would just sit there recording the user executing their repetitive tasks. With that data, we would then be able to fine-tune the GPT3 DaVinci base model. It just made all the sense in the world, but there was push back on the idea.
I think at the time, I was not educated enough on AI to really make a sound argument for my case. I was basically seen by upper management to be reaching to high and was basically told to stay in my lane. Also, I can understand the decision to not go for it as it would require the hiring of at least 1-2 ML engineers and the tech was so early back then that it was not an obvious move. All that said, I still think it would've been possible. Also, I'll mention that Adept, a company started in 2017 by an ex-Open AI employee David Luan, have been employing the technique I just mentioned tor a few years now within enterprises like Workday.
2. Rush 'n' Squeeze
The variety of products I designed at Invisible varied greatly. From client side to operations side. I also designed some marketing materials also such as their deck, social assets, emails, and blog. While it was considered an early stage startup, it was probably the most mature one I'd been at so far. Their core engineering and operations teams were fairly developed and new people were coming onboard all the time.
While the scope was fascinating, I was in a startup run by highly ambitious team leads. It was always go go go. I felt the constant tension between the speed at which they wanted designs produced and the quality and thoroughness at which I wonted to produce them at. Because of this I could never develop a mature design system or provide interaction and design notes for the devs.
Funny enough, it was told to me by the CTO, Scott, that the job of design was to pushback against the rest of the organization. After he said that I tried to push back, but it didn't matter. I even had support from engineering because at some point front-end devs felt the bite of not having a consistent design and component system in place. So while we tried to get more time and space for thoughtful and thorough designs to be produced, ultimately we were suppressed. I mean, you can only push back so much until you become a nuisance and are let go. I didn't want to lose the job.
Conclusion
Working with Invisible taught me so much and I'm grateful for the experience. I realise that I am not suited for an environment whose focus is all about shipping fast without a fundamental design system in place. Look, I know startups are all about working fast, but it makes no sense when technical and design debt builds up over time. That eventually leads to an nonfunctional and unusable product. So it's all about moving wisely. Build a well functioning foundation first and continue to build everything on top of that.
So ultimately I've learned that I will only work with a company that understands the value and necessity of a wise and thoughtful design strategy. One that begins at the foundation and progresses through the fractal of complexity over time. That means executing the userflows first, low-fi wireframes second, the design system third and the hi-fidelity mockups (with thoroughly written dev notes) last. Of course user research comes into play but it can be debated how necessary that is. It really depends on the project.
So in conclusion, I can not be a part of a team that does not share this same understanding of how important it is to start of solidly because I know that it ultimately leads to many problems within the company and product downstream.