• Axure Blog RSS Feed

    by Published on 10-05-2016
    1. Categories:
    2. Inside Axure

    I figured that the recent visual and UX design update to the Axure customer portal would be a good opportunity to take you behind the scenes at Axure to look at the life cycle of a similar project: our previous portal update, which went live this past April and coincided with the Axure RP 8 release. This particular update focused on adding tools for purchasing, renewing, canceling, and assigning subscription licenses of Axure RP.

    We've been refining how we build software here at Axure since 2002, and by this point the process is pretty streamlined. But we don't adhere to any particular espoused philosophy of process management; we aren't a strict Scrum Agile shop, and we don't make use of a Kanban board. Our approach is informal by design, which makes it hard to encapsulate in a pithy five-point list or what have you. But what I can do instead is describe it by example.

    (This article is adapted from a portion of a talk I gave in September 2016 at UC San Diego, organized by the extremely nice people over at San Diego Experience Design. I'll be sharing more from the talk, which was about Axure's software design and development methodology, here on the blog over the next couple of months.)

    A high-visual-fidelity, low-interactive-fidelity wireframe of the portal's "change edition" dialog, with some change notes for the developer.

    Rachel, one of our product managers, ran the subscription update project, and she worked with Kevin, one of our developers. Victor—our CEO and our head of product management—was also involved because he was responsible for the change from the business side. The idea was to make subscription licenses, which were new to Axure RP 8, manageable via the existing license management portal. We needed this change for its own sake, but we also needed it a little ahead of the Axure RP 8 release so that we could test activating Axure RP with subscription licenses.

    The scope was limited for this update; we knew what we wanted to accomplish, and we also had a set of things we wanted to avoid. At the time, we were planning for a comprehensive visual refresh of both Axure Share and the customer portal. The plan was (and still is) to unify those two properties so that they shared the same design language. We didn't have the new design patterns in April, so Rachel was instead prototyping using the then-current Axure Share assets so that we could begin to bring the two properties together in anticipation of the later visual and UX refresh.

    We tend to start the process of developing a new feature pretty informally. The first prototype won't be very "deep"—just two or three screens. Victor will give feedback and clarify. Rachel will find some conflicts as she's incorporating the requirements and will present some possible resolutions, and Victor will weigh in. There wasn't much competitive analysis on this particular project, but in this case there was a fair amount of comparative analysis, where we looked at how other software products of all kinds have implemented subscription mechanisms.

    Changes needed to the cart page are mocked up and then called out using sticky note widgets.

    Development can begin as early as when the main scenarios have been addressed in the spec (i.e., the prototype). If the prototype gets to that point and the developer is still wrapping up another project, Rachel will continue to flesh out the spec, and it'll be more complete by the time development starts. Either way is fine.

    In the case of this particular project, once Kevin had wrapped up his previous development work and had come on board, communication was a lot of chat, via Slack, and a lot of face-to-face. Kevin had the RP file to work from and would generally ask questions via Slack first, some detailed, intended to stay on chat, and some short, followed by: "hey, can I come over?" (Rachel's desk happens to be next to mine, so I can confirm that Kevin was coming over a lot for a couple of weeks there. Which was nice for me, because I like Kevin.)

    Because they built it, Rachel and Kevin are now the resident experts on the set of features included in this portal update—which at Axure means they're the point people for any bugs that come up. They'll switch back to the portal project and prioritize it when a bug needs fixing. This can put them behind on current projects, which isn't ideal, but it's a concession that we make in order to preserve our culture of work and ultimately boost the quality of our final product.

    If we were doing strict Scrum Agile development, the Scrum Master might get concerned about the distraction of a portal bug fix and potentially push for Kevin to return to his current project. And poor Kevin would have to stand up the next day and admit that he didn't get anything done on the current project because he was fixing the portal.

    In situations where a strict process management framework is called for, to avoid implementing one is to doom your team to inefficiency. But to impose one for its own sake, absent a compelling reason, is just as misguided.

    Kevin takes deadlines very seriously, which is great. But if he were made to stand up and account for time spent on live fixes every day, it could be a recipe for anxiety and sleepless nights. Now, you might argue that that's a personal issue on Kevin's part, but we've found that happy, relaxed developers write better code, and so we prioritize that over sticking to a daily or weekly schedule.

    The imposition of Scrum Agile on a team is, let's face it, a drastic measure. It's a step to be taken when your team has demonstrated a clear, compelling need for it. The subject of what constitutes a good reason for implementing Scrum Agile is beyond the scope of this article, but for now we're happy to concede that good reasons do exist.

    In situations where a strict process management framework is called for, to avoid implementing one is to doom your team to inefficiency. But to impose one for its own sake, absent a compelling reason, is just as misguided. Ultimately, we've decided that a formal Scrum Agile approach—or any other formal approach to managing our software development life cycle—is unnecessary for the way we work today. ◼
    Published on 10-04-2016

    Our visual and UX design refresh of the Axure customer portal is now live!

    We recently released a fairly comprehensive redesign of the Axure Customer Portal. Many of our customers—even regular users of Axure RP—may not frequently get into the portal; in the past it's been mostly just a place to periodically update your credit card info or maybe assign a license if you're the manager of a team of Axure users. The recent redesign makes portal a more pleasant place to do all the stuff you could before, but we've also added a dedicated profile page where you can update your account details and add a profile image.

    The profile image is only being shown in about three places right now—all of them inside the portal—but over the next few weeks and months we'll be rolling out some changes to Axure Share and Axure RP that will incorporate it. So if you're a profile-photo type of person, head over to and upload that pretty-good shot of you on a hike from last spring. Or maybe the one of your cat sitting on your laptop keyboard while you're trying to work in Axure RP—that's a funny one. ◼
    by Published on 09-28-2016

    The Format Painter is a tool in Axure RP that allows you to quickly copy and paste style properties from one widget to another. It's a "modeless" window (the opposite of "modal"), meaning you can have it open while simultaneously working on the canvas. It's super useful and has been part of Axure RP since forever, but it's one of those features that can kind of stay under the radar if you don't know to go looking for it.

    As of Axure RP 8, you can access the Format Painter via the "More" dropdown in the Tools section of the main toolbar. (In previous versions it was available via a small icon in the Style toolbar.) Here it is in action:

    You'll notice that the Format Painter dialog has a line item for each style property available in Axure RP, and each one can be checked or unchecked to include or exclude it when painting to your target widget. If you scroll down to the end of the list of style props, you'll find that you can even use the Format Painter to copy interaction styles (e.g., MouseOver, Selected) between widgets. Convenient! ◼
    Published on 09-21-2016

    The term "web fonts", in the general sense, refers to the web development technique of using font files hosted on a remote server—instead of on your computer's local hard drive—to render the letterforms you see when you browse the web. In the world of Axure RP, the term has a second, related meaning: it's a feature that allows you to use web fonts in your diagrams by configuring your Axure RP project file to point to the fonts' hosted locations out there on the internet.

    Web-based font-hosting has been prevalent since about 2010. (The Axure RP feature has been around since version 7, released in 2013.) The year 2010 was a big one for web fonts in large part because it was when Google, in their inscrutable benevolence, debuted Google Fonts. Competitor Typekit had begun selling access to web fonts in 2009 (before being acquired by Adobe in 2011), but no one before Google had offered a high-quality library of web fonts that were free to use. (These days there are some pretty good free-to-use alternatives to Google Fonts, such as Brick.) Speculation has simmered over the years as to why Google maintains the service, but the Google Fonts site was given a Material Design makeover this past June, which I think we can take as a fairly positive sign of Google's ongoing commitment to it.

    Using Google Fonts is the easiest way to implement web fonts in your Axure prototypes. Read on for a step-by-step walkthrough of how it works. (Also, if you prefer to learn by example, download this .rp file that's already set up with links to three different Google Fonts web fonts.)

    - - -

    1. Head over to fonts.google.com and browse or search for a font you'd like to use. If you want to follow along with the screenshots in this article, you can search for the "Raleway" font.

    2. Click a font name to go to its profile page. Once there, click the big red "plus" icon to select the font; you'll then see a popup notification bar at the bottom of the window.

    3. Click the notification bar to expand it, and then click the "Download" icon in the top-right corner to download a zip archive of your selected fonts. Keep the Google Fonts webpage handy though, because we'll need it again in a minute.

    4. Go ahead and install the font files you downloaded and then restart Axure RP if it was already running. You'll now be able to use your new typeface to style text as you work on your diagrams. That's half the battle! (If you're not sure how to install fonts on your computer, try these articles for Windows users and Mac users.)

    5. Back on the Google Fonts webpage, highlight your font's "embed URL". You want just the piece inside the first set of quote marks, starting with "https" and ending with the font name, as shown below. Once you've got just that piece selected, copy it to your clipboard.

    6. Fire up Axure RP and open your project's Generate HTML dialog ("Publish > Generate HTML Files…"), and then go to the "Web Fonts" tab. Add a new entry to the web fonts table using the green "plus" button, name it after the font you downloaded, and then paste the URL you copied into the "URL" field, as shown below.

    Click either "Close" or "Generate", depending on whether you want to continue editing or generate your HTML output right away.

    - - -

    The Google Fonts service is convenient to use, but of course it has its limitations—the main one being that it doesn't offer every font under the sun. If you absolutely need to use a particular font in your project, and if it's offered via another font hosting service or if you're planning to self-host, the process of getting set up may present a few extra hurdles.

    1. Other font hosting services. If you're the spendy type, there are a half-dozen sites out there offering fonts and web font hosting for a price. Axure customers seem to prefer MyFonts and Monotype's Fonts.com, both of which are tried, tested, and fully compatible with Axure RP. Adobe's Typekit will also work for pointing to web fonts, but Axure RP users who run Windows should take note: Typekit's digital rights management (DRM) scheme makes its local fonts incompatible with Axure RP on Windows (but there's no conflict on OS X / macOS). So if the typeface you absolutely need is only available via Typekit, you'll want to take advantage of Axure RP's font mappings feature (read on) so that you can use it in your prototype.

    2. Font mappings. If you'd like to use a particular web font in your prototype but don't have that font installed on your local computer, you can still make it work by using a feature called "font mappings". This feature works by swapping out a font in your prototype for a designated web font when the project's HTML is generated. You'll see the local font on the Axure RP canvas, but you'll see the web font when you view the prototype in your web browser.

    To create a font mapping, head to the next tab down in the Generate HTML dialog and map any font that you already have on your computer to the web font you just configured. Here's an example:

    So in this particular example you'd design all of your text using the Gill Sans font while you worked in Axure RP, but then the text would appear in the Raleway font to you and to others visiting your hosted prototype after you published it to the web (e.g., to Axure Share).

    3. Icon fonts. The popular icon set Font Awesome is included in Axure RP as of version 8; you can access it by switching to the "Icons" widget library in Libraries pane's dropdown menu. No web fonts configuration required!

    If you'd like to use a different icon set, and if it has been hosted online somewhere as a web font, the steps to get it working in Axure RP should be the same as with any other web font. Keep in mind, though, that many font icon sets have not been hosted online by their creators; they expect you to do the hosting part yourself.

    If you're having trouble getting a particular icon font working in Axure RP, try searching the forum for that particular icon font, or feel free to email the Axure product support team at support@axure.com for assistance.

    4. The "@font-face" method. If you're using any major web fonts service, you'll be provided with a link to a .css file as a quick and easy way to point to the hosted location of the web font you want to use. (This link is called the "embed URL" in Google Fonts, but may be called something different by the other services.) On the other hand, if you or your company has self-hosted a font, you probably won't have a tidy CSS file to point to.

    If this is the case, you'll need to use the "@font-face" method instead of the CSS method to point to your web font when you're configuring your Axure RP project. The @font-face method can be tricky to implement and is not the recommended method for using web fonts in Axure RP. But if you need to do it, here's an example of how it might look:

    5. Enabling cross-origin resource sharing (CORS). Self-hosting a web font is not for the faint of heart; it's leaving "Axure RP user" territory and entering "web administrator" territory. The Axure support team probably will not be able to help you if you run into trouble with self-hosting a web font, but we have learned one useful trick from experience: you need to enable what's called "cross-origin resource sharing", or "CORS", on your web server. This is pretty much the number one problem web font self-hosters run into.

    But how can you enable CORS on your particular server? Fortunately, the good people over at Enable CORS are passionate about enabling CORS, will tell you when and why you'd want to, and have technical details about how to do it for a long list of server platforms. It takes all kinds to make the world go round, folks. ◼
    Published on 08-31-2016

    When Megan Miller arrived in San Francisco in November of 2014 to attend Adaptive Path's annual Service Experience Conference, she came as a web designer in the midst of an existential quandary. As a member of Stanford University's in-house Web Services team, the focus of Megan's passion had recently begun to shift away from her visual and UX design duties and toward a holistic view of her clients' end-to-end experience. Her team's services were an important piece of that experience, to be sure, but there were other pieces: web hosting, ordering and billing services, video-conferencing services, and IT considerations such as workgroup administration and web authentication. Megan was increasingly drawn to the bigger-picture question of where the gaps might be in that end-to-end experience and whether principles from her UX design practice might be applicable toward bridging those gaps.

    By the time she returned to the city one year later for The Service Experience Conference 2015, it was not just to attend but to deliver a presentation of her own. A lot had happened in the intervening year. She had been in the audience when Erik Flowers, Principal Service Designer at Intuit, delivered a presentation at the 2014 conference. Inspired by his story of success in carving out a place for service design at a high-profile technology firm, Megan contacted him for advice. Their email exchange led to a series of in-person meetings, a weekly web-hangout working session, and ultimately to the launch of Practical Service Design, a central resource and "home away from home" for service designers both fledgling and experienced. The site launch coincided with a new title for Megan: Senior Service Designer. Service design had officially arrived at Stanford. (Check out Megan's 2015 talk if you'd like to hear her inspiring story in her own words.)

    UX Design has matured. 10 years ago, having a UX team would have been novel. Now, it’s a must. Companies are defined by UX and customer delight, because there are 20 other apps just like yours.

    When we checked in with Megan to see what might have changed around the office since her change of position, we found her still experiencing the rush and challenge of the new. "I came to this with 10 years of UX and digital design experience," she said. "It’s a new skillset—a very different toolkit. Your wireframes won't help you." (Instead, the discipline lends itself to certain other types of deliverables: the service ecosystem map, the end-to-end overview, the service blueprint. More on that below.)

    Megan's service design projects so far have prominently included the "contextual inquiry" method—i.e., sitting with your users and watching them do the task you're interested in—and the results have been illuminating. A recent project studying campus-wide usage of document storage and collaboration services (e.g., Google Drive) was typical of her approach: "I had them show me tasks: pains, gains, creative uses. I brought back emerging personas, top uses, top gains, top pains, preliminary recommendations. The idea is that the information collected will inform future strategies. It all went into a big report, and the research will stand up over the next year." Depending on the project, the findings may or may not be immediately actionable—but that's perhaps to be expected while an organization's first-ever service designer builds a body of research. No immediate next steps were planned to follow on from that particular study; instead, the research will fit into and help clarify the larger picture of how Stanford's community can best benefit from their IT services. "These collaboration services are not going away," she said.

    Why Now?
    Megan's trajectory from UX design to service design mirrors a broader trend. (The service-design-focused Service Experience Conference, which facilitated Megan's and Erik's partnership, was first held in 2013 and will move to a larger venue this fall.) "Service design is only about 20 years old," she told us. "The roots are in the services industry: hospitality and government to name a few. We’ve only seen it recently catching on in the West Coast."

    We’ve had people comment that they’ve worked in an area for five or six years but never truly saw the end-to-end of what happens before and after their part. That’s the magic of service design and the service blueprint.

    In her view, the rising profile of user experience design over the last decade has been an important prerequisite, giving customer-focused organizations a model for how to now think about and take advantage of service design. "UX Design has matured. 10 years ago, having a UX team would have been novel. Now, it’s a must. Companies are defined by UX and customer delight, because there are 20 other apps just like yours. We’re riding a wave of design that is cresting. Everyone is getting the basics right." This, more than anything else, may explain the trending popularity of service design: organizations by and large now "get" the value of UX design, have incorporated it into their processes, and are ready to take the next step on the path toward a comprehensively user-centric ideology. (For more on the challenges and opportunities of service design, check out this article by Erik and Megan, available over at Service Design Network.)

    The Service Blueprint
    We caught up with Erik Flowers via Slack chat to find out how he diagrams and documents his findings in his work at Intuit. "We’ve utilized the service blueprint format heavily," he told us, "modifying it into something sort of new that allows us to take these end-to-end experiences and really dive deep into each moment from the surface journey that you can see from the outside, to the deep core of underlying support processes and systems and people that make it happen. It’s an analysis of all the intermixed pipes, wires, tunnels, chutes, ladders, and our internal actors that are supporting the experience above and trying to make it as functional and smooth for the customer as we can."

    A service blueprint, rendered in sticky notes. Credit: Erik Flowers.

    The service blueprint really shines when documenting the most complex of systems—the ones with the greatest potential for inefficiencies and oversights to creep in. Erik explained: "For those scenarios that really add up in the end as a painful customer support case, we’re able to address things much more collaborative and end-to-end. Then we can get to root cause and fix it upstream, so the logjam never happens in the first place. You can pull logs out of a river all you want, but it’s better to actually take a step back and see why they’re coming down at a rate that is causing the downstream jam."

    A service blueprint. Credit: Megan Miller.

    "We’ve had people comment that they’ve worked in an area for five or six years but never truly saw the end-to-end of what happens before and after their part. That’s the magic of service design and the service blueprint. It gives you a high level view and at the same time a highly detailed view. And with that, you can finally look at the beginning and end of an experience, and everything in-between, and generate those easy tactical fixes you can just go do right away, and larger strategic insights that require a vision shift across silos that probably will need leadership to see that end-to-end and let them see how everything is impacting something else. There’s really no way a single team or person can see that, it’s just too big. But once you make it tangible and visible, you can take that high level, wide view, and generate insights from that without having to hold it in your brain all at once."

    Here to Stay
    Is service design a flavor of the month? Juha Kronqvist, a researcher and lecturer at Aalto University in Espoo, Finland, defended the long-term value of the discipline in an article published on Medium last November:

    "The ongoing change from an industrial society to a service economy is getting stronger and affects the design world as well. The share of services in GDP is rapidly growing and successful products increasingly resemble services (Iphone, Nest, Fitbit). Service design is created in response to this megatrend and it elevates the capabilities of designers to a strategic level. Designers are expected to understand how services operate, even if they only design products. Service design — developed during the past 30 years — is still new and not without growing pains, but interest in its utilisation is booming as tangible results start stacking up."

    For Megan's part, she retains a healthy dose of self-deprecating skepticism even in the midst of her enthusiasm. "Service design isn’t the silver bullet," she told us. "We’ll hit the trough of disillusionment at some point. But we’re really new here, so we don’t want to limit the possibilities." ◼
    by Published on 08-23-2016

    Did you know that you can "9-slice" in Axure RP? The Axure RP version of the feature is called "preserve corners".

    Sometimes you've got an image button that you want to resize quickly, without remaking it using widgets and without ending up with a jaggy, distorted mess. Perhaps your button has a detail that makes it trickier to quickly rebuild—maybe something like this button I found on the download page of a certain industry-leading prototyping tool:

    If I wanted to make this button wider to fit a long piece of text, stretching it horizontally would leave me with some distortion, like this:

    Notice how the "reflection line" detail is skewed as compared to the original, and how the right border is now thicker than the top and bottom borders. Not great.

    This is where the preserve corners feature comes in. Observe:

    When you right-click on an image and select “Preserve Corners”, four dotted red lines appear over the image.The lines are marking out areas on the borders of the image which will not be scaled when the image is resized. Because I wanted that reflection detail to be preserved when I resized, I dragged the left-side divider to the right of the reflection line, making the preserved portion of the image on that side nice and wide. Then, when I widened the whole image, only the center portion scaled. Because the part I defined as the center is just a simple vertical gradient, I didn't get any distortion when making that part wider.

    I think of the preserve corners feature as the lime squeezer in the Axure RP kitchen drawer—designed to do one thing really well, and super useful when you need it. Next time you're making margaritas or working with image buttons, give it a try. ◼
    Published on 07-26-2016
    1. Categories:
    2. From the Field

    Photo: Elizabeth Benker, ZS Associates
    When ZS Associates went through a company-wide rebranding in 2014, Elizabeth Benker—at the time a Design Lead, and now the UX Manager for the firm's Javelin™ Product Suite—saw the opportunity for a systematic, standards-based approach to the design overhaul of the product portfolio. The result, after a six-month effort requiring a balance of focus between the UX team's standards work and its members' various primary job functions, was a comprehensive new set of design guidelines: the ZSUI Standards.

    In a postmortem phone conversation with Axure this spring, Elizabeth told us that Axure RP turned out to be integral to the process of developing the new framework and communicating it within the software development team. "The project had been dragging on because we were stuck on the tool question. When we finally landed on Axure, we all said, 'Genius!' We were all fired up. We had everything we needed to get started."

    The Project
    The firm’s larger rebranding effort had provided Elizabeth and her colleagues in UX with a rare moment. "All of a sudden, all of the software we build had to be updated at the same time. We wanted to seize the opportunity to develop a consistent look and feel and a single set of interaction patterns. Because there was so much excitement with the new brand, we had a lot of organizational momentum."

    The goal was to unify ZS' Javelin™ products through a consistent user experience, starting with a unified user interface. The means to that end was conceived as a central repository where anyone—UX designers, product managers, front-end developers, and even consultants developing custom applications for clients—could go to learn about design standards, see and experience working examples, and download functional assets.

    As the UX team began to gear up for the standards effort, the potential benefits of the project became even more apparent: the new framework could also serve as an onboarding tool for new team members. "We were painfully aware that our lack of documented standards wasn't just resulting in a lack of alignment across teams, but also frustration among our own new people," said Elizabeth.

    We had a new person join the UX team in January—she was much more effective from day one. Her first week, she’s wireframing, and it looks like our stuff!

    The Team
    The project began with just three designers—Elizabeth, Shannon Burch, and Andrew Heber—a tight-knit group who had forged a common sensibility through sheer time spent shoulder-to-shoulder. "The three of us had worked on a massive, complex project together. To support multiple people working on the same design, we'd quickly aligned on styles. We'd worked it out through many conversations. When we were no longer on that project, we brought the same standards back to our own products. And for a while, that worked."

    But the ad-hoc approach to standards wasn't scalable. "They were locked away in our heads," Elizabeth recalled. "For the framework project, we needed more hands on deck from a UX perspective. The original three of us had all of these standards, discussions, agreements, but we hadn’t documented them. We just knew the standards—or we thought we did! But we weren’t as aligned as we thought we were. It was frustrating. A new designer would show me a screen and I'd say: these aren’t aligned with standards. They'd show someone else, and another opinion would emerge."

    The Tools Question
    Perhaps the very method by which the UX team aligned could also be the platform for distributing the finished framework? They began to look for the right tool.

    "We met with our front-end developers. We asked: should we buy an off-the-shelf tool to create a style guide in a way that multiple people can access? A CMS, or maybe some kind of style guide app? But all of the tools to build style guides were not quite right for us. We knew we wanted an online repository that communicated and presented our standards.

    "Our designers are not developers. They’re designers. Not unicorns. We really, really wanted the designers to be able to create and update standards themselves. And we wanted those UI interactions to be demonstrated via working examples; we didn't want just pretty pictures of them.

    "With all of those criteria, we struck out. We even discussed building it from scratch through a vendor. For a while, we felt quite discouraged."

    And then Andrew, a Senior UX Designer, said “Why don’t we just use Axure?”

    The ZSUI Standards project ultimately took the form of a microsite, built in Axure RP and published to Axure Share, along with a downloadable package of production-ready CSS built by their front-end developers. UX Designers use the Axure masters and libraries as a ready-made, drop-and-drag toolkit for creating on-brand, interactive wireframes. UX Developers leverage the CSS Framework when building new features.

    Elizabeth told us that the results have been positive. "The UX team has been using the new framework since the beginning of the year. The wireframes are on-brand right out of the gate. They’re able to learn the standards quickly. It’s really cut down on the time, both for wireframing and for onboarding new UX team members.

    "Now it’s so much easier. When we had a new person join the UX team in January, the contrast between onboarding her and the previous person was like night and day. She was much more effective from day one. Her first week, she’s wireframing, and it looks like our stuff! And visual QA time to ensure the finished product is polished and on-brand has also decreased because everyone is pulling from a shared collection of design and development assets."

    ZSUI Standards excerpt. Credit: ZS Associates

    Axure RP's features geared toward collaboration and content reuse—team projects, discussions on Axure Share, masters, and custom-built widget libraries—have facilitated the upkeep and continual improvement of the ZSUI Standards.

    "Now we have a backlog. We release one new standard a week at this point. We started with the straightforward stuff: radio buttons, a fonts page, a colors page, error handling, success messages. Aligning the standards is no small feat. It’s a lot of passionate arguments and discussions.

    "But what’s so great is that we have time now for conversations about the deeper things. Now we’re really tackling: what should the filtering experience be like across our products? Things that are much more complex. Now that we've solved the lesser issues, it frees us to focus on the thornier problems."

    It empowers people—they can put things together themselves. They have more confidence that what they put together is high-quality and consistent.

    ZSUI Standards excerpt. Credit: ZS Associates.

    Next Steps
    Elizabeth is excited about what the new framework means for the future of design collaboration across teams at ZS Associates. "We have a test case happening right now. A team that is not a product team is using the assets. They’re building something and it looks exactly like one of our products. It’s pretty cool."

    Pavneet Kaur, a developer based in ZS' Pune, India office, shares the sentiment. "We're building a new product with a very intense timeline. Initially I was a bit hesitant to use the ZSUI Framework. I thought it would be a difficult and time-consuming activity for me to understand and use the library they made. But Mikhail (Vazhenin, a front-end developer involved in the standards effort) made it look like a piece of cake. To summarize, I would say: it’s easy to make things look hard, but hard to make things looks easy. ZSUI makes everything easily beautiful and consistent."

    "It empowers people," said Elizabeth. "They can put things together themselves. They have more confidence that what they put together is high-quality and consistent."

    About Elizabeth Benker
    Elizabeth leads User Experience strategy, research, and design for ZS’ Javelin™ suite, a set of software applications that maximize sales force performance. In addition to her product role, she also applies UX methods to consulting engagements focused on solving complex business problems for global firms. In her career as a UX professional, Elizabeth has worked with a wide range of Fortune 100 clients. She has also worked on multiple in-house teams and taught user-centered design at the university level. This varied experience has shown her that good UX is truly a strategic differentiator. It is this belief that fuels her passion for UX, whether she’s working to improve a CEO-level executive dashboard or a consumer-facing cruise-booking engine.

    Page 1 of 9 1 2 3 4 5 6 7

Search Engine Friendly URLs by vBSEO 3.6.0 PL2