Yesterday, Skuid’s senior director of product experience, Shannon Hale, hosted a Reddit Expert AMA (Ask Me Anything). For anyone who isn’t familiar with the channel, the AMA is one of Reddit’s mainstream features where experts put themselves on the line to be questioned in their area of expertise by Reddit users everywhere.
The focus of this hour-long segment is user experience (UX) design, Shannon’s field of expertise. Shannon has 20 years of combined experience in tech roles, with titles including principal software engineer, lead interaction designer, and director of product management.
She currently works as senior director of product experience at Skuid, where her teams design tools that help business experts create powerful enterprise applications without code.
Previously, she worked as director of platform product management at Salesforce, where she was responsible for many declarative tools including Schema Builder and the Formula Engine.
Here are some highlights from the conversation, as seen on Reddit.
What’s a no-code UX platform, and how does it work?
Q: What's a no-code user experience platform?
A: Great question! Our no-code user experience platform is a library of components that are common to enterprise business applications, that have been created with a good user experience in mind, and that can be combined and hooked up to data and actions to create applications.
Common applications include extending customer relationship management (CRM) platforms, enabling salespeople or service agents to be more efficient. Creating a custom experience tailored to the company's own business processes helps users get more done faster and reduces the learning curve for complex processes.
Q: Interesting stuff. How do you present things like complex SQL (structured query language) queries in a way that's understandable to people without much understanding of data files and structure?
A: That does get tricky. It's not so hard when the objects being queried are all in the same table, but foreign keys and subqueries can be really challenging (particularly with Salesforce, where foreign keys can seem to be just another field on the object, not an actual different object).
We provide a picker to choose the fields and the ability to add filters which handle things like whether something's greater than or less than or equal to something else, and we use a merge field syntax to equate field values to other fields.
We keep revisiting this, though, because a problem we see is that although people manage to create the queries, it's also easy to construct a query that's not going to perform well. Those nuances are harder to communicate.
Q: In my tinkering I noticed that JQuery plays a large role in Skuid, in particular with the way the theming system works. Do you see a transition away from JQuery in terms of theming and components and more towards fully custom components, similar to the Lightning Design System?
A: I have to be careful how I answer this, or the engineering team will get mad ;) But yes, it's definitely something that's been discussed as we look at our next version of components.
Q: What has been the most difficult thing about creating no-code tools to build applications that are typically code-intensive?
A: Honestly, the biggest challenge is thinking about all the possible things someone might want to do with the tools, and then how to abstract those out into a system that works well for a common denominator of customers. We've been careful not to choose vertical applications (like specifically a CRM), so we have to consider our components as they might work across multiple applications.
As soon as you think you've considered everything, someone comes up with another use case.The second biggest challenge is to create a UI (user interface) for configuring the components and actions that doesn't basically reflect the complexity of the code.
Skuid for professional developers and citizen developers alike
Q: As a developer, the marketing around tools that promise low-code feels like a slight to those of us writing code. One of the reasons I love Skuid is that while it is low-code, I can also custom code interactions and interfaces.
However, that rarely gets pitched as a selling point, whether it’s Skuid or Salesforce.What are your thoughts on the relationship between declarative tools and custom coding? Is it really just a matter of the audience these tools are attempting to reach?
A: I think there's a lot of value in declarative tools for developers. When I worked on Schema Builder at Salesforce, it was definitely a tool for a more sophisticated user than the custom field wizard, a declarative tool for developers.
As I mentioned on an earlier comment, I used to be referred to as the Product Manager for the "Fast Developer Tools" when I was working on the declarative platform at Salesforce.
But I also think the relationship between declarative and programmatic should be seamless. Need a formula or action to do something that's not out of the box? There should be hooks for a programmer to write that and expose it to the declarative user.
These are the types of things that I'm looking at with Skuid right now, but it means also considering things like where things get used, how they get configured, what happens when they change over time (versioning), and how to support all that.
Q: Were you involved with Salesforce’s Process Builder? In broad strokes, how was adoption of that tool? As a coder, it was never easier for me to use the Process Builder compared to writing a trigger, even with the hassle of deploying to production.
I kept tripping over the tool. Very frustrating. Assuming the "no-code experience" or "clicks not code" is a trend in the industry, how are you positioning that idea with traditional devs? Are you hoping to convert them, perhaps with the promise of less time spent testing and deploying? Or are you just focusing on non-coder admins?
A: I wasn't directly involved with Process Builder, though since all the tools on the Force.com platform need to work together, I had input on it. It definitely took a few releases to come together, which is a challenge when you're trying to replace something like the workflow engine, when you're looking at 10 years of functionality, it's hard to roll it all out in a single release.
But, adoption has been really strong. Keep in mind that many customers working on the Salesforce platform don't have any developers on staff and a trigger is beyond the realm of possibility for them, so processes are a huge win for them.
As far as no-code versus development, when I was at Salesforce, the head of Developer Evangelism liked to call me the product manager for the "Fast Developer Tools", it can be faster to use some of the no-code tools than to write code for the same functionality.
Also, you can move some of the effort off of the developers and onto skilled business analysts, and let the developers work on more complex challenges. For many enterprise customers, there's so much work to be done that there's no shortage of work left after the no-code stuff.
How are industry trends shaping the landscape?
Q: Do you see AI (artificial intelligence) changing the way no-code applications are used to create applications?
A: I think it will, but I don't think we've really started to see the depths of change here. And it also depends on what you want to consider as "AI." A lot of AI still requires training data and specific rules, and figuring out a way to communicate those in a way that is easy for business users to configure is really challenging.
If we can reach a point where the AI just creates the perfect UI without any intervention from an administrator, we'll all be out of a job ;) But I think we're a ways out from that yet.
Q: What about Skuid excites you the most in the upcoming future?
A: What I'm excited about most for Skuid right now is the next version of our component library. Now that we have a lot of customers, we've had a chance to take a step back and see how people are using the components, and where they've had to write code or do custom stuff, and we can reduce that and make people even more successful.
The relationship between declarative and programmatic should be seamless. Need a formula or action to do something that's not out of the box? There should be hooks for a programmer to write that and expose it to the declarative user.