Hello, I’m Geoffrey Gaenslen.

Building a Better Dashboard Go Kinetic

Go Kinetic is a portal for consumers with Kinetic internet service to monitor their equipment, pay their bills, and submit requests for technical support. I was brought onto the project team in 2024 to achieve two formal objectives:

• Bring the portal in line with Kinetic’s new brand.
• Show a user’s orders and support requests on their home page.

The Rebrand

Updating everything about the portal’s branding would be a lengthy process, but I quickly devised a roadmap to a minimum viable product: in the next development sprint, typefaces, colors, and basic UI components like buttons would all be updated to match the new visual identity from marketing.

Future sprints would bring individual sections of the portal in line with the parts of the brand that required more careful (read: time consuming) quality assurance: new typographic scales and a new spacing grid to apply to every single element of the layout which, if implemented too hastily, could break page layouts in unexpected ways.

The New Widget

While keeping up with QA on the rollout of the new brand, I worked with the customer experience (CX) experts on finding a place on the dashboard for orders and support requests, while simultaneously working on a third objective of my own:

• Improve the user experience of each section that I touch by making them more scannable.

User data told us that individual customers didn’t typically have many orders or support requests open (or recently closed) at a once; “two or fewer” described the overwhelming majority. So I designed a widget that would show two records, and scroll to accommodate others. At the dev team’s suggestion, the total was capped at four to keep loading time down, and the list of records would end with links to the dedicated “Orders” and “Support Request” screens in the portal.

Unexpected Feedback

In gathering customer feedback, we asked about the new features included in the new widget and on the dedicated “Orders” and “Support Request” screens. Users loved the functionality… if they could find it. I was confused; this was exactly the problem that the home page widget—which prominently displayed the new features—was meant to avoid!

But one of the CX experts seemed less surprised: they’d been working on Go Kinetic longer than I had, and they’d gotten this feedback on other home page widgets too. This gave me an idea: if every widget is getting this sort of feedback, then maybe the problem isn’t every widget…

Maybe it’s the dashboard itself.

I reexamined the dashboard, focusing on its structure and how it responsively resized and reorganized its widgets. I found two problems undermining the page’s usability:

• The widgets responsively compressed themselves vertically so they would all fit in the user’s viewport. But this cropped important content out of widgets, including calls to action like the “View and Pay Bill” button!
• The widgets responsively expanded horizontally to fill the user’s viewport, which made things harder to visually scan for; on larger monitors it was all too far apart!

Just as the problem was twofold, the solution I landed on was as well:

• Responsively change the dashboard from a fluid layout to a fixed-width layout beyond a certain viewport width, keeping the dashboard narrow enough to scan.
• Only let the Orders & Support Requests widget—which is a list of variable length—scroll vertically. (Even then, only in views of the dashboard that had more than one column.) Make the other widgets display at their natural height and allow the entire page to scroll to encompass them.

With the proliferation of mobile devices, most users expect to scroll a page vertically, even in desktop environments. But sometimes stakeholders can find that hard to believe. They can also find it hard to believe that white space can be good, actually!

But by talking with the CX team about these proposed changes first, we were able to present a united front to the product owners, and get the changes approved.

Conclusion

• The overall dashboard redesign made it easier to find the button used to quickly pay users’ bills, reducing the number of support calls needed to handle such transactions.
• The new Orders and Support Requests widget allowed users to contact field technicians assigned to them directly, further reducing support calls.

Architecting a Friendlier Home Base Nexus by Kinetic

Windstream’s wholesale unit was getting poor feedback from users about their ability to manage their clients using our existing tools: they were slow, and they were built around a client-centric view. That is, a user would search for a single client record, then drill into that record to see everything about that client: their contracts, their services, their open tickets, upsell opportunities, etc.

While this approach gave wholesalers a complete picture of each individual client, it didn’t serve the way wholesalers told us that they actually did their jobs: it leaned on a shallow notification system to convey which of their clients needed their attention, and it didn’t do anything to help wholesalers anticipate their clients’ needs.

Together, the project director and I conceived a new task-oriented information architecture in which the key sections of the portal would be the inventory, orders, quotes, and support tickets of all of a user’s customers. This would allow a user to more proactively evaluate their customers’ needs, because the new architecture would forefront potential problems and opportunities.

The stakeholder response to our pitch was… not what we had hoped for.

Stakeholders Divided

Business unit directors and product managers were deeply divided into two camps on how to respond to this feedback.

• Some liked our pitch, and were eager to do away with the old portal entirely, not just because they preferred the proposed information architecture, but because a new foundation presented the opportunity for much needed performance imporvements.
• Others bristled at the prospect of having to learn (and teach!) a whole new portal. They believed that adding a new page to the existing portal with clearer notifications could ameliorate some of the issues uncovered by user feedback.

Both sides proved intractable. While I searched for a compromise with the stakeholders, the question ultimately had to be put to senior management. The decision came back in favor of our pitch. A new portal would be built.

Approved. . . with New Requirements

Many of the old portal’s performance issues stemmed from the fact that it was old. It was showing its age on both the backend and the frontend. When approval for a new one was handed down, it was with two caveats:

• Windstream had just undergone a rebrand. The new portal would be among the first to adhere to the new brand guidelines still in development.
• The fact that a new portal would be a much bigger lift than tweaking an old one would have to be mitigated: the launch date was moved forward by three months.

The stakeholders and the developers realized that some functionality would have to be outsourced to make the new launch date. Ultimately, quoting would be handled by an integrated third-party tool. This was a bit of a disappointment to me personally (my work in quoting was why I landed the project), but I still had some ideas to contribute.

Getting Off the Grid

As it took shape, “Nexus” as the new portal came to be called, was largely grid-driven. Landing pages were tables full of records calibrated to show what our users would need at a glance based on their feedback and on stakeholders’ learned experience.

Each record in a table had actions that could be taken pertaining to it, such as updating a support ticket, changing the contact information on an order, or editing the permissions of non-admin users. For the most part this pattern for drilling down into specific data was clear and predictable.

Except in the case of date-driven events, like service maintenance. While stakeholders were debating information architecture, one thing everyone agreed on was the value of forefronting individual circuits that were experiencing problems. But we could push that concept further, if we accept the some other things to be true:

• If a user sees that a circuit is down, they want to know is when it will be back up.
• Circuits can be down for several reasons, only some of which are problems (scheduled maintenance, upgrades, etc.). But down time is still down time, and if Windstream knows it’s coming, the customer should too.

Once we accepted these truths, what we needed was obvious: a maintenance calendar.

Conclusion

• Nexus was unveiled at a trade show to positive buzz. It was recognized with a 2023 Partner Innovation Award and featured in Fierce Telecom for streamlining wholesale tasks.
• Within its first month, Nexus as a whole drove a 30% increase in quoting volume.

A More Focused Quoting Experience Jack of All Trades . . .

Windstream had a single quoting application for use by its enterprise business unit, its wholesale business unit, and by the external sales partners for each of those units. It was comprehensive, with the ability to quote multiple configurations of every product and service the company offered. However, feedback from salespeople consistently said the application was difficult to understand and use without training, and therefore quotes took too long to generate.

I was leading the UI/UX for WE Connect Partners, a portal for external sales partners to keep track of their customers, spot sales opportunities, and keep abreast of Windstream’s product catalogue. After a successful launch, the next feature on everyone’s mind was a native quoting tool.

Through discussion with the business—who began with the stated objective of “a native quoting experience that’s easier to use”—I guided stakeholders to three more specific objectives:

• Streamline the quoting experience by only offering the services that the business wants to keep selling.
• Structure the experience as a step-by-step “wizard” to improve user comprehension and make validating user input less cumbersome.
• Speed up the quoting process by only gathering information that affects the price of services, rather than everything needed to configure and activate the services after purchase (which can be gathered after a purchase is made).

Order of Operations

After deciding that the quoting experience should be a step-by-step process—basically a long form broken up into bite-size chunks over several screens that would be seen in sequence—the obvious question was “what are the steps”? The simplest answer was “each product gets a step”, but there were several complicating factors:

• Individual products could need multiple screens of questions, depending how complex the product is to price.
• Some individual products directly affect one another; certain configurations of one product could change what information is—or isn’t—required to quote a different product.
• Product configuration is not all that’s needed to quote services. The length of a service contract pertains to every product being quoted.
• Additionally we need to know the physical addresses where the services are being set up, and even if the same product is needed at multiple locations, each instance of a product can have a different configuration.
• Speaking of locations, every address entered into the quoting tool has to be validated before services can be quoted.

Frontend, Backend, and Business Coordination

As I collaborated with the business stakeholders on the individual product screens, the development team discovered that the API we were using to connect to Windstream’s original quoting application didn’t expose all of the data that we had hoped for. Fortunately, the new mockups I was producing had generated a lot of enthusiasm from the business, who prioritized updating the quoting API to deliver what we needed!

Expanding on the Design System

Though the Quoting Tool was intended to be “an application within an application”, and therefore had an existing design system to which it had to adhere, the “parent” application didn’t have many form fields, or guidelines for them. Since this new tool would be heavily form-based, the design system would have to be built out.

So while working with the stakeholders to determine what questions each product screen would need to ask (and in what order), I also started designing the form components that the questions would be built out of. Doing these things simultaneously allowed me to design individual components as we learned that we’d need them.

Conclusion

Reception to the Quoting Tool was extremely positive both internally and externally.

• Internally, alternate versions of the Quoting Tool selling products appropriate to other business units were adopted and integrated into those units’ respective applications.
• Externally, the Quoting Tool—combined with the streamlined backend processes and API changes that designing it prompted—reduced combined quoting and briefcase time for users by 2–3 weeks.