Skip to Content
author's profile photo Anne Johnson

What is your professional GUILTY PLEASURE?!

Hey everyone!

Let me explain what i mean by 'guilty pleasure'! Ever since attending University, with focus on Digital Design (UX, UI, Design Thinking) I must admit that I have been the absolute nerd for something called Critical Design. UX'ers focus on building creating products with users and customers that give value to them, that make their lives better, that intercept the ideas of how the future could be. Basically when we make stuff as UX'ers, we are keeping up the pace with future tech, business and user experiences!

'Now, what is Critical Design then', you might think! Good question. It is the design practice of creating and something that is thoughtful, provoking - even out-right useless and confusing! It is about asking the WHY are we living as we are currently, and how are we so well trained to see our living as the only right one. How on earth would that fit into our UX process?

You see, by creating something that is provoking or confusing, we are helping ourselves break out of the habit of accepting the current world as permanent and unchangeable. I itch to sneak Critical Design into our SAP practices!

Anyway, I haven't sorted out the logistics on how we could disrupt SAP like that just yet, so I'll be wringing my brain and slowly push it onwards.

Do you guys have similar guilty pleasures that just sits somewhere in the grey matter? For example, I once thought it could be cool to make small and simple games on UI5, just for the sake of ushering in the paradigme of Homo Ludens! :-)

* Please Login or Register to Comment on or Follow discussions.


  • Aug 08, 2019 at 04:41 PM

    I love that "Critical Design" concept - I might use that word next time I put up a paper mock up that goes against what everyone expects :)

    One of my pet peeves at work is dreaming big. I like to set "unicorn goals", and ask "I you had a magic wand, what would you do with it?". It helps in making people think of a better situation than the statu-quo, especially when the general state of mind is that there is no advantage to changing the statu-quo.

    • Aug 12, 2019 at 01:27 PM

      Dreaming big is what is going to make it big!

      You see that in Science Fiction - what was a big dream in the past is reality now!

      We should definitely put that into our daily life! :D

  • Aug 09, 2019 at 06:34 AM

    I know some hardcore techies who are very good at writing confusing and even downright useless UIs. But I suspect that isn't what you mean.

    I started programming ABAP Objects. That was disruptive enough - people without OO knowledge couldn't read my code. (Those who did, found them very easy to understand).

    Nowadays I find coding for ABAP unit tests and using TDD causes significant bafflement to some.

    In both cases, although it disruptive, they bring real benefit. I very seldom feel guilt about anything though.

    • Aug 12, 2019 at 01:25 PM

      I think you're right - we shouldn't feel guilty about doing good things! If it helps everyone and makes work more fun and/or useful, then we should go ahead and do it.

  • Aug 13, 2019 at 06:12 PM
    "even out-right useless and confusing"

    SAP is already nailing this Critical Design thing. :)

  • Aug 14, 2019 at 01:30 PM


    Considered long if I have a story to contribute. Thought long: 'Naa, that's not fitting.' But somehow it's related.

    My passion is speeding things up. Can't stand (unnecessary)tedious repetetive work. Don't give anything about comments like: 'We did this ever since this way.' If you see inefficiency, do something about it*.

    *Given you are able to comprehend the full complexity of the matter :-).

    We had a database system(no names!) building a complex multilingual print publication. At first the data model grew bent to some system internal limitations. The standard exporting tool was unable to resolve complex foreign key relationships. Result was a system friendly data model but not very user friendly. The process grew slower and slower because it always exported everything and the logic behind had to extract the essence.

    At some point the pain threshold was reached to redesign everything(@Danny Lacerte: yes, this was also some unicorn goal). A publication took 45 minutes at that moment. Using the system's API allowed to built the data model in a more 'natural' way. Having learned what we need enabled us building it right this time. With a smart data model everything seemed to snap into place. The standard UI was sufficient again because the data was where the user expected it(Not where the system could use it). The publication via API took only, what it needed.

    By the time the unicorn was finished, conventional publication times reached 90 minutes. The unicorn delivered in 3 minutes. That's magic. Hmm. It was magic. 6 years, ago.

    Now we have a reputation to preserve :-). Magic level is hard to maintain, when users get used to it.

    Unicorns DO exist. Magic IS possible.

    Keep up the good work, folks.

    • Aug 14, 2019 at 11:37 PM

      Oh this is quite relevant! :D

      How, if i may ask, did you manage to push the change?

      How did you convince your coworkers to go from we've-done-it-like-this-forever, to lets-try-this-new-thing?

      • Aug 15, 2019 at 01:17 PM

        Thank's for the unicorn.I like it!

        Good question. I didn't really had a plan how to convince my colleagues. Reflecting right now how everything happened...

        Did you ever hear of sculptors who claimed their sculpture was always there? They only had to remove the clay?

        The situation then: We were a really small team. No backup for any of us. Consultants built a XSL-T Script that processed the XML output of the database system. While they did remarkable work, XSL-T is simply not the proper tool for shuffling data to that extend. It's still used for adding formatting information to the raw XML publication. But for reading, slicing and dicing data you need a proper programming language. The Script was tailored around the first product segment. Every segment brought new challenges, which took quite some time until the consultants got it right. Every segment made the standard exports bigger and the overall process slower. And we were far from finished... More flexibility, products and countries were needed.

        Impending doom can be quite a motivator.

        (convincing) factor 1: Extrapolate the status-quo with it's consequences. Which meant a mid-term collapse of the process. Too many users worldwide wanting too many publications which take far too long. Ever heard of scalability problems? Had no issues argumenting that.

        What's the solution for that? Think of something, the consultants answered me. The database system came with a Java API. I can hear some of you sigh, but Java is still a formidable programming language. Wasn't really a pro back then in Java, but took up the challenge(Still consider myself not as a real pro, but learned one or two meanwhile). My colleagues were either knee deep in ABAP or not IT, at all. So it was me or nobody.

        Started with some table readings and developed a feeling for the API. Googled some how-tos. Had luckily no legacy applications to manage and had some time to spare for experimenting(those were the times...).

        Factor 2: Someone needs room for experiments in ones daily work.

        Sketched an overall plan to replace the existing process end to end. Replacing DB->13 XML Standard Exports->Huge XSL-T processing to single XML file with formatting info->PDF Formatter->PDF with DB->Single XML File via Java API->Quick XSL-T formatting info adding->PDF Formatter->PDF. A big benefit among others was a true separation of Layout(XSL-T) and Data Shuffling(Java). Which ended the total consultant dependency.

        Factor 3: Think your solution through. End to end. No ifs. No whens.

        Next step was a POC. Putting the first tables in context and make your coding tell you what it does in debug output or logging. With that technique you don't need a debugger. Learned it digging into XSL-T. The first thing my stream lead saw was debug output sketching a rough structure of the future XML publication.

        Factor 4: Don't make too much fuzz too early. Showing something that works saves you lot's of convincing. Even if it's only the first percent.

        So my stream lead was game. He had no extra work with it and no one else, as well.

        Factor 5: (Quite obvious) You have less resistance if your idea means little to no extra effort to others. Distribute the workload well.

        Alas for my vision I needed one thing from him: Another XSL-T Script which consisted only of formatting. Don't know how he convinced our CEO to give green light to another consultant budget.

        Factor 6: You can't control everything. For some issues you need the skills of your colleagues. Treat them well. Grow a trustworthy team. With diverse skills.

        Picked for diverse questions only specific colleagues to discuss it. Big appointments mean often no outcome. Coined the saying: 'Either you have an appointment or a decision' :-).

        This was the time to kick the unicorn production to overdrive. No more objections. The consultants produced a new Script and I saw the unicorn clearly at the end of a long but visible road prancing on a distant meadow. The sculpture stood shiny at the end of a 27k lines of code long road.

        Every now and then showed some progress to keep the spirits high. Took some sporty interest to make the coding as quick as possible. Wanted to break the sound barrier. Tweaked the algorithms further and further. Experimented with data structures perhaps unknown in any book. Created parallel structures. One structure had the bulky data, the other had the same shape but contained only indices and meta data. Used the fat version once and the slim version frequently.

        Factor 7: Make the colleagues 'wow' every now and then. Producing correct output fast is a real motivator.

        Reached the meadow 6 years ago. Oh my, time goes by.

        You asked me how I convinced my co-workers. Perhaps it was only a byproduct of being in enthusiastic work mode. I really loved my work back then.

        Conclusion: Find a way into enthusiastic work mode!

        Boy, this answer grew longer than expected.

        Have a nice day,

        Manfred Klein

        • Aug 16, 2019 at 12:11 PM

          Thank you for the explaination, Manfred! It makes great sense, and there are some good notions in it.

          You ought to publish this in a blog and go into details about all of the Factors - they could help a lot of people who are struggling with the same kind of issues :-)

          Have a fantastic weekend too!


  • Add a comment
    10|10000 characters needed characters exceeded