Skip to Content
Author's profile photo Graham Robinson

On Designers & Developers

I have just returned from the SAPPHIRENOW and ASUG Annual Conference in Orlando where I was fortunate to be part of the Media & Analyst Program for the event.

Many others have written about their overall impressions of the conference so I won’t go over old ground other than to say it was huge!

Whilst there I had several formal and informal chats with Sam Yen – SAP’s Chief Design Officer. Sam is always generous with his time and willing to share his thoughts. He is responsible for SAP’s renewed focus on the user experience that we see delivered through products like Fiori and Personas.

If you are interested here are some of my previous blogs that cover – to varying degrees – other conversations with Sam.

Changing perception of usability at SAP

Fiori arrives – first impressions and thoughts

What is SAP Fiori? Maybe it’s more than you think

Coincidentally whilst travelling home I came across a post from Ivana McConnell titled Designers And Developers: No Longer A House Divided. In it McConnell talks about how the roles of Designers and Developers are blurring together and the challenges this presents. She sees this change manifest itself with designers becoming pressured to stay on top of development technologies, and vice versa, and points out that really this is just a symptom of a communication problem between the two groups. Her suggestions include…

“…rather than focusing on understanding the mechanics of each other’s work …,
we should focus on softer skills,…”  – emphasis is Ivana’s

We can only become better designers and developers by learning to communicate better with one another.

No argument from me. A designer and a developer working well together will produce better results that a designer who also codes or a developer who does the design. We have all seen those wonderful screens produced by developers who think a palette of 256K colours means you should use as many of those colours as possible. 🙂

Sam Yen pointed out another challenge – that of how to scale the design piece of work when there are so few designers working with developers? What is the ratio of designers to developers in your organisation? A quick Google search and I found responses that suggested optimum ratios from 1:2 up to about 1:10.

SAP have been focusing on design for a while now and their ratio is at least an order of magnitude higher. I asked a few people from some of the larger system integrators on the SAPPHIRENOW show floor and there was no one claiming better than 1:1000. Most of their standard “development” teams contained no designers at all. We seem to have a problem scaling-up the design piece.

In some respect the SAPUI5/OpenUI5 SDK attempts to address this issue by providing “pre-designed” pieces of the puzzle to help keep developers on the straight and narrow. The SDK contains documentation on a large suite of controls that follow consistent design patterns. It also includes samples that don’t just show developers how to code individual controls but also how to use them to build a complete application.

Screen Shot 2015-05-11 at 3.31.04 pm.png

And there is also the Fiori Design Guidelines to help. This includes design stencils that can be used in the Axure tool for creating wireframes and mockups. Well worth a look.

Screen Shot 2015-05-11 at 3.33.29 pm.png

But the problem of scaling the design piece still needs to be better addressed. SAP have some ideas on this. We can expect to hear more later in the year – perhaps at SAP TechEd.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Joao Sousa
      Joao Sousa

      Fiori Guidelines are a great help to compensate for the lack of designers. Like you say the ratio of developers vs designers is very bad nowadays.

      In the past I don't think enterprise customers valued design enough and people got away with the ugly ALV which was cheaper, but times are changing. In a mature environment processes are improved by a better UX, and I'm already seeing a shift.

      Author's profile photo Matt Fraser
      Matt Fraser

      Heh. In my org we're still trying to get old-fashioned reports migrated to ALV, which would be a big improvement right there... think how much more we could achieve!

      Author's profile photo Former Member
      Former Member

      Working in consultancy, I can count on zero fingers the number of times I could convince a customer to pay for a.n.other resource on a project that they don't see as adding value...

      Consultant - "we'll have a designer working 3 days a week for 6 months through the design/build phase, to ensure the developers are meeting the overall UI/UX guidelines and the app delivery is consistent with your user's requirements"

      Customer - "sorry no, we don't want to pay extra for someone who isn't building."

      6 months later...

      Customer - "why do all of our app's look like they've been built with the 'data goes here' design approach?  They're horrible, we won't pay until they've all been changed and look better."

      I agree that the modern world and multitude of options available for delivering quality UI/UX solutions really do need more design input, and I definitely agree that developers aren't always (if ever!) good designers.  The challenge is that many customers, project managers and others in control only see the bottom line cost of resource and it is an uphill struggle to change these perceptions.  I've seen this happen around security, testing, change management and basically anything that isn't perceived to be a core build activity.

      Our industry needs a fundamental adjustment in how consultancies present proposals and costs, to focus more on overall benefits realisation rather than pure cost of build, and customers need to get away from focusing only on the number of man days and total cost.

      Maybe consultancies should use central design resource and their cost is built into the normal daily rate?  I'm sure there is an easy fix, it just needs more and more to sign up to the approach.

      Then, I hope we start to see more widespread use of much needed resource, such as designers, across projects and we can see the benefit of the softer skills Ivana mentions and Graham references here.



      Author's profile photo Graham Robinson
      Graham Robinson
      Blog Post Author

      Thanks for your comments Gareth. There is another blog right there - how about you write it? 😉


      Graham Robbo

      Author's profile photo Matt Fraser
      Matt Fraser

      Good takeaways, Graham, and a conversation I was just having with a colleague a few minutes ago, about designer:developer ratios (uh, that would be 0:3 in my org).

      Author's profile photo Jelena Perfiljeva
      Jelena Perfiljeva

      A designer?! Bwahaha, I wish we had a second developer. 🙂 Oy vey...

      Many SAP customers (especially small/medium size companies) would do perfectly fine with "pret-a-porter" UI design instead of the designer grade one. But the guidelines need to be clear and easily available. Then it would be just the matter of developers (including SAP's own - sorry, we've seen them "not walking the walk" before) following the guidelines instead of reinventing the bicycle or rather producing their own ugly incarnation.

      Also the "ready to wear" design should be created by really talented designers. Great design works just as well at a discount store as on a fashion show runway. But not so great design will only get worse if it goes to mass production. So SAP better have an equivalent of Calvin Klein working on this. 🙂

      Author's profile photo Sergio Guerrero
      Sergio Guerrero


      this is a great post. I have had an opportunity to explore the guidelines, the sdk, the mobile library and these are all great resources for developers and designers. I believe that nowadays developers have a responsibility to not only be developers but also think simple and as you mentioned before the FIori Guidelines are a great way to stay within the lines of what we need to do going forward.

      for those who are new to Fiori, I also want to recommend to take a look at the prototyping kit which you can find in the Fiori Guidelines page. it is a great source and you can easily create a design for your next fiori application.

      good luck!