Pegaworld 2017 Recap

This year I wrote my Pegaworld recap on LinkedIn’s Article platform:

Pegaworld 2017 Recap

Pegaworld 2016: User Experience Notes

As a follow-up to my writeup on the PW2016 conference, I discovered some notes I collected during bootcamp.

25 Reasons to Care About UX Design:

1. Changing your mind is expensive-the more you can define in advance the better
2. $1 today saves $100 tomorrow in DEV costs…do more whiteboard
3. UX has high positive and negative ROI
4. YOU DONT want t spend time/money on maintaining apps
5. UX makes your MVP min viable product worth something
6. UX cuts costs across the board
7. You care about your brand
8. It takes 50ms to decide if l like what you are selling
9. 94% of first impression are design related
10. You care about NPS
11. YOUR competitors care
12. Don’t just do what competitors do
13. U want people to stay longer and discover more
14. Design tells more about yo than your produc
15. UX is the product
16. UX I s not all abt user
17. Builds loyal customer
18. You want users working, not figuring out ui
19. Create strong org advocacy
20. Bad UX is pretty obvious
21. Good UX also provides clear structure
22. To be cyst centric, consider UX
23. Fixing UX problems can be easy-85% of UX probe can be solved by testing with 5 users
24. Build ui with a goal, not a look
25. Bad UX wastes time, money and may kill you

Design For Pega:

• For navigation controls, use color, position, and size to increase or decrease an element’s visual weight
• Use Consistent icons, labels, titles, and instructions throughout the portal
• Motivate users to visit or use the tool frequently and share feedback
• Provide clear exit strategies for the user and ensure there is always a “back” or “cancel” option for each process
• UX is everyone’s job- whether defining requirements, developing screens, or testing, everyone should share the burden of creating a relevant user experience

For more, visit http://design.pega.com

Pegaworld 2016 Recap

Pegaworld 2016 June 5-8, Las Vegas, NV

This year’s conference was hosted at the expansive MGM Grand Casino and Hotel in the midst of an early wave of triple-digit weather. The setting was grand, the location was hot, but the real action was on the main stage and breakout sessions. The headcount tallied 3,300 people and as Pega CEO Alan Trefler said during his keynote, the conference has grown so big no city other than Vegas could host the event.

The Keynotes

Day  1 of the conference started with a rousing warm-up by DJ Ravi Drums (http://ravidrums.com) and his Tesla Drum Kit. The conference then opened with Alan giving his pitch for the impact his Pega 7 product has had; user experience design was sure to be a hot topic this year. Model-driven was a key theme indicating to me the growth of business-administered Pega applications.

The Day 1 keynotes were interesting in that we heard senior leaders from Phillips Healthcare and Allianz relating the business outcomes that their Pega investments have contributed to. A common theme was the power of analytics in driving customer engagement. One could not avoid Pega’s global reach given the diverse ensemble of keynoters with accents that spanned the globe. The point driven home by @pegakerim, as he described the art-of-the-possible with robotic computing (justifying the acquisition of OpenSpan) in his Instabul-esque voice.

Day 2 keynotes were by-far the best Day 2 keynotes of any Pegaworld conference I have previously attended. The ice breaker was an interesting video (watch here) highlighting the Cisco Global Business Services solution built on Pega 7 which eliminated 93% of manual touches in the order entry process. The panel discussions once again reminded us of the importance of judiciously applied analytics to drive digital transformation. The final keynote from Gerald Chertavian, Founder and CEO of Year Up provided a very human-centric perspective on the reach of Pega and especially CEO Alan Trefler. YearUp is a fascinating and inspiring program that helps disadvantaged youth acquire professional and technical skills that position them for immediate and long-term success. Trefler and his wife were early supporters of the program which provides, among other services, Pega-skills training to poverty-effected young adults. The success stories were very moving.

Breakouts

My pre-conference objectives were to attend as many sessions as I could relating to user experience and design. The offerings seemed to be tailor made for me since I found that every breakout timeslot included at least one UI or UX discussion, including the Wednesday bootcamp sessions. Read below where I summarize the notes I collected across the sessions.

Sessions I attended (links to recordings will be added once published)

Monday	Tuesday	Wednesday
Accenture: Creating a Breakthrough User Experience that is Captivating and Differentiated-and Delivers Results	Go Ahead – Create Rule-changing Customer Experiences	Beyond Visual Design: Creating Substantive UI
Xerox Leverages Pega to Maximize Field Service Effectiveness	Driving Excellence-Center Of Excellence Panel Discussion	Turning Desktop Apps into Enterprise Mobile Apps (and Vice Versa!)
User Experience: whose job is it anyway?	25 Reasons Why You Should Care About UX Design	How Do I Do That? An Immersive Workshop on How to Create Exquisite Pega UI

Highlights:

• Steve Weinswig (Fjord) and Jennifer Spinosa (Accenture) – this session reminded me that  User Experience is a cultural thing, even in enterprise software. Both business and IT need to have a level of expertise in user experience design. And a mandate from C-suite can help drive UX as a priority in our product teams.
• Pega Field Service strategic application has definitely matured since we first saw it demonstrated three years ago. Most interestingly, Xerox took a mobile-centric approach to insure that its field staff were able to leverage the provisioned mobile device as a primary workstation.
• Several sessions reinforced the impact of user experience, even in Enterprise application development. User Experience should be the responsibility of both business and technical teams. A well-skilled UX lead is ideal, but in the absence of a UX lead all participants in a project should see UX as a priority. The business should define requirements that specify, in as much detail as possible, the user experience expectations. Technical teams should understand the techniques for configuring Pega applications with an awareness of modern user interfaces and UI design patterns.
• Pega Agile UX Design method incorporates UX into every stage of development and allows for iterations on the user interfaces (all too often we build UI after all the core functionality works)
• A key takehome message: while Pega allows for responsive deign, application design teams should build Mobile UX and Desktop UX (in fact any channel UX) as separate efforts. Depending on the channel, user expectations will differ and should be accomodated through appropriate layout and UI design patterns.
• Another takehome: do your UI design offline (paper or whiteboard) then build in Pega (don’t do what you learned in DCO training)
• The launch of Design.Pega.Com provides resources to provide key insight to the why’s and wherefore’s of UX design along with technical articles instruction developers how to build for UX.
• Pega Exchange is a new community offering hosted on the PDN to allow users to share reusable components.
• Enhancements to Pega 7 Express are coming with Version 7.2.1 that allow more functionality for form layouts–looking forward to that!!

UPDATE: checkout my notes from the UX Design bootcamp here

Disclaimer: The author is employed by Cisco Systems, Inc. however none of the content in this post or on this blog in sanctioned by Cisco Systems, Inc.  and should not be considered as an endorsement by Cisco Systems, Inc.. All opinions expressed are the solely attributed to the author.

HHonors Wifi Blues

I have stayed frequently at four different Hilton-brand locations (Austin TX, Milpitias CA, San Jose CA and Savannah GA). Whenever I try to connect to the HHONORS network on my iPhone 6, ipad mini or ipad with Retina display, no connection can be made. Here’s what happens.

I see the list of available networks (HHonors, ATTWifi, etc.).  I select HHonors and then see a checkmark next to ‘HHonors’ on the Wifi network section in the Settings app, but I never get the WiFi connected icon on the top of my screen (and subsequently cannot load any web pages or use any connected apps).

Googling, I see a number of posts about not being able to load pages after connecting to Wifi. I’ve seen posts about different Safari settings (autofill, etc.)- but those give me no joy. In fact, since I never see the wifi icon, Safari never comes into the scenario.

Calls to the helpdesk include typical advice “close all apps”, “power down the device”, “airport mode”, “Forget Network” and try again. I even tried setting the DNS manually to 4.2.2.1 and 4.2.2.2 (no idea what that is but it showed up in the FlyerTalk.com forums).

Strangely, I do see that the device does receive a local IP address but no connection ever completes. Interestingly my Macbook Pro does not have this issue, so I suspect it is an iOS issue.

I would love to see someone dig in and solve this. I have done the call support desk…tweet @Hilton @EmbassySuites… only one time did someone provide a fix by doing something where tech support was able to see my device on the network and they reset some network thing.

If anyone should stumble across this post and find a solution, please share so we can solve this!!!

 

 

Pega Certification Study Guides

This post includes links to the  Pega study guides I created as I prepared for certification. Each is based upon the Pega-provided exam blueprint.

Pega CBA Study Guide

Pega DCO Architect- study guide

“What’s New in Pega 7.1.8” Webinar Recap

Pega 7.1.8 Feature Summary

So I just finished watching the “What’s New in Pega 7.1.8” webinar. It was recorded if you want to watch later(see links below for info). However, the two screen grabs I post here gives all the detail (my notes are below as well)

Pegaworld 2015 (Conference Highlights)

Last week’s Pegaworld 2015 was reportedly the largest Pegaworld yet with over 3,800 attendees. If you missed it, the keynotes are archived and available for streaming here. Also, most of the breakouts were recorded, so you can watch videos and review presentations on PDN.

Key Themes:

Design Patterns for iBPM (Part III)

The Beginnings of a Vocabulary

Several iBPM vendors have their own vernacular for describing their “capabilities”: Cordys/Fujitsu has their “Business Operations Platform”, Pega has their “Situational Layer Cake” and “Build for Change”. However these do not go far enough to help a business user describe how they solve problems in the iBPM platform.

Sure there is BPMN which attempts to give us a working set of building blocks for our process modeling activities. But this again is limited to the notion of modeling processes (visual representation) and does not prescribe the execution of a transaction within that process.

In the “Design Patterns” book, the Gang of Four precede their exploration of each design pattern by categorizing them into meaningful groups. This is a useful approach because it presents the ideas in a top-down fashion, moving through layers of abstraction to provide meaningful context to the underlying patterns.

An interesting sidenote is that Design Patterns need not stand alone and in isolation. Patterns solve for relationships (as described in Post II): what an individual instance can do, how multiple instances work together – including nesting relationships (a pattern might be comprised of several patterns combined together).

Just as in the “Design Pattern Book”, I submit that categories of patterns will help organize the underlying patterns in a way that will be intuitive to business architects and systems architects alike. Further I submit that iBPM design patterns must address both the business functionality provided by the pattern, and specific technical recommendations for practical implementation. Design patterns cannot succeed if they are just vapor-ware.

In subsequent posts I will expand upon a proposed set of Design Pattern categories. I will attempt to describe the intended business impact and the technical challenges which must be overcome within the design pattern.

Please like, share, follow or provide feedback in the comments section below!

Design Patterns for iBPM (Part II)

Great News! I have been given the opportunity to present at Pegaworld 2015! Along with , North America Practice Lead – Business Process Architecture (BPA) at Capgemini, we will discuss the importance of Business Architecture and the impact that Design Patterns can have in terms of accelerating time to capability. I will share background and relevant examples from Cisco’s Global Service Supply Chain. But more importantly (to me) I will present a Call-to-Action for iBPM practitioners (business and IT alike) to establish a well-defined set of Design Patterns to accelerate iBPM adoption.

So now, on with today’s post…Design Patterns for iBPM (Part II ). In today’s post I will share more thoughts around exactly what I mean by Design Patterns for iBPM (this is a preview/supplement to the content I will share at PegaWorld)

Design Patterns for iBPM (Part I)

Design patterns are a concept born out of architecture back in the 1970’s. The design pattern is intended to establish a working vernacular, or vocabulary, for application within a given trade or domain. Design patterns help to codify mutually agreed upon approaches to solving certain repeatable design issues. In physical architecture, design patterns might describe the basic components for designing a chair, a house, or a city.

Design patterns do not seek to define the specific implementation details at a granular level; a chair is a basic four-pillared, rail and stile construction– nothing here represents a design pattern. However, a design pattern for a dinner table chair might prescribe the best dimensions for comfort while eating at a table, aesthetic elements that differentiate a dining table chair from a lounge chair, and parameters for how a dining table chair can be readily adapted to different time periods or motifs. In this example, the design pattern can become a useful construct for future designers- best practices can be encapsulated in the design pattern so a designer doesn’t even need to consider the best aesthetic dimensions for a Queen-Anne dining table, or a comfortable lounge chair. Rather the designer can focus on choosing the best materials that fit the specific room or situation they are designing for.

In computer programming, the Design Patterns concept became legend with the “Design Patterns for Reusable Object Oriented Software”, published in 1996 by the Gang of Four (The book’s authors were Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides with a foreword by Grady Booch.) Many OO designers and developers have dogeared their copy of the “Design Patterns” book when contemplating how to best recreate a user experience using object oriented software in C++., SmallTalk or J2EE (Java). The design patterns helped establish a set of principles and archetypes for experienced software creators (as opposed to the now popular “Hacks”). Most of the best programmers at Apple, Cisco, IBM, and a whole host of great Bay-area startups, write code that is a thing of beauty. The beauty comes not from the complexity of the code or clever use of available hardware features for a given platform. The real beauty is in the simplicity, the tight organization, the reuse of common classes, and the dogged adherence to making their code “self documenting”–choosing variables and code logic that read almost like poetry…or at least more like human language than machine language.

To take the notion of design patterns and apply it to the Intelligent Business Process Management (or iBPM) domain makes perfect sense. For the very notion of a business process is an abstraction, for which there are already a full complement of terms, tactics, and techniques (BPMN for example). The promise of iBPM is that it will carry us forward from the abstract concept of a diagrammed business process, to a workflow that is executable by humans or machines, and informed by analytic models of past instances of the process. It is the intelligence garnered from past instances of the process that give us the “I” in iBPM. What has been missing in practice is the very thing that Design Patterns can help solve for: a lack of clear and consistent approaches to implementing iBPM has made this space one that is failing to deliver on its promise.

What has been missing in practice is the very thing that Design Patterns can help solve for: a lack of clear and consistent approaches to implementing iBPM has made this space one that is failing to deliver on its promise.

Design Patterns applied to iBPM is not an attempt to use or plagiarize from the “Gang of Four Design Patterns” book. In may be likely that many of the patterns from that book apply to the implementation of iBPM. However the intent here is to establish a working vernacular to help define constructs within the business process domains that will solve for basic design issues in a very general and repeatable way. The idea is to make ready a set of templates that a business architect might use to organize the iBPM solution thereby freeing up the designer to focus on the differentiating capabilities within the process.

In this series of posts, I will share my thoughts on the importance of iBPM design patterns. I will further seed what I hope will become a conversation on patterns which fit within a scheme of categories. I will then describe how I have seen each pattern applied in a real-world business setting (either of my own experience or through collaboration with colleagues). My interest is to accelerate delivery on iBPM projects, to inform solution designers with reliable approaches to solving business issues, and to establish a sense of order from which iBPM can become a craft worthy of appreciation and not just the latest techno-geekery.

Take me to Design Patterns for iBPM (Part II)