• Axure Blog RSS Feed

    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.
    Published on 04-15-2016
    1. Categories:
    2. News



    Axure RP 8


    We are excited to announce the release of Axure RP 8, giving business and UX professionals new diagramming, prototyping, and specification features that help them design the right solution and align their teams. For large teams and enterprises, new collaboration features and an option to install Axure Share on-premises help to streamline the software-planning workflow. We can’t wait for you to try it out!

    Existing customers can update to Axure RP 8 for free. If you don’t already have an Axure RP license (any version), you can download and use a 30-day free trial.



    Axure RP 8 has a number of significant enhancements to improve the software-planning and prototyping process.





    More Versatile Diagramming
    Axure RP 8 has a new pen tool for drawing custom shapes. It also comes with a built-in library of more than 600 vector icons. Improvements to flow diagramming include the ability to add and position connector points to any shape or image. New line ends and curved connectors allow for even more customization.






    New Interactions and Animations
    Axure RP 8 extends the core prototyping functionality with new events, actions, and animations. You can flip and rotate widgets with animation, as well as resize from an anchor and dynamically set opacity. It is also now possible to perform simultaneous animations on widgets. In addition, we’ve enhanced the repeater to make prototyping data-driven grids easier.






    Richer Specifications
    We’ve enhanced widget notes to support rich text formatting. Links in the text are now clickable in the HTML prototypes so you can link to related documents or issue-tracking solutions. In addition, the new sidebar in the HTML prototype includes all of the widget notes on the page in addition to the page notes.

    Beyond notes, a new Snapshot widget has been introduced to make it much faster to specify the flow through an interactive prototype and keep that documentation updated.







    Improved Team Collaboration
    Axure Share, the cloud platform for publishing Axure RP projects, can now host team projects so you don’t have to set up an SVN server to take advantage of co-authoring and revision histories. You can also set up a private version of Axure Share server on-premises with the Enterprise Edition.

    Widget libraries can now be created as team projects and hosted on Axure Share. From Axure RP, you can load libraries directly from Axure Share, making it easier to ensure team members always have the latest version of a shared library.






    More Efficient Environment
    Axure RP 8 has a cleaner layout that gives you a larger view of the design canvas while arranging functions so you can work more efficiently. For example, a single Inspector has replaced three panes and has been reorganized to make it easier to find properties.






    Redesigned HTML Sidebar
    The sidebar in the HTML prototype has been redesigned to have a more modern look and also to make it more extensible. For example, a new Console section has been added that allows you to see triggered interactions and variables as you interact with your prototypes.


    New Editions and Subscription Options
    Axure RP 8 is available in three editions: Pro, Team, and Enterprise.

    • Pro includes all of the prototyping and specification features of Axure RP, including advanced interactivity and annotations, and lets you publish files to Axure Share with unlimited reviewers.
    • Team is geared towards teams who need to work on projects simultaneously. It has the features of Pro plus co-authoring with Team Projects via Axure Share or SVN.
    • Enterprise has all the features of Team, plus the ability to publish projects and host Team Projects on on-premises Axure Share servers with the ability to manage account roles.

    Perpetual licenses are $495 for Pro and $895 for Team. We’ve also introduced subscription licensing options—$29 a month for Pro, $49 a month for Team. The Enterprise Edition is available only as a subscription and costs $99 a month per user.

    We are grateful to the thousands of customers who participated in the Beta program. Your honest and generous feedback have helped us take Axure RP 8 to a new level. Thank you!

    Click to Tweet: "Axure RP 8 is now available"

    Published on 03-07-2016
    1. Categories:
    2. News,
    3. Axure RP 8 BETA

    With the final release of Axure RP 8 now weeks away, we wanted to share the new pricing and product lineup with you. This will be the first time the price of Axure RP Pro has changed in nearly 12 years. There will be two key differences from the current offering:

    • Axure RP 8 will be available in three Editions: Pro, Team, and Enterprise.
    • We are introducing a subscription option, in addition to the current perpetual licenses.

    Here’s a quick breakdown of the different Editions. We’ve also put together an FAQ below to help answer some questions you may have.

    PROTEAMENTERPRISE (new in 8)
    For professionals creating prototypes and specifications.For teams co-authoring prototypes and specifications (check in / check out with revision history).For companies requiring an on-premises solution for publishing and co-authoring prototypes and specifications.
    Perpetual: $495

    Subscription: $29 / Month
    Perpetual: $895

    Subscription: $49 / Month
    Perpetual: not available

    Subscription: $99 / Month
    All of the prototyping and specification features of Axure RP including advanced interactivity and annotations.

    Publish to Axure Share with unlimited reviewers.
    All of PRO plus:
    Co-authoring with Team Projects via Axure Share (new in 8) and SVN.
    All of TEAM plus:
    Publish to and host Team Projects on on-premises Axure Share servers with account roles (new in 8).

    For more information, email contactus@axure.com.

    Answers to Frequently Asked Questions

    Is Axure RP 8 a free update?
    Yes. If you currently have any version of Axure RP, you can update to Version 8 for free. Customers currently using the Standard edition will be updated to Pro. Customers using the Pro edition will be updated to Team.

    What happens if you buy between now and the release?
    The new prices will take effect the day of release, which we anticipate will be about a month from now.
    • If you buy RP Standard now for $289, you’ll get a free update to RP Pro 8 ($495) when it is released.
    • If you buy Pro now for $589, you will get a free update to RP Team 8 ($895).

    What happened to Standard?
    The Standard Edition, which doesn’t have the documentation and co-authoring features of Pro, was introduced in 2012 for customers who use Axure RP less frequently or on smaller projects. With RP 8, you will be able to subscribe to Axure RP Pro monthly for $29 / month and have access to the full feature set.

    Is Pro different in 8?
    Yes. The Pro Edition in Version 8 will not come with team projects. If you want to co-author with team projects, you will need the Team Edition. Existing Pro customers will get a free update to the Team Edition in Version 8. If you’re new to team projects, this article goes into further detail about team projects in Version 8.

    Why subscriptions?
    Some customers have asked for more pricing options, especially when working on shorter-term projects. The subscriptions are meant to accommodate those requests. For most customers who plan to use Axure RP regularly, we would recommend the perpetual licenses for RP 8.

    If you have any questions we didn’t answer here, please email us at support@axure.com.

    Thanks again to everyone who has participated in the Beta. Your feedback and comments have genuinely helped shape Axure RP 8. To learn about the enhancements to RP 8 in the past few months, please read this article.

    We can’t wait to share the final release with you!

    Thank you,
    Victor

    Page 1 of 8 1 2 3 4 5 6 7

Search Engine Friendly URLs by vBSEO 3.6.0 PL2