From Chaos to Clarity Employee Center

Yes, you can design a great user experience

CCB1134-K22

## Transcript X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:0 [MUSIC PLAYING] Hello, everyone. I'm Sarah Toulson, and I'm here to tell you that you can, in fact, design a great user experience whether you are working from the Service Portal or the new Next experience. A little about me-- I currently work with the awesome people at Servos. I am absolutely living the dream, serving state and local governments through digital transformation on the ServiceNow platform. I've been on this platform for four years or so, and before that, I went on a very winding journey that includes over 10 years in graphic design and many years spent in the public service sector. That being said, today, I'd like to take you through the basic process that I use to put together a front-end design. We'll talk about gathering the information you need, taking that information, and planning the layout, and then we'll attack the scary subjects of colors, fonts, and putting together styles into a mockup that you can show your stakeholders. Unfortunately, due to our limited time I'm not going to be able to get into the weeds as much as I'd like to give you guidance on font pairing, inspiration, or some of the other details that go into this process. I do have a pretty robust list of resources on my website that can help, but please reach out to me if there's more specific guidance that you need. With that, let's get started. First things first, getting that intel-- here, we're looking to use a series of workshops or conversations to figure out exactly what we need the portal to do, what the priorities and challenges are, and what general direction we need the design to go in. The more information you have up front, the easier those design decisions are going to be for you to make. Here's a short list of what you're going to be looking to collect and establish-- the personas, the functional requirements, brand styles, and organizational culture. Though we're ultimately talking design, I'm going to start us off talking about function. Why? As much as bad typography triggers me, and as important as the design is to the overall success of the project, a pretty design that does not deliver the functionality needed or get the users what they need easily is a failure. So here are a few things that have helped me gather requirements specific to the front-end interface. The first thing I do, I pull up the out-of-box portal that you're going to be using for your project, and I review the major functionality of the site with the team or the stakeholders. You're then going to go through the portal piece by piece, page by page with them to discuss what functionality exists versus what they need. Bring your personas into play here. For example, when Mary comes to the portal, what's the most important thing she needs to be able to do? Your other option is to address each widget or feature individually and ask, for example, what links need to be present in the header navigation. Last, you'll want to use this workshop as an opportunity to suggest functionality that may not be present but that may be a possible solution to some of the challenges they've articulated. One of my favorite examples of this is to put the SC Popular Items widget on the landing page as an easy front-page way to display the most-used catalog items without additional searching. Once you know what the portal needs to do and the content you're going to put in it, it's time to have another workshop to talk design. In the meeting, you're looking to do three things. First, establish those final decision makers. Double-check to ensure that there's no one above the current team you're working with that will have potential veto power over your design. This can really hurt project deadlines if objections are raised late in the development cycle. Next, look to establish the design direction. This is most easily accomplished in a series of questions. Start by asking, do you have an existing site design or brand guide you want me to use? If yes, most of the design work may be done for you. However, you still want to review this with the team to ensure it contains the information you need. Most brand guides are limited to print, and they lack specific direction for a website. So you'll want to ask follow-up questions to determine how they want to handle that. One of the best ways to handle these information gaps is to ask them if they want to emulate their current public site. If this is the direction they want to go, you want to review that site with them and ask if there's any specific elements they want to include or avoid. Afterwards, explore that chosen website to find styles and see how colors, fonts, features, and accents are used. If they do not want to emulate their current site or if they think their brand guide is a little outdated or lacking, set aside time to conduct a lightning demos workshop with the team. The concept here is very simple. You have the team members come to the meeting ready with sites and apps that they found and that they like and would like to see emulated in your project. During that meeting, they're going to share their findings, and the team is going to discuss the different options. And out of this, the team should arrive at some conclusions for a design direction, some style guidance that they want you to take. And last, during the design conversation, take the time to review any and all assets you've been given, including logos, brand designs, and approved images. Try to get these items ahead of time so you can figure out what styles the brand guide, again, doesn't cover so you can ask for specific clarification. Now that you have all the information you can possibly gather to help inform your design, it's time to start putting it together. So what exactly is a wireframe? A wireframe is an illustration of a page's interface that specifically focuses on space allocation and prioritization of content, functionality available, and intended behaviors. Notice I said nothing about colors, fonts, or styles in that definition. Before you get started, here's a few things that I do to prepare both my team and my wireframing app for success. First, define the scope of your wireframes and subsequently your mockups. Wireframing an entire site can be really long, arduous process, so provide boundaries to the design process by specifying how many and what pages will be designed, deadlines for providing feedback, and limited number of feedback sessions. You also want to ensure that the team is on the same page about the purpose of the wireframes versus the mockups. Remind them in reviewing the wireframes the purpose is just to look at the functionality and the layout and make sure everything's as it should be and not to worry about styling at this point. Later, I'll give you some pointers for presenting your wire frames and mockups. And of course, set up your wireframing tool. Not everyone uses wireframing software on a day-to-day basis, so here are a few examples of software programs that you can use. Really, anywhere that you can draw a box and place text in it is going to do the trick. It doesn't take an artist to put together an intuitive wireframe, and honestly, this can be just as, if not more, important than whether or not you get the button color correct. Now, onto some best practices for putting together those wireframes. Think of your wireframe as an outline for your site page the same way you would outline a long research paper. This is what visual hierarchy does, and there's a few ways you can help to establish that. First, divide your page by functional sections. The portal design I have up to the right is a good example of the divided sections of a site. Here, I use titles, but you can also use alternating background colors and other tricks to establish these boundaries. Next, employ white space or the negative empty space on a site to separate your content and provide focus. Increased white space can help direct the user's attention to a particular item. White space is not wasted space, though I've heard many developers comment to the contrary. It helps give your users the chance to focus on only a certain amount of content at a time, which can really help prevent them from getting overwhelmed. And last, use visual cues to help direct users to different degrees of detail on the page. Just like in a research paper outline, use different indicators to help the user determine where on the scale of importance the item falls and further help them scan the content quickly to find what they need. A couple of other things to consider when putting together your wireframes is that you want to limit the number of choices available to your users, and you want to prioritize the placement of features and content to more quickly address those most pressing needs. As much as possible, ensure that your users only have to consider four to six items at one time. Keep this in mind for features like lists or groups of cards, especially if there are other content types nearby. If you have more than this number of items, use pagination, tabs, and filtering to help them narrow down those choices as much as possible. As I mentioned you want to ensure that the biggest pain points are clearly addressed early. If this means putting a link or button to that one catalog item that is submitted incorrectly 80% of the time right there on the landing page, that's what you do, even possibly using those visual cues to highlight that particular item. And last, I love to use my landing page as kind of the entry point or the triage point for the rest of the site. You're looking to give them an introduction to the different types of content available and by triage providing them with the most used or most useful content and services right there from the start, like I did at the top of the design scene here. All right, now that we've laid everything out, we have our nice boxes that tell us where everything's going to go. It's time to start putting those styles into place so we know what everything looks like after it's developed. So what exactly is a mockup? It's a high-fidelity model rendering of a product, or in our case, it's a picture of the pages that make up our Service Portal. First, let's talk colors. Overall, the thing you want to make sure that you do here is give every color a job. Start by working from the information provided by your team. If your color palette is limited, you can expand it by taking that main color and creating various shades, lighter and darker. I have been given portal projects where I was only given one color to work from, so I promise you, you can make it work. Next, strive to balance how the colors are used across the site. The 60-30-10 rule works really well here. 60% of the colors should be neutral and easy on the eyes. I tend to use a shade of light gray or a very light shade of the main brand color, which is used mostly alongside white for backgrounds. Next, 30% should be that secondary color you use to create visual interest. This is your main brand color, usually, that you're going to be using for links, buttons, and that sort of thing. That last 10% should be the accent color. This is your bright pop that provides differentiation and really calls attention to different things. And last, try your best to associate colors with a given functionality consistently. Interactive elements should be the same color. If you have headings the same color as your links, for instance, that can get confusing. You can see here on the screen, I've shown a bit of a color palette brand guide. We took the colors that our client gave us and expanded them into different shades and then assigned those colors to different functionalities, including links, text colors, and the brand primary colors. Next, let's talk about fonts. This could be a presentation in and of itself with all the nuances, voices, and styles out there. The big takeaway here is to use balanced variety to establish that visual hierarchy. First, consider all of the use cases for typography. You have the main body text, which is the majority of your site, but you also need to consider different heading sizes and how they're used in page section titles or in panels, for instance, but also the small text on your buttons and links as well. You also want to make sure that the fonts you choose are legible. I have up there a good use case for these different items. If you can't easily read the font at different sizes, you're going to have a hard time communicating effectively with your user. And last, use font weights and styles to establish that hierarchy. You can see there on the right that this can easily be accomplished with only one font. This particular client has Gibson as their typeface, and they show a lot of differentiation just using different font weights or thicknesses and different styles like all caps. If you use more than one typeface as I've done in many portals, choose a distinctive typeface for your headings and a steady, legible typeface for body copy. Open Sans is one of my go-tos. This next part is the hard part for me because there are so many little use cases and details that we could go into that are all considered elements. The big takeaway here is to remember that you're ultimately trying to put together a cohesive design where all the moving parts work together. Start by styling your common elements. These are your links, your buttons, your panels, and the other piece is provided to you by that bootstrap design. Next, consider the state changes and how they're going to look. These are your hover effects and such that are going to change when the user interacts with the UI. Taking the time to consider the state changes can really go a long way to making your site feel more dynamic and reward the user for interacting. And last, consider content changes. There's a lot of dynamic content on Service Portal sites. One of my friends, who is a phenomenal developer but very much not a portal person, really helped me see the importance of this attention to detail. At one point, I showed him one of my designs, and he peppered me with questions. What does this look like if there are no items on the list or 20 items? How about if the short description for one of those requests is really, really long? You want to have a plan for how the design changes as the content changes. All right, once you've put it all together, the hard part is still in front of you. So here are a few things that I do to get through presenting a mockup to a project team or stakeholders and handle the feedback that comes with it. First, put this in front of your internal team before you put it in front of a stakeholder or client. This is going to help you ensure that you fix anything obvious that you missed, and it's going to help you get a good idea of what kind of feedback you can expect. And it's free practice. As you go into the meeting, inform your stakeholders of when they can ask questions and how feedback is going to be taken. I tend to review a page section by section, like about as much content as you see depicted there on the screen, and then I will ask for questions before moving to the next section of a page. They're going to interrupt you anyway, but it does help. As you walk through your designs with a nice, calm voice, note the use cases, functional requirements, and other decisions that led to the design as presented. Showing the rational explanation behind the visual design can often move stakeholders to see the reasons behind your choices and move them towards approval and help you avoid unnecessary adjustments. And as a bonus note that I forgot to put on this slide, some of the common pushback that you may get includes disagreements with the features placed specifically on the landing page or disagreement with the general design direction. Make sure your project manager or your other leadership is on board and ready to support you and be ready to back up your decisions with the direction and the decisions given to you by the stakeholder team members. If they suggest a change that would be detrimental, ask them what use case or requirement such a change will support. This is going to help you understand the need for the desired change and possibly find a better solution. All right, again, I hate how limited our time has been because there is so much depth to different tactics and topics that we've covered here today. If you have any specific questions, please reach out and let me know. I'm happy to help you become more comfortable with the design process however I can. I hope this is encourage you to see that the process of front-end design is a skilled, practiced endeavor, just like any of the other development work you've done, and I hope this also provides you with a roadmap for putting together designs that you can be proud of. Thank you. [MUSIC PLAYING]

From Setback to Success: Feeding your Focus and Maintaining your Motivation

CCA3071

<p>Even the most dedicated ServiceNow® MVPs face challenges that can dampen their enthusiasm and distract from their goals. How do they bounce back? What fuels their continued passion and commitment? Dive into this empowering session with distinguished ServiceNow MVPs as they tackle these tough questions. Discover practical strategies to overcome setbacks, sharpen your focus, and reignite your passion, regardless of the hurdles. Whether you’re grappling with motivation dips or seeking to enhance your resilience, this session will equip you with the tools to thrive in the ever-evolving ServiceNow ecosystem.</p>

Live Coding Happy Hour Live! The YouTube show we love, but more live than usual!

CCB2880

Grab a drink and unwind with us as we build something live on stage. Real-life development isn't so clean as our well-polished demos make them out to be. There's a ton to learn from watching experts struggle despite years of knowledge. And then tune-in at home on Fridays on the ServiceNow Developer Program YouTube channel!

WomenNow Meetup: Through the glass ceiling and beyond!

CCA3028

<p>Join this meet up to network, celebrate successes, and address the issues women face in the ServiceNow<span style="font-size: 11.0pt;"><span style="">®</span></span>ecosystem. Enjoy this opportunity to connect, exchange insights, and engage in discussions aimed at advancing professional and technical skills.</p>

Breaking barriers and building bridges in the ServiceNow sphere

CCT1313

<p>Despite progress, gender diversity in tech remains a challenge, with women comprising just 22% of the <span style="font-size: 12.0pt;"><span style="font-family: Calibri , sans-serif;"><span style="font-size: 11.0pt;"><span style="">ServiceNow®</span></span></span></span> community. Explore the barriers and challenges women face, get insights on thriving and leading in this evolving field. Join accomplished women developers and administrators sharing experiences, strategies, and the importance of fostering a supportive community. Whether navigating ServiceNow<span style="font-size: 11.0pt;">® o</span>r promoting inclusivity, this session empowers and charts the path for a more diverse future in the ServiceNow industry.</p>

Panel: 15 percent and fearless: A discussion among developers that happen to be women

CCB1225-K23

<p>It is well-known that the tech industry lacks gender diversity, and the ServiceNow ecosystem is no exception, with women representing a mere 15% of the ServiceNow<span style="font-size: 12.0pt;"><span style="font-family: Calibri , sans-serif;">®</span></span> community. Why is this the case? What barriers do women face that discourage them from pursuing a career as a ServiceNow developer? Join developers and administrators, who happen to be women, as we discuss the everyday challenges we encounter in the field, explore some of the hurdles we've faced and how we are able to overcome them. Find a community of women around you to share your experiences with and grow with.</p>

Content Classification Chaos: Building a Taxonomy Assistant With AI Agents

CCB7102

Content sprawl got you down? Catalog items and Knowledge articles scattered with no rhyme or reason? We'll explore building an AI-powered taxonomy assistant using ServiceNow's AI Builder Agents—and what happens when theory meets reality. Whether you're curious about AI implementation, wrestling with content organization, or want to learn from bold experiments, you'll get honest insights about AI Agent capabilities, real-world lessons about what works (and doesn't), and strategies for taxonomy content classification with or without AI.

Leadership in the HERizon: Meetup & Hackathon Team Build

CCA1520

Join this Lead Boldly session for an inspiring session featuring women from all corners of the ServiceNow ecosystem, along with leaders from our community & WomenNow, as they share their career journeys and personal experiences. This is a great opportunity to network, connect, and exchange stories with other women and allies in the ServiceNow Community. Plus, you’ll have the chance to form your Hackathon teams before the CreatorCon Hackathon kicks off!