So to understand this project a little bit, I have to explain that our Management Console is used to organize and run the various locations our clients might have. Mainly, our clients are in the restaurant business. The Management Console is tied to the POS (point of sale). You can set schedules, inventory, manage products, build menu’s etc.

With this Yext page we would be creating, our users would be able to define and manage their business information (hours, dining type, social media accounts etc) in one location. From there, Yext would propagate that out to the more than 100 platforms in their network, thus creating consistent search results for our clients, improving their SEO and online presence.

By leveraging a third-party provider who’s an industry leader in search, Revel benefits by tapping into their entire slew of offerings and abstract ourselves from having to understand and build individual point to point integrations. This saves us valuable development time while increasing our potential feature offering.

One of the design parameters for this project was to create a seamless experience for our end users. We wanted the user to feel like this was another tool or feature within our MC and not some iframe to 3rd party service.

In order to do so, we had to strategize the best place to build this in our existing product so that the experience for our users made sense and fostered easy product adoption. After better understanding the Product Requirements, we both got to work on some ideas.

Yext has hundreds of possible fields to fill out. We first had to identify which fields were relevant to our users and how that differed from what is already defined in our Management Console.

After a few team meetings, we decided to make this a stand alone, one page design.

Because of this, we opted to bypass the lo-fi design phase. Our team had created a Sketch Library called Revel UI, which was basically a child theme of Material UI but with a few modifications. This allowed us to quickly mock-up hi-def designs. With that, we already had the text field, inputs, drop downs etc defined, it was just a matter of putting the right components in the right order.

One example of that, as seen above, would be how the user would set and define their categories. The first attempt was using one of the standard drop down components.

The problem with this approach, was that the drop down would be a very long list of options; hundreds in fact.

So we tried something else.

We instead opted to use the auto populate search feature that was newly added to our Revel UI Library. This component was originally designed for selecting a location on our revamping of the Online Ordering project.

Checking with the developers, they were able to test that we could pull in the categories data from the Yext API. So now, the user could just begin typing the category they wanted to instead of scrolling through hundreds of options in a drop down.

Another area we had to have a few side discussions with was how the user would define their business hours.

So the deciding factor for this component was that we actually had not one, but two other on going projects that also required this same hours selector component. Keeping with our number of sprints available to us on this project as well as keeping the budget down, we opted with the first design since it had already been agreed upon and pointed by developers on another team.

It was not my first choice design wise, but it fit the acceptance criteria and we knew we could revisit this component in a later sprint.

For new components like this, our team liked to provide a “Design Analysis” for the developers. It was an overview of what components were pre-existing and what components were going to have to be built and added to our Library.

There were a handful of other small design and development problems we had to solve before this was able to move to development. For example, we tried to pull in information that might have already been defined elsewhere from the Management Console like the Business Hours and have it auto populate this page.

On another page, separate from this, the user could set their hours and in some cases, could have two open and closed hours per day; open for breakfast, then open again for dinner.

Unfortunately, Yext would only accept one “open” and “close” time per day, so that wasn’t something we could accommodate.

This project has taught me that good design decisions are scalable and reusable, this is how design decisions help reduce development time. Good design decisions also help maintain parity across the product in order to provide a seamless experience to the end user.

That’s the one “fun”, or “challenging” thing, depending how you look at it, about what we do here, is that you might look at this project and think it’s pretty straightforward, but when you start to dig in, you realize there’s a lot of small things (components) that are tied to or have impacts on other parts of the Management Console.