My name is
Toshit Panigrahi.

Professionally, I have been called a Programmer, UI & UX Developer, and Product Manager.

Between you and me, I love taking an intangible idea and making it a reality - in the process, crafting an enjoyable product for all of us to use.

What I've Been Up To

   July 2013    July 2014    July 2015    July 2016


Parallel Wireless











Boston University Computer Science & Business

I specialize in designing and revamping interfaces for enterprise-scale web apps that usually have established backend architectures. All my front end work is done in HTML/CSS/JS, and I work closely with development teams to integrate it with the backend stack.

I get my hands dirty in code when necessary, and am intensely involved with the coding in my projects. Python, Javascript, PHP, and SQL are my strong suits (my Java is a bit rusty).

Creator of

Botler is a chat bot platform which helps make bots useful and accessible - for both developers and users! The platform is built to allow developers of all coding levels the ability create a bot using any language they want (deployed on their stack) and get analytics on it. For users, Botler strives to provide one of the best bot experiences you can find and takes bots from a novelty to a tool that is actually useful.

I am immensely interested in chat bots and I believe there is a value they provide which can enhance interaction with digital products. After studying the bot ecosystem, I realized most bots were a mere novelty and people did not understand their value. So I started working on Botler in April 2016 to help developers and users understand the value of bots.

So far, I am the only person building Botler, and have taken it from idea to design to code. Botler has had one enterprise deployment, with talks for more underway.

Finalizing the Idea

I got the idea for Botler towards the end of March 2016, and immediately began looking at what the ecosystem for bots was like. The bot trend was picking up and predictions were being made for bots (claims as bold as that bots would replace apps).

After studying chat bots and the current platforms, I realized bots could not completely replace apps; the UX of a web or native app is so nice that chat bots are not optimal for certain actions. However, I believe that bots have immense value to provide. To understand how to harness this, I looked to the history of apps.

Most bots out there today are like the very first apps (e.g. the apps that turned your screen into a strobe light or displayed a compass). These apps were cool toys but not practically useful. Apps succeeded because they could provide a new form of interaction which websites could not provide. So for bots to succeed, we must learn to identify what bots can do that apps and websites cannot. Bots should not dismantle the app, but should provide a new mode of interaction to augment the product experience. I also wanted to expand the realm of bot building far beyond a few niche developers to almost anyone who could code. I detail this further in the Botler documentation; it is called the Botler Method.

Designing the Botler Front End

Once I knew what I wanted to build, I began designing the interfaces. I build the interfaces out in HTML/CSS/JS so that I can immediately use the final design as I start backend work. The UX had to be great because most people have never used a chat bot; I wanted to leave a good first impression so people would trust the bots on Botler (it is my duty to developers who will deploy bots on it).

The v1 of Botler had to do the following things really well:

- Talking to a bot
- Discovering bots
- Building a bot
- Analytics on your bot

Above is the home page after signing in. The main interaction is talking to bots, so it is the central element in the IA. On the left side are user centric functions, which is why bots that the user created are listed there, as well as the CTA to build a bot. On the right sidebar is the button to discover more bots.

Discovering Bots - the Botler Market

The Botler Market was critical because it was what let users find bots that they would love. It had to be inviting to users and I realized that the market is a product in its own right (in fact, many startups simply aim to provide a bot market). The Botler Market had to inspire developers so that they would be proud to have their bot listed here.

At the top, I wanted users to see the featured bots. These are personally chosen bots which I felt provided a unique value or someone took extra care to build.

In addition to showing listings of bots, which every bot market does, Botler could do something others could not. I wanted users - whether or not they had an account - to immediately interact with a bot on the market. They could immediately decide whether they liked a bot or not. Users should not need to text a separate number, log in elsewhere, etc. like they do on other bot markets which simply aggregate bots from every platform.

Here is an immediate interaction with the @Stocks bot on the Botler Market. A panel slides in and a user can interact with the bot right away! I wanted the design to feel subconsciously familiar, and so I made the overlay in the theme of the Netflix pause screen when you leave a show paused for a few seconds. (I remember the first time I saw the Netflix overlay I thought it was a really elegant design.)

Building Bots on Botler

The other core facet of Botler is building a bot. Because I wanted to expand the scope of developers who made bots, Botler had to be extremely developer friendly. Developers can use any language they want and any API's they want, because bot logic is deployed on the developer's own server!

Botler is unique because it is basically a query routing platform. When a query to a bot registered on Botler arrives, Botler simply routes it via GET to the endpoint specified by the bot creator (which is their own server/domain). Botler can receive user queries online or through SMS on the Botler number. This means users can get information even without Internet access.

The bot creator only has to worry about the coding of bot logic. They do not have to think about SMS gateways and the entire architecture to support a bot. This makes bot development significantly easier and allows for greater security since the bot logic and user query processing happens on the developer's server, thus achieving the goal of appealing to a wider audience of developers.

To reach even more potential bot creators, Botler allows users who cannot program to create simple bots. Users can register a bot handle, and specify key value pairs so that when a user messages the bot with that keyword, a preset string is returned.

Because most people will never have created a bot in this manner, the UI shows a card on the right side which visually demonstrates to the bot maker what it means to provide a keyword and a response. This card updates live as the user builds the simple bot.

Bot Analytics

I felt bot creators should be able to see that their bots are being used (or not used) and they should be able to see how users interact with their bot.

For bots that users chose to program (called Service Bots), I allowed the bot creator to see all the queries users submitted to their bot. For simple bots (called Data Bots), I showed how the hits to the bot broke down across the different keywords. For both types of bots, I showed the hits by day and the SMS vs Internet hits to the bot. (For graphs, I used Chart.js which is awesome!)

This page also allowed the bot creator to edit the bot responses, or change the endpoint. On the right side, I built a message testing area which lets the bot maker message the bot to test out the bot's behavior.

Botler Documentation

In order to help developers understand Botler and why they should register their bots on it, I realized I had to write up the documentation. I needed to tell developers the exact parameters I passed and give them inspiration on things they could do with Botler. You can check out the more technical Service Bot documentation, if you would like.

This is the first time I built a public API myself and also the first time I had to write documentation.

Soon I realized that simply providing technical documentation was not enough. The power of the Botler platform was that any bot could be reached on Botler's number or on the site. There needed to be a way to standardize these interactions, and provide best practices for bot makers to follow. So I also put together a UX style guide made specifically for bots.


Product Development at

Toast is an all-in-one point of sale and restaurant management system. Built specifically for restaurants on an affordable cloud-based platform, Toast offers the power, flexibility, and ease of use a foodservice business needs.

This was my second time at Toast. I work in the intersection of product management, engineering, UX, doing some of each. At times I work with the product team to rank features or decide the value of resource investment. Some times I have to code to build features myself and deploy them. Other times I have to deliver the HTML for a product UI and keep in mind the overarching product goals as I design.

Toast Online Ordering (Revisited)

My second time around at Toast, I got to redesign Toast Online Ordering once again. The original design I had delivered over a year ago had been implemented and we got a lot of feedback from our customers. The goal of this second redesign was to incorporate this feedback, and provide additional UI allowance for features we added to the roadmap.

The biggest request by customers was for additional branding opportunities. This meant more space for the restaurant's pictures and more prominent logos. Some customers even wanted to be able to choose colors. In addition to the customer voice, I was filled in on the engineering limitations we had which had to be accounted for in a redesign because the last redesign was causing bugs.

When I started working on this redesign of the online ordering platform, I had to take both of these requirements into account. It was up to me to deliver a design which eliminated the engineering problems, and was able to allow for enhanced branding.

The allowance for branding was tricky; customers could upload any picture they wanted, they may not upload a picture, the picture may be blurry, etc. I had to figure out a way to allow customers to upload anything they wanted, yet the design had to be pleasant even in the worst cases.

In this new design, customers could upload a big cover picture for the date selection modal. Even if this picture was blurry, the modal would disappear quickly, and the user would not see it anymore. The new design also allowed restaurant owners to upload a picture at the top of their menus. Upon scrolling, a CSS blur filter made rendered the image slowly out of focus, guiding the user to what was important - the menu. One of the main features we needed the design to allow for was saved user accounts. The UI had to be lightweight to implement quickly and consistent with the rest of the online ordering site redesign.

All of the screens you see here are screenshots of the actual functioning HTML pages I delivered - not photoshop renderings.

The Nightly Email for Managers

The nightly email is a summary of how the restaurant did that day - containing some critical information - which is sent to all the restaurant's managers every night.

The problem was that every time customers requested more info on the nightly email, the new rows were simply tacked on to the end of the email or new columns were made. This practice, of course, did not scale and it had reached the point were the email was massive and cumbersome to read.

I took up the task of redesigning the nightly email. We were on a time crunch - the sprint ended in a week. I had to learn how the email was constructed, rework the HTML and styling, make it compatible across email clients and browsers, and then work with an engineer to push it into staging.

This was one of my favorite projects because of all the limitations I faced; this email had to be constructed using simple HTML tables, inline styling, no javascript, no external stylesheets, and there were compatibility issues to fix and a shortage of time.

Despite the challenges, I wanted to make it look absolutely gorgeous - there was no reason for it not to be. The most important pieces of information were moved to the top and were the most important in the hierarchy. The tables were grouped by related data points, and I shifted the whole email aesthetic towards a style more consistent with the rest of the platform.

Toast Training Wizard

Occasionally, I would help some of the folks in marketing and do some custom HTML/CSS work on Hubspot. This involved tweaking the Toast homepage, and other small cosmetic changes and maintenance. I also found out we used Hubspot not only for the marketing website, but also to host our training guides and documentation.

One day, another product manager approached me and asked if I could redo some of the Toast Inventory product documentation, because customers were getting confused trying to set it up. I began by reviewing the product and its functions, and then went through some of the current documentation it had, which was hosted on Hubspot.

The guide was enormous and daunting at first glance. This dissuaded customers from trying to learn the product and getting in the habit of using it. I felt it was a strategic product decision to spend a good part of two weeks on completely reimagining this documentation; I wanted to make it interactive and easy to digest. The returns would be justified because it seemed the documentation was what customers got hung up on, and fixing it should help this product gain momentum.

I spent a day or two getting to intimately know exactly how Hubspot was engineered on the front end, and then I worked around it to build a completely custom interface. I overrode default CSS (and had to make sure it did not affect any other page on the site) and built one master template from which anyone could build documentation without coding.

I took the point-and-type capabilities Hubspot provided, and after I figured out how their Javascript worked, I made it target elements on the template I built so that a document-creator could take the template and fill in the title and paragraphs without touching the HTML.

At the heart of this template was a piece of custom Javascript I inserted which worked around the native behavior and could do some pretty amazing things; it could hide steps which were blank, select the appropriate section from the sidebar, dynamically update DOM based on the guide's contents (e.g. video or stp instructions), and automatically style tables.

One of the biggest features I was able to build into it was an iframe which loaded the Toast manager login. This could be opened by clicking the arrow on the right, and the manager could sign in and follow along right there, without switching tabs or windows. You can see a documentation page here.

The documentation I delivered was extremely well received. And is now being used in the main Toast Training Center to guide people on all Toast features.

Just something interesting I wanted to share, below are all the iterations of the left sidebar used to select a step. By looking at these side by side, it reveals the thought process as the design evolved. It shows how the design of the sidebar changed as I played around with the contrast of elements, increased and decreased padding, played with the font weights to make sure it was just right.

Product Manager & UI/UX at

Cintell is a marketing tech startup. We work to help marketers understand their customers better by enabling them to create customer personas in the Cloud and share them within the company.

My primary responsibility is to take a high-level product requirements, then define features, design the product UI, and work with development teams to build the product according to specifications in a high-pace startup environment.

The Public Persona View

Marketing departments can use Cintell's cloud platform to build and share buyer personas. One of the first things I did at Cintell was redesign the persona view that could be publicly shared. This was an exciting starting point because it laid the groundwork for revamping other parts of the platform moving forward to make the experience of creating a persona more engaging.

The backend functionality already existed, and we didn't want to lose any functionality with the redesign. One of the challenges was displaying all the possible data types and letting the design scale to accomodate any number of attributes and sections. Information had to be easy to find and the site had to be responsive because many users who accessed the finished personas were likely to be on the go.

Currently, personas are printed out on PDF's. To maintain familiarty, I made the main persona and data grouped as one unit that resembled a sheet of paper, allowing sections room to grow and reorganize as more data was added (a purely CSS solution to increase robustness). The meta-level functionality was moved to a separate side pane, which allowed for a nice translation on the mobile version.

After the design was finished, I worked with the development team to implement the new design, crush bugs, and make various adjustments so that we could roll it out within three weeks.

The Interview Guide

Next, I was in charge of designing and defining the functionality of a new core product called the Primary Research module which allows marketers to gather intelligence about customers that is accessible company-wide.

Based on the intitial high-level requirements about the product and its value proposition, I had to design the product and craft the total experience that would please the end user.

Four distinct pages needed to be made: the Guide Listing page, the Guide Creation page, a page for viewing responses, and a page for recording responses. When designing each step, I had to predict what the user would likely want to do on the page, and how to set it up intuitively to help them interact with it.

Below is the Guide Listing page, which shows the user all of their Interview Guides. On this page it had to be easy to find a particular guide. One way to aid this was to allow tools for filtering and searching. A user might also want quick info about a guide, and in that case it would help to provided quick meta-data about the guide so that they wouldn't need to open the guide up to view that information.

The information hierarchy of the page becomes apparent with just a quick glance, and the design helps reiterate this by guiding your eyes from left to right, even as you scroll down on the page. The left column hold the functions which affect all of the guides, such as sorting. In each Guide section, the left half contains the main info about the Guide, while the right half contains meta-data, such as the number of question, answers, the tags, etc.

The experience of creating an Interview Guide had to be straightforward, to allow a user to come in and create one with little friction. I wanted to be able to guide a user through the creation process. One way was to set up the steps for creation linearly so that the user would work through the page from top to bottom (as opposed to, for example, setting up tags/attached personas on a side panel).

On the Guide Listing page, the title, description, tags, and attached personas were used to help the user figure out which Guide they were looking at. To reinforce the idea that these elements are crucial information, we chunk this information together during the Guide creation process.

When the user arrives at a question input, it may be hard to come up with a question. A person who is new to this may not even know what kinds of questions are the right ones to ask. To reduce the user's stress of coming up with questions and make the process easier, my solution was a suggestion box which helps a user come up with questions.

When the question input is empty, the suggestion box gives some ideas for questions to ask. In future iterations, it allows the suggestion box to become "smarter," with more categories to choose from when the question input field is empty.

However, once users start typing, we can assume that they have some idea about what they want to ask. The suggestion box now offers autocomplete suggestions from a database of questions. Further, it also searches the other Interview Guides associated with the account to find similar questions that were asked before.

Once the user finishes the question input (either by selecting an option from the suggestion box or by typing in a question mark), they are given the option of saving and publishing, or adding another question.

User Experience & Development at

Toast is an all-in-one point of sale and restaurant management system. Built specifically for restaurants on an affordable cloud-based platform, Toast offers the power, flexibility, and ease of use a foodservice business needs.

I was responsible for the redesign of the Toast Online Ordering platform. In order to do so, I had to study the current version in order to understand how information was relayed to the server and had to design an experience and interface that would minimize the backend rework.

Toast Online Ordering

The backend architecture for online ordering already existed, but it needed a front end revamp to make it a nicer experience. One of the first things I had to do was study the backend data structures and flows before I designed anything so that the new design would work with most of the existing architecture. It also helped inform me about what info about the menu and items was readily accessible and what info would cost significant server time to fetch.

I wanted to give the page a distinct and recognizable form that set it apart from other online ordering platforms. The order summary let people customize their order, letting them choose between pickup or delivery, and set future orders and times. I wanted to make it really clear to users what time their order would be ready from the time they place the order.

One of the major challenges with the online ordering design was designing for all of the modifiers associated with items and accommodating for edge cases. Modifiers had many different types, and some could have subgroups to select from.

Having a pleasant mobile experience was important because across other online ordering platforms, a large portion of users ordered from their phones. The online ordering page was designed so that the page could be optimized for mobile browsers using responsive CSS.

One of the interesting ideas that came up within the team was to let restaurants choose from a selection of themes in the future. We could even take it a step further and come up with a custom theme that preserved the branding of the client, such as below. The key to this feature was that we would simply load a separate custom CSS, and would not need to change any of the backend output.

This was an insightful experiment because it abstracted the Toast Online Ordering beyond superficial design to its IA form factor. Even when using another brand's theme, a user who was shown the ordering platform would instantly recognize the setup as the Toast platform if they have come across it before.

Cofounder of

MAHI is a text-to-knowledge engine that allows developers to create smarter applications. MAHI augments human intelligence by identifying topics in any type of text and makes intelligent decisions about the subject to display information and gathers other topics that are relevant.

After I had an initial idea of a conversation enhancer, I convinced my friend Martin Zhu to help me co-create it. I was in charge of the product direction, front end development, algorithm design, and worked on about 40% of the backend Python. Martin was in charge of backend stack, optimization/efficiency, API integrations, databasing, and about 60% of the Python codebase.

The MAHI Engine

When we first started work on MAHI, we thought we were going to build a system that listened to conversations in a meeting or support call and was able to pull up relevant data. After we had a prototype, we realized the true value of MAHI was the text-to-knowledge engine. If we were able to open up this engine to other developers, they could use it to develop applications for it that we would not have thought of.

So we decided to focus our efforts on making the MAHI engine more robust to accomodate text from any source and remove the dependence on punctuation. Then, we created an application which was similar to a conversation enhancer in order to demonstrate how an outside developer could use the engine to extract knowledge from a source text, examine the topic webs, and then integrate with other services, or other parts of their algorithm, based on what they are building.

The UI for the demo application was fairly straightforward. All the way at the left it had control to start/stop the microphone which listened to your conversation. One of the cool things about MAHI was that it picked up on the subtle topics and topic shifts in a piece of text, and it could come up with related topics for it. In the demo application, we wanted to bring background information about the main topics in your conversation and be able to give the user a feel of what it's like to interact with this web of knowledge. To allow this and, more importantly, still be usable, the UI is split up into three distinct columns.

In the left side, the column constantly updates as you talk with topics that are coming up in your conversation. You can click on one of them to explore it further. What this becomes is a sort of timeline that you can scroll to see what has been said so far.

In the middle section, you are presented with the background info that was gathered for a selected topic. By putting it all in a column, it made it easier to scroll through and find information quickly.

In the right section, you had topics related to the selected one which you may want to read more about, as well as outward links to the news sites covering it.

With this layout of information, I was trying to create a gradient, a subtle tree, of how the information related to a conversation. At the very left were things that were the most concrete - things that were mentioned or alluded to. In the center, there was information more generally about a selected topic. And moving further to the right we have information that is another step removed from the concrete topic. You can read more about the technical aspects at the MAHI site.

Creator of

Enjoin was an anonymous, location-based social network that connected you with those around you. It was a mobile website that used the HTML 5 geolocation API to load a user's location. Because it was a website, it could be accessed by any smartphone OS and had to be compatible across browsers.

It wasn't always an anonymous social network. I had the Enjoin domain for about 8 months at that point, and used it as the name of all the ideas I tried in that time. This was the fourth iteration after the first three didn't work out - but each iteration had sharpened my skills, taught me more, and made it possible to make the final iteration of Enjoin.

The Anonymous Social Plaza

After the idea first occured to me in March 2014, I set out to develop it as fast as I could. I wanted to put to use the skills I had gained over the past year in web app development. It took me a few days to complete the UI for every page in HTML, and after that was completed I moved on to the backend work.

This was very unusual because normally the backend work is done first, but because this was a mobile website and not a native app, I wanted to spend a lot of time creating the best possible experience given the restrictions of the platform. With the HTML template, I also knew exactly what data I wanted to collect and display, and could structure my database tables accordingly.

It took me about a day to finalize the logic for loading posts near a user (above is an actual page from my notes), accounting for the maximum distance-to-load and accuracy of both the previously posted content and the current user location. The user coordinates from the front end browser were passed to the server using AJAX, and the algorithms that ran on the server were written in PHP. Once the appropriate posts were loaded, the frontend UI was dynamically updated the content using a successful AJAX response.

The response to the site was amazing, and it was active for a total of 36 days before I took it down for personal reasons that I elaborate over here. The process of creating Enjoin taught me a lot - both about web app development and about myself. It was also what I considered my first well designed product, not only in appearance but also in code. And finally, it was what kicked off my information architecture influenced design process that I use in enterprise web apps.

Developed in

25 days

Then generated over

80,000 hits

In just

36 days