Skip to Content

I’ve had Personas installed in my development system for a few weeks now, using it as my primary interface to the system whenever possible and redesigning some of the transactions I use a lot. This has helped me discover its capabilities and limitations, and also given me an appreciation of some of the wider issues beyond just designing individual transactions. For now, though, I want to give an overview of my thoughts after playing with it for a couple of weeks.

One of the first things most people seem to do is redesign the main SAP logon screen. Remove the toolbars if you don’t use them, add a few buttons for common things you do, add a pretty background. Those are all easy to do, and it is a good way to get started. You can get something that looks nice very quickly. Conveniently, the corporate identity for my organisation uses colours that blend very nicely with the webgui’s standard blue, and we have some standard images that work well as background images. My login screen currently looks like this:


Then you go off to another transaction and get the standard look and feel and you instantly realise the Personas is not about redesigning individual transactions. It is about redesigning the whole user experience. You need to work on a consistent look and feel for every transaction a user will encounter, or their experience will be very disjoint. That’s where the real work is in a Personas project.

To give an example of what you can achieve with a more complex transaction, here’s where I’ve got so far with ME21N – Create Purchase Order:

screenshot 2.jpg

If you are familiar with ME21N you’ll realise this is a whole lot simpler that the standard transaction. I’ve removed a lot that we don’t use, including all of the tabs in the item details section. Most of the time we only use just two fields from that whole section! The header has been reduced to some radio buttons and a pop-up menu. This is a work in progress and there’s more work to do on it, but for most of our users this would work perfectly well and be much more understandable.

There are things that don’t work as well as I’d like. One of the main reasons for this is that Personas is really just re-writing the standard webgui screen and can’t modify the behaviour of that screen in any way, and of course the underlying dynpro transaction has no idea what Personas has done to its layout! For example, in ME21N above the table control for the line items is hard to deal with. It changes size depending on how much room it has in the standard layout, even if that’s not necessary in the Personas layout. I’d love to make it a fixed size (most of our POs are just a few lines long anyway) and lose the scrollbar, for example. I haven’t found a way to do that.

One thing I haven’t mentioned yet is Personas scripting. Personas gives you the ability to record actions – button presses, menu items, entering data into fields, running other transactions – and attach that (essentially a BDC session, for the developers among you) to a button. These scripts can interact with extra gui elements you add to screens to help with merging screens in multi-screen transactions. They can also run transactions, grab data, and display it somewhere else entirely. For me as a techie, scripting is the most exciting feature of Personas. There are lots of possibilities for automation, not all possible with with the scripting facility as it exists today. I’m hoping future developments will enhance the scripting capabilities. I’ve blogged a brief Personas scripting overview.

We will shortly be kicking off our Personas project and that’s where the real work will begin. There’ll be more blogs to come, I’m sure 🙂

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Gareth Ryan

    Great stuff Steve.

    One thing I’m curious about (and apologies if this is obvious but I’m not very close to Personas yet) is how these sort of changes can be rolled out to users?

    Do you have the power to set up customisations of your system and then push these out to users using authorisation/something else to control who sees them?

    Or more scarily, can all users start to meddle with their transactions? (Can see lots of fun helpdesk calls via that method!)



    1. Steve Rumsby Post author

      The tailored screens – called “flavors” – are stored centrally in the NetWeaver system and can be made available to individual users or groups of users. So, a central team could develop flavors and assign them as appropriate to the user. They also transport, so you develop in a dev system and transport through QA to PROD as with everything else in SAP.

      There are authorisation controls that determine who can do what within Personas. You can allow all users to design their own screens. As you say, that has the potential to create chaos, so you can restrict that. The “Basic View” – the completely untouched standard SAP version of a transaction – is always available, though, so users can switch back to that in case of difficulty.

      I expect we might run an arrangement with some expert users allowed to develop flavours that are useful within their specific department, and then centrally we might pick them up, tidy them them up, and roll them out further.

      The management of all the flavors is something I haven’t thought much about yet, but I do think it will require some serious thought before we roll out too far.

      Maybe a blog on Personas administration is in order?

      1. Gareth Ryan

        I’m genuinely surprised (in a good way) that this all sits inside the normal transport mechanism.  That can only be a good thing.

        Yes, you definitely need to think about rolling this out – my experience with anything remotely UI/UX related is that the hardest part is the roll out and management.

        We all know users who will chop their own arm off to ensure fonts are the same size and the logo has a lovely 3D drop shadow effect on their reports but couldn’t care less that the monthly sales figures (or indeed cod lifetime) are completely incorrect 😉

        And yes, a blog on the admin side would be brilliant – everyone gets carried away with new tech without thinking about the implications for implementing, supporting and enhancing for people like you and I, so your views on this would probably be very well received. 🙂

  2. Uwe Fetzer

    Hi Steve,

    thank you for your (independent) view on Personas.

    Last year at Teched the presenters said that everybody who can design Powerpoints can also work with Personas. True?

    (ok, bad comparison, who really can design good slides? 😛 )

    1. Steve Rumsby Post author

      I think the design issues for Personas are similar to the design issues for Powerpoint, yes. If you are good at one you’ll be good at the other. I’m not very good at either:-)

      At the design level you have to think about the aesthetics and usability of each transaction (slide) separately, but also how they fit into a coherent set of transactions (theme) with a compatible look and feel. The mechanics of both are similar – drag and drop gui elements onto the page and format appropriately.

      I find I need to use Personas scripting a lot more than I need Powerpoint scripting (never), and so there’s a bit of a programmer mentality required that you might not normally find in a good Powerpoint designer. That apart the analogy is about right. A Personas project is much more about design than anything else.

  3. I. Kooyman

    Hi Steve,

    I have a question which I think you can answer, so I hope you can help me out!

    For a project I am trying to simplify the me21n transaction in Screen Personas, just like you are doing in your example. When I enter an item in the item table and press enter, the header data collapses and the item detail data expands. I want to avoid this because it isn’t good for the usability of the transaction and doesn’t look good after the transaction is simplified.

    When I look at your example, it seems like both your header data and item detail data is expanded, can you tell me how you did this?

    Kind regards,

    Iemke Kooyman

    1. Steve Rumsby Post author

      The standard ME21N transaction will not allow the header and item detail panes to be open at the same time. Open one and the other automatically closes. You can’t change that behaviour. The only thing you can do is copy the data from those panes into custom fields that are permanently visible. I would suggest that is much easier to do with the fields from the header pane. In other words, create a custom header section and use a script to copy data from the standard fields into the custom fields, and then hide the whole header section. I think you need to do this rather than use tab caching on the header section as the table needs to be present in the underlying dynpro screen for caching to work.

  4. Steven Krozser

    Hi Steve,

    I realize this is an old post – but I am optimistic that you are now well on your (or finished with your Personas project)! Would you happen to have any other personas / flavours / templates that you could share pertaining to Purchasing related transactions?

    We are in the early stages of getting a proposal to bring in Personas – and I plan to create some simple business cases on why/how our Purchasing area could benefit from this application.

    1. Steve Rumsby Post author

      I haven’t done a lot with ME23N, besides hiding a few tabs in the header and tweaking the colours and background a bit. Those things work quite nicely in v3.



Leave a Reply