Successfully reported this slideshow.

JavaCro'14 - Is there a “user” in your user interface – Ladislav Mačkala


Published on

Do you know your users? Are your users engaged in the development of their business application? Do they enjoy working with your application? Developing a complex information system is a challenge for any development team. System architects and developers often prefer to concentrate on technology, data model and business logic, in the process neglecting the user interface. They forget that user interface is the only part of your information system that users see, and often the most important metric of usability and quality. High-quality user interface is not just a matter ofengineering, but also of social skills and life and business experience of developers. Make your customers happy!

Published in: Technology
  • Be the first to comment

  • Be the first to like this

JavaCro'14 - Is there a “user” in your user interface – Ladislav Mačkala

  1. 1. Is There a "User" in Your User Interface Ladislav Mačkala IT director, Podsjetnik d.o.o
  2. 2. About me 18+ years of experience in Java development and relational database design and implementation Holding B.Sc. And M.Sc. in Computing Have lead Java development teams in several software companies in Croatia Currently leading IT and Marketing department in medical tourism company
  3. 3. What is this presentation about? About my experience in GUI development About importance of listening to your users when developing GUI About user-developer impedance mismatch
  4. 4. Motive A real-life example Application 1: CRM developed in-house, custom-tailored, 1 year in production, cca 50 users Application 2: ERP made by a domestic software company, off-the-shelf product, 3 months in production, cca 10 users Some users use both applications – their user experience with each of them is drastically different!
  5. 5. Motive (part II) A friend of mine, a developer, showed me his DSL framework and generated server- side code. When I asked about the GUI, he answered: „Oh, that's easy.” Is it?
  6. 6. User – developer impedance mismatch End users and developers have different perception of the same application End users use it every day, in the predictive way, and want the application to MAKE THEIR LIFE EASIER! Developers want to make cool things, but in the end don't use these applications!
  7. 7. Goals To find what makes end users ("them") happy To find what makes developers ("us") happy To find ways to reduce user-developer impedance mismatch
  8. 8. The developers' side Developers love to create new, cool and interesting stuff Developers hate to do boring and repetitive things (like maintaining their own code) Developers are focused on technology Developers are in love with their models
  9. 9. The developers' side (part II) Developers think that the GUI they produce is much less important then their code and data models Developers think they are smarter than their users (danger!) Developers rarely want or can see their application through users' eyes – they rarely think of USER EXPERIENCE
  10. 10. The users' side Users use the application to do their job, and that which makes it easier Users want to be faster using your application, not slower Users don't want to adjust to the application, but want the application to be adjusted to them Users want the application to look good, because they look at it most of the time
  11. 11. The users' side (part II) Users want consistency while they work with the application – which means: they want to learn only once Users want the application to be fast - which means: they don’t want to wait for the application Users like colors, images, fonts, charts... Users are INERT, they don't like changes
  12. 12. Real-life stories Experiences of my team and my users Both good and not so good
  13. 13. Story 1: make your GUI logical Users want to be forced to use as little clicks/steps as possible Users want to learn things once and then to repeat them Consequence: my old users teach new users how to use the application during business rules education – without IT support!
  14. 14. Story 2: accelerate time-consuming tasks Creating offers for our patients Frequent operation Time-consuming: lots of manual tasks, lots of clicks Similar offers must be created from scratch
  15. 15. Story 2: accelerate time-consuming tasks (part II) Solution: implemented creating offers through "shortcuts", "shortcut" templates and copying offers Result: time per offer reduced 5-10 times (15 min. to 2-3 min. per offer), for group of offers even more Users actively participated in development and were delighted with that feature
  16. 16. Story 3: missing colors in the pallette We upgraded our infrastructure (SmartGWT 3.0 -> 4.1) The ColorPicker in the RichText editor doesn't have the same colors in the pallete And our users love the specific hue of pink that is now gone! Solution: not resolved yet – the possibility of riots not negligible!
  17. 17. Before (v. 3.0) After (v. 4.1)
  18. 18. Story 4: making application faster We accelerated some frequently used parts of the application by adding missing indices in the database We accelerated the frequently used reservation calendar with heavy refactoring and framework upgrade We removed some premature optimizations that reflected general application performance Consequence: nobody noticed! When we asked them if they noticed, they admitted that it seemed a little bit faster, but they “weren’t sure"
  19. 19. Story 5: making application slower We mistakenly deployed a new version with suboptimal SQL query in the frequently used part of the application We upgraded our infrastructure due to serious bug that could cause data corruption and some parts of application got a little bit slower. Consequence: our support lines got hot-red! They notice the slightest change in speed, if that change in speed means slower!
  20. 20. Story 6: who wanted it? One user wanted something trivial like italic font and red color to emphasize something – it was done in minutes and everyone was delighted! We made small auxiliary tool for our cashiers when they have to calculate percentages - it was done in an hour and they loved it! We have worked for days on a complex feature that wasn't requested by users but was crucial to implement from business perspective – some users noticed and nobody was impressed! Conclusion: it's not about how hard it is to implement something or how much time it took – it's about who wanted it in the first place and if it makes their life easier!
  21. 21. Story 7: protecting user from themselves Users want to be informed when they are trying to do something wrong Users want to be warned if their actions may result with some unpredicted situation Users don't want to be able to do things in several various ways, they want just one way Conclusion: it's better to unnecessary warn your users, than not to warn them at all!
  22. 22. Story 8: using colors and images We made main application screens full of colors, images and various fonts. Our users are accustomed to the layout of those views and can spot the vital information without much reading, just scanning. Conclusion: make your application easy to scan!
  23. 23. Conclusion Include your users in all phases of your development process! Listen to them! Don't assume what they want – ask them! Make them happy and they will be grateful and loyal! (maybe even do your job )
  24. 24. Q & A