• Axure Blog RSS Feed

    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
    Introduction
    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?”

    Results
    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

    Ongoing
    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.
    Published on 06-14-2016
    1. Categories:
    2. Software Development,
    3. From the Field



    Photo: Ken Randall, Flying Bridge Technologies
    Introduction
    There comes a time in the life of a young and successful manufacturing firm when disconnected homegrown systems and spreadsheets aren’t enough to keep up with the volume of demand. That’s when people like Ken Randall come into the picture. A business analyst, Ken helps companies create ways to streamline the way they do business and make sure their high-quality products are delivered on time—every time. A couple of years ago, Ken was called in to do just that for Element Designs, a manufacturer of custom cabinetry based in Charlotte, N.C. He and his team's solution was to customize and implement an enterprise resource planning (ERP) system from the ground up. The system he envisioned pulled together many different parts of the company, from handling tailored customer orders to managing raw material inventory levels to manufacturing to shipping. For a small company like Element Designs, this was a daunting project. Here’s how Ken and his team at Flying Bridge Technologies, along with partner iFensys, did it.

    The Project
    Element Designs makes high-end custom cabinetry. Their products are made to order from highly precise specifications provided by architects and builders. The company was facing year-over-year growth but there was no way their manual processes could handle the volume and maintain their attention to quality details. From handling customer and manufacturing orders to managing raw materials inventory levels to shipping, it was clear the company needed to implement an Enterprise Resource Planning (ERP) system.

    The Challenge
    This ERP implementation was an extremely large undertaking for a small and relatively young company. They had committed a good deal of their limited resources—both dollars and time—into the success of this project. So the pressure was on to get this right the first time. Failure was not an option for this company.

    The Team
    Because this project was so critical to the company, we had a team of 14 people. That included the company’s entire top leadership team of six executives, along with four key department heads. We also had a lead consultant, a process engineer, a technical architect lead, and myself as the senior business analyst. I was involved from the beginning, helping to identify the business case and developing the initial needs assessment. There were other people who floated into the project as needed, but they were not involved in the design, modeling, mapping, decision processes. That said, 14 people on the same page was no small feat, which meant that we needed a tool that would help communicate all the complexity of an ERP project. We chose Axure because it let us communicate with everyone in the company, and it was a tool that we could use throughout the project lifecycle.

    The Kickoff
    Once we got buy-in from the company’s leadership, we started the project with a workshop consisting of six clear-the-decks days, spread over two weeks, to get a clear picture of the current state of the company’s way of providing products. We started by taking apart the business processes and documenting them in Axure. We had configured a number of templates and had organized the page hierarchy for the various processes and sub-processes to use for this workshop.

    Moving from page to page and creating links on the fly in Axure, we were able to model in real time, at the pace of the workshop discussion. So there was no need to go back at the end of the working sessions and try to capture what was said, because we already had it captured during the sessions. At the end of the day, we just published the working models to Axure Share. As everyone already had the project link bookmarked in their browsers, it was a simple matter of refreshing the page to see the latest process models.

    Improving the Flow
    Process flows are the stock and trade of business analysts. We use them to define how something gets done and communicate that with practically everyone on the team—executives, business users, process engineers, tech leads, developers, QA testers, implementation teams and operations, to name a few. We also use business requirements documents to clarify the mission (the why), specifications (the what) and wireframes (the how). In the past, those elements were presented in separate documents, often in different formats—spreadsheets, illustrations, text, slides and so on. This made cross referencing information a big challenge, and created situations where documents sometimes had contradictory information.

    For this project, we decided to produce a single file in Axure that would convey the information normally contained in many of these deliverables. Our document had process models, often separated into functional flows via “swim lanes,” systems information, and high-fidelity screens that with entry forms. The file also contained a functional prototype of a new online tool that customers could use to configure their custom cabinetry to exact specifications.


    End-to-end flow provides an overview of the manufacturing process. Credit: Flying Bridge Technologies.

    Business teams can see at a glance the interaction of systems and process. Along the process, they can drill down by clicking through to see more in-depth information, such as the screens and forms, user personas, the relevant business rules and so on. Or they can stay on a high level to get the big picture. Either way, stakeholders don’t need to hunt down another document to get the information they need.

    Getting Everyone on the Same Page
    As we laid out the end-to-end process in Axure, we found a number of instances where the left hand of the organization had a different mental picture of the business process than the right hand of the organization.

    In this project, for example, this cropped up when we discovered through our flow analysis that some products had to be sent via expedited shipping to meet a deadline, even though it was the customer who had not approved the order in a timely manner. This was often because the up-front process was not being done in the right order. The Customer Service team set an expected ship date first and later asked the customer to approve the final order. More often than not, the customer approval was a day or two late in coming back, but the ship date was already established, and customer expectations were already set. For the Production Team, the only way to make up the time was to use express shipping - which added cost to the project and cut into the profit margin of the project.

    We find that putting the details of the business rules and UI on lower-level pages, allows us to keep the process flow diagram clean and readable. The details are abstracted into separate pages, but when published on Axure Share, are just a click away.

    The Customer Service team did not know that this was happening until we walked through the end-to-end process. Once it was laid out for all to see, everyone came to understand the underlying complexity—a key first step in simplification. We were able to surface several instances like this where one process had unintended repercussions elsewhere.

    To get everyone on the same page, we use the second major tool of the business analyst—business rules. Business rules are the logic and the rules of thumb that we use every day to make decisions in our jobs. Most of the time we don’t even think about them; they are decisions based on our experience or gut feelings. Business rules automate that process with the goal of helping everyone be consistent and improving efficiency. As business analysts, our job often boils down to identifying the need for such rules, defining them, and then documenting them in a way that’s simple enough way for non-technical team members can easily read and understand.

    This is accomplished through flowcharts for the logic and decision, matrix tables to show conditions and options, and screenshots of the UI to show how users would see the information. In the past, that meant having to jockey multiple documents to see the entire picture—a word processor for a high-level summary and description, a spreadsheet to see the list of rules, a diagram depicting the flow, and image files to show screenshots. We were able to consolidate our documentation into a single file, using Axure. From a page presenting a process flow diagram, you could click an icon that lets you see the relevant business rules. Another click takes you to the UI mockup. We find that putting the details of the business rules and UI on lower-level pages, allows us to keep the process flow diagram clean and readable. The details are abstracted into separate pages, but when published on Axure Share, are just a click away.


    Process flows in Axure can be linked to business rules in the same Axure RP file to provide more in-depth context. Credit: Flying Bridge Technologies.

    In this particular instance, we designed better visibility into our process flows, which called for earlier and better information provided by the ERP solution to what was. This allowed the Customer Service Team to help set customer expectations before orders were committed, while allowing the Production Planning Team to have a more time to make priority changes in the production schedule.


    Flying Bridge created a working prototype of this custom configurator using Axure RP. Credit: Element Designs.

    Takeaways

    1. Simple presentations are key for engaging executives in complex ERP projects. Element Designs had never modeled its processes before, and they were frankly leery of the need for such an up-front step. A great experience was required to prove the time spent would be worth the effort. Having the text, data, diagrams, UI, and related information in Axure RP as a central repository for all requirements, we were able to streamline the process and simplify it greatly for our client.

      At first, the publication of the process and screen mockups was thought of as an internal capability, between the business analyst and the development team. We quickly learned that the ability to publish to the client for feedback and validation turned out to be a huge win - saving a tremendous amount of time. At the end of every session, we were able to instantly publish the session’s work. And since the client already had the Axure Share URL bookmarked, all they needed to do was refresh the screen to see the changes.

    2. Having a single file allows us to collaborate in real time. This saves us the need for us to gather as much information offline as we would have had to otherwise. As we collaborate, we’re able to make the changes in the document right then and there.

    3. Business rules are key to communicating with developers. If you take the time to write and document the rules properly, the logic you create during the process can be easily translated into a series of case statements and if-then statements in the ERP software code, making the job of the programmer much easier and faster.

    4. Specifications often can be reused as training documents. We were able to create a final overview version of the process that was used to train the production team on what the process looked like from 30,000 feet. We had not planned to do this at the beginning of the project, so it was a good win-win reuse of the definition requirements.



    In the end, having a single document capable of communicating relevant information to all stakeholders saved us a lot of time, and it helped to make sure everyone from the CEO to the production manager were aligned and, quite literally, on the same page.

    —Ken Randall

    About Ken Randall
    Ken Randall has over 25 years of experience developing enterprise business processes and technologies. Throughout his career, Ken has been called on multiple times to resolve crisis and turnaround situations, as well as lead strategic initiatives. His expertise has evolved from client/server-based solutions to n-tier collaborative web applications and he has worked with many of the major technologies deployed today. Ken is currently Vice President of Business Process and Workflow Strategy at Wells Fargo. Prior to joining Wells Fargo, he was Vice President of Business Development at Flying Bridge Technologies Inc.
    Published on 05-17-2016

    Horizon Blue Cross Blue Shield of New Jersey has been awarded the No. 3 spot in the 2016 InformationWeek Elite 100. They earned this title for implementing a fee-for-value healthcare delivery model intended to improve healthcare delivery while lowering costs for patients.

    Kelly Sheridan, an associate editor for InformationWeek, wrote an article Horizon Prioritizes Data and Patient Experience that describes how Horizon combined solutions from Teradata, Tableau, EXL Healthcare, NaviNet, SAS Enterprise Business Intelligence, and Informatica, as well as custom Microsoft .NET apps and IBM WebSphere-based Web services to achieve this goal.

    To ensure that patients would get the information they needed to make healthcare decisions, Axure RP was used to create prototypes and gather feedback from members. Here is an excerpt from Sheridan’s article:

    A major part of the project consisted of revamping the organization's Doctor Hospital Finder, which was "messy and unclear" before the project started, said Blackwell [CIO at Horizon]. The insurer aimed to make it easier for patients to understand which healthcare providers were part of their plans so they could make more informed decisions. This involved strong use of the Axure prototyping tool, which allowed early-stage versions of the app to be tested among members so Horizon could receive feedback.

    For her article, Sheridan asked Blackwell, CIO at Horizon, if he had advice for CIOs attempting similar projects. Blackwell emphasized the importance of aligning the people who are thinking of business strategy with their IT partners. It is critical to ensure that all divisions are working towards the same goal.
    Published on 05-10-2016



    You don’t need to be a Fiori expert to start designing your own Fiori UX Apps. Working with Fiori stencils and icons created for use in Axure RP, you can quickly start building by dragging and dropping screens, icons and functional elements onto the canvas in Axure RP.

    To get started, download the Fiori libraries, and load them into Axure RP. If you don’t have Axure RP, you can still download a free-trial copy for 30 days for this exercise.

    Now let’s dive in. For this exercise, we’ll design a simple travel expense approval app.

    1. Know your test data. Before you start designing, have a basic idea of the data you will need for your app. For our expense app, this could be the expense type, the amount of the expense, the receipt (as an attachment), date and purpose. Advanced tip: If the stencils you use are built as Axure RP repeater widgets, you can even upload test data from an Excel spreadsheet if you like to make the exercise more realistic.

    2. Create role specific prototypes. Managers approving the expense, for example, will see a different screen than the employee submitting the expense. SAP recommends that Fiori designers focus on one user, one task, and three screens, also known as the 1-1-3 principle. Figure out exactly what the user needs to do to complete the task and how they will interact with your product. In this case, the user is the manager and the task is to approve the expense.



    3. Gather ideas. If you’re looking for inspiration, start by exploring the design elements here. You can also poke around the SAP Fiori Apps Reference Library. The library contains information about dozens of out-of-the-box SAP Fiori Apps. Here’s one for My Travel Expense.

    4. Fire up Axure RP and load the Fiori libraries you’ve downloaded. You’ll notice that the stencils come in three sizes. Choose any one.
      Large (L) - for desktop screens
      Medium (M) - for tablets with touch-friendly controls
      Small (S) - for phones with touch controls
      Learn more about these sizes here.

    5. Create a Master Detail App. Selecting a stencil from the SAP stencil library on the left and dragging it out to the design area. One of the most commonly used stencils for this type of application is SplitScreen_Object.

    6. Customize the fields to match your test data set. This is where you get to have fun playing with the interface and configuring your perfect app. For example, using the SplitScreen_Object stencil, you can rename the “Products” column on left to “Expense” and the right column as “Expense Detail.” Continue to refine the screen until it matches your data set. Violà! You’ve designed your first Fiori UX App.




    Once you’ve designed your master detail app for one screen size and form factor, it’s easy to adapt those designs for other devices by using the same stencils in the other two sizes.

    The advantage of using the Fiori stencils and icons in Axure RP is that they automatically comply with the SAP Fiori Guidelines, saving you the time of having to go through the 27-page checklist when you go through the SAP Fiori App certification phase. (You’ll still need to be careful when styling and customizing the stencils, however, to stay within the guidelines.) As a postscript, keep an eye out for SAP’s forthcoming update of Fiori, which SAP Partners say will feature additional stencils such as cards and overview pages.

    Need more information? We’ve compiled a list of additional resources.


    We'd like to thank Sana Salam, Chief Executive of Sodales Solutions Inc. for helping us create this guide.
    Published on 05-10-2016
    1. Categories:
    2. From the Field



    Photo: Sana Salam, CEO Sodales Solutions Inc.
    Introduction
    In Italian, the word "fiori" means flower. Three years ago, that’s not a word that would likely spring to mind when thinking about enterprise business applications. SAP, known for creating software that form the digital spine of some of the world’s largest companies, recognized that. SAP’s solution, launched in 2013, was Fiori—a suite of front-end business applications designed to be intuitive, modern and mobile-ready.

    Sodales Solutions Inc., the first SAP partner to become a certified Fiori developer, created a method for tackling Fiori projects. Here, Sodales’ Founder and President, Sana Salam, outlines her company’s methodology, which she and her team have refined over the course of completing 26 Fiori projects.

    Why Use Fiori?
    Simply put, SAP Fiori is the new user experience of SAP. It simplifies complex SAP products into intuitive self-service tasks, ultimately boosting process efficiency and user adoption. SAP created Fiori to solve two major user experience issues:

    1. Traditional SAP transactions involved too many screens and tabs making them daunting and inefficient. SAP Fiori UX reduces the number of clicks by showing only role-specific information and actions on the screen. In some cases, users see about 70% of reduction in the number of clicks with Fiori apps.
    2. Traditional SAP products are module based, where users are required to memorize transaction codes and program names to access and execute various tasks within a process. SAP Fiori UX can break down large processes into simple, discrete tasks and eliminating the need to summon transaction codes from memory.

    In some cases, users see about 70% of reduction in the number of clicks with Fiori apps.


    Because Fiori is responsive and device agnostic, many SAP customers also use Fiori apps as mobile apps, which opens up new avenues of business solutions that can be applied in more settings than before.

    When to Use Fiori
    In order to assess whether SAP Fiori is a good solution for our clients, we typically look to see if one or more of the following situations is true:

    • Tasks are time sensitive and completed by users who are on the road. This could be a plant technician reporting an operational breakdown, for example.
    • Users’ responsibilities are not tech oriented. This could be a sales team working with customers.
    • There are complex SAP transactions that need to be decomposed and simplified for better efficiency. A good example of this is the SAP purchase order creation process.
    • The project involves cross-platform processes and sources. Examples of this are recruitment, training and helpdesk processes.

    Applying Design Thinking for Fiori Projects
    At Sodales, we’ve completed 29 SAP Fiori UX projects (involving over 100 Fiori UX apps), out of which 11 are targeted for Fiori mobilization. Our design philosophy for Fiori apps is based on the Design Thinking framework—a creative problem-solving technique that brings a disciplined approach to innovation. This framework is especially suited for projects with little or no precedent to help inform an immediate or pre-built solution, but not so exotic as to be beyond the realm of customized Fiori implementations. We use various design thinking tools for managing the end-to-end application lifecycle starting from strategy, budgeting, roadmap, technical feasibility, user experience, requirements and testing.


    Photo: A journey map created during a Fiori workshop led by Sodales. Credit: Sodales Solutions Inc.

    Step 1: 360° Research
    Goal: Get smart quickly with problem discovery.
    How: During this phase, we schedule interviews and observation sessions with a carefully selected group of users; preferably from various disciplines. Research phase can be conducted over a span of a few days prior to the workshop, depending upon the availability of information/stakeholders. In some cases, research phase might just be about reading current state documents, analyzing existing studies or conducting phone interviews. Let’s use an example of a customer service process. In this case, we would start off by interviewing and observing various roles/personas involved in the process such as sales agents, supervisors, finance executives and operations teams. These one-on-one interviews allow us to capture unbiased yet personalized feedback and touch points about the problem. We augment insights gleaned from interviews with observation sessions to further understand the unarticulated needs of users. For example, if a customer service agent has to walk to a printer during customer meetings, that interruption might have a negative impact on customer experience.

    It can be tempting to skip this step and take our clients’ presentation of their problems at face value and start designing a Fiori solution. But if we don’t take the time in advance to dig deeper into the source of their issues, we might end up solving the wrong problem.

    Step 2: Synthesis
    Goal: Understand a typical user.
    How: During this phase, we spend about 15 to 30 minutes visually describing a typical target user by identifying personal details. In addition to age and gender, we also dive into their challenges, what they see or hear on day to day basis, how they do their work, and what their personal goals are. We strive to put ourselves in the shoes of the user. There are several design thinking tools available for this, such as personas, empathy maps and so on.

    Step 3: Journey Mapping
    Goal: Map the persona's current experience. Identify critical problems and opportunities.
    How: This step mirrors the intent and design of Fiori, which seeks to create experiences around tasks performed by specific roles, rather than a transaction-focused approach. Journey maps, paired with insights gained from personas, are a powerful way to start thinking about how you can structure your Fiori solution. In this step, we spend about an hour to map out of how our typical user goes through a certain process. We capture specific information about their emotional experience, stakeholders and systems. This allows us to capture the cognitive reasons of why and how users do certain things.


    Photo: An empathy map created during a Fiori design session.
    Credit: Sodales Solutions.


    Step 4: Brainstorming
    Goal: Rapidly generate ideas. Incorporate best ideas in low-fidelity prototypes.
    How: Here, we divide into groups of four to seven people, with each group addressing a specific problem. The groups spend about 45 minutes in brainstorming possible solutions. When forming groups, we try to include people from a wide variety of backgrounds, roles, levels of experience and departments. In our experience, this forced diversity tends to yield more novel solutions than having homogenous groups. For one of our projects, when we paired sales agents with lowest results with sales agents who achieved highest results, we found that the best and wildest ideas came from “lazy” employees who quickly found the easiest shortcut for doing a task. It is generally a good idea to have a project team checkpoint at this stage (designers, IT and executives ) to ensure we are still on track.


    Illustration credit: Sodales Solutions.

    Step 5: Storyboard
    Goal: Create a visual representation of future
    How: This exercise takes about one hour. Each group incorporates the most feasible and promising ideas to create at least one sample end-to end scenario of future. One of the key success factors for this phase is to ensure that we pair at least one executive decision maker with each group. The decision makers act as a moderator to ensure users are not creating something that is not a high priority requirement. The decision makers also help the participants with common understanding of various terminologies. The storyboard use show-and-tell approach. It is important to generate a large quantity of hand-drawn storyboards using as many sample use cases as we can think of. This allows us to conduct hypothesis testing in the next step.

    Step 6: Create “Napkin Pitches” and Low-Fidelity Prototypes
    Goal: Test hypotheses using rapid prototyping and feedback
    How: This exercise takes about three to four hours of collaborative, hands-on work where groups set out to create their napkin pitches. One of the primary goals of hypothesis testing is to assess the feasibility and viability of solutions. This cannot be done just by looking at things at high level. It involves testing the storyboards we’ve created in Step 5 for specific use cases with a variety of day-to-day situations. The hypothesis testing of a service ticket app, for example, might involve several potential scenarios, such as: 1) a technician receives a phone call from customer; 2) the technician is onsite for routine maintenance; or 3) customer service receives a request for return of damaged equipment. Can our solutions work in all three situations?

    To answer those questions, it’s important that our prototypes are created with enough detail to test out those scenarios. Such details would include all the required field labels, layouts, and key performance indicators that can enable users to think through the design variations. We use Axure to create detailed prototypes for Fiori, using a library of templates, icons, stencils and controls that SAP has built specifically for Axure.


    Screenshot of Fiori prototype in Axure. Credit: Sodales Solutions.

    If you'd like to explore SAP Fiori stencils, we created a quick start guide to get you on your way.

    The combination of pre-built Fiori stencils and Axure makes the effort of hypothesis testing negligible; we’re able to build a working Fiori prototype in Axure in as little 5 minutes. Through this process of building and testing our prototypes, we gain further insights into the solutions’ feasibility, giving us the confidence to take our innovation journey to the next step.

    The combination of pre-built Fiori stencils and Axure makes the effort of hypothesis testing negligible; we’re able to build a working Fiori prototype in Axure in as little 5 minutes.


    Step 7: Implementation
    Goal: Set up development project
    How: At this point, we’re off to a great start. We can begin planning the development phase of our Fiori project. At this stage, we can create an initial set of requirements as a project scope, as well as the supporting assets for business case approval. We use Axure to extract the documentation and data flow directly from the prototypes we created in Step 6. This documentation is quite detailed and gives us a fair understanding of the possible number of screens, the types of interactions, the user flows for various tasks in Fiori and so on. The visual prototypes created with Axure are also great for engaging executives during business case or budget approval meetings. They give executives the comfort of knowing that we have done our homework, and they create excitement because they can be touched and felt on a smart device just like a real app.

    The Upshot
    As you’ve probably gathered by now, Fiori makes designing business applications much more compatible with design thinking methodologies. That’s because Fiori encourages designers to move away from thinking about software features and instead focus on roles and tasks. In an article on the SAP Community Network, John Burton pointed out that, “All SAP Fiori apps follow a design principle known as 1-1-3 (“one, one, three”). This means each screen should be designed with a single user (or role) in mind, a single task that this user wants to accomplish, and a maximum of three levels of navigation to perform this task.” In other words, Fiori’s 1-1-3 rule encourages us to focus on one user, one task and three screens. Simplicity drives return on investment.

    Fiori’s 1-1-3 rule encourages us to focus on one user, one task and three screens. Simplicity drives return on investment.


    The approach we’ve developed further amplifies those returns by allowing us to technically and financially validate the innovation before it is built, making it particularly effective under budget constraints. It lets us evaluate which Fiori apps we should build first and how they can deliver the most value at lowest effort. And it does so with the help of direct user input. “Design thinking has significantly transformed the way of requirements gathering for us,” said Khemraj Sharma, Global Business Intelligence Manager at Karl Storz, a maker of surgical instruments. “It adds personal emotions, which were missing in traditional approaches. It allows users to be fully engaged, and they can express their idea more openly.”

    Many organizations use design thinking to solve problems. What sets our process apart, however, is speed. The bulk of this exercise, Steps 2-6, can be accomplished in a single day. Joe McLaughlin, Vice President, Operations and Technology for AAA’s Western & Central New York division, recently ran his team through this exercise and noted that the fast pace resulted in an “energetic, collaborative, and efficient approach to identifying improvement opportunities in key business processes.”

    What sets our process apart, however, is speed. The bulk of this exercise, Steps 2-6, can be accomplished in a single day.


    Processes are well and good, but what about results? Datta Sapre, an executive in IT Applications at SageNet, whose team also undertook this exercise, told us that the combination of “design thinking and SAP Fiori apps have helped us simplify our business processes resulting in increased user adoption and lower processing times.”

    We hope you find this process useful in your quest to build intuitive, user-centric business apps with SAP Fiori.

    --Sana Salam

    About Sana Salam
    Sana Salam is the president and founder of Sodales Solutions Inc., an SAP-certified partner specialized in Enterprise Mobility, User Experience and Big Data solutions. Before starting Sodales, Sana worked as a turnaround project manager where she revived derailed IT projects. Sana’s passion for helping enterprises simplify their business by humanizing technology led her to found Sodales. Her firm uses SAP technologies and user experience methods to solve business complexities with a design thinking framework. The Sodales team has won several design awards, including the SAP Mobile Apps Challenge for Microsoft Windows 8 and the SAP Google Apps Challenge. Sodales was the first SAP partner to certify a Fiori app. Sodales is driving innovations for SAP customers in the areas of SAP® smart business analytics, IoT apps and SAP® S/4HANA extension apps.

    Page 1 of 8 1 2 3 4 5 6 7

Search Engine Friendly URLs by vBSEO 3.6.0 PL2