So, on the ride back home after a wonderful couple of days in Frankfurt, I started thinking about the question I asked the panel.
I had it well formulated in my head, but then the microphone turned my question into a bit of a scrambled mess. I hope I didn’t offend anyone!
My question to the panel was supposed to be what their experience was with backend developers who, thanks to Vaadin, become full stack developer and suddenly need to connect to the user and need to think about user experience design. Technically, they can write the code, but creating a good UX requires a specific skill set.
I was wondering what the experience is off the panel on this subject? And if they could share some lessons learned?
I didn’t mean to say “it’s not because they can that they should”
I loved the answer about even when creating an API, you need to think about the user, being another developer.
That’s a good question. As someone who joined Vaadin with some frontend knowledge, but definitely not a lot of UX knowledge, I think that Vaadin has helped me achieve a greater focus on UX part. That’s simply because I don’t have to spend so much time connecting client side component to the backend, with all the validation that could happen in the backend and frontend. Because the components are pretty much ready to use, I can spend extra time on CSS and adding some “nice to have” features to the components.
I don’t have to worry as much about making it work, I can worry about how to make it work best for the user.
Hopefully this doesn’t sound too much like an ad
That was indeed the eye-opener in a previous team.
The mindset change that a UX designer brought to the entire team was amazing.
This sets the context a bit for my question.
I’m currently technical lead in a UI team responsible for introducing Vaadin to the project. We are in fact responsible to paving the way for the rest of the developers to join the effort and effectively becoming full-stack developers.
I’m strongly focusing now on the technical side: design patterns, ADR’s, good coding practices, (Documenting The Vaadin Way actually)
We don’t have a UX designer on board, and I’m a bit worried about the impact on the usability of the application. And I’m wondering how to best prepare for this phase of the project.
I think you’ll need to spend some time on market research and see how your “competitors” (or products with similar features) handle the UX. You’ll likely have to use the product for a bit, to determine what works well and what is clunky. At the end of the day, you should probably prioritize what’s intuitive rather than most advanced or covers all the possible use cases.
Ideally you’d get it focus group tested, and sit down with an actual user to observe them, giving them tasks without directing them how to do it.
Likely you wont have the time or the budget for the perfect approach, so best you can do is to just learn about your users (how they work) and imagine being them, likely doing a lot of repetitive tasks. Optimize for those repetitive tasks, make them as smooth and intuitive as possible.
Hopefully that gives you some ideas, maybe one of our UX guys can chime in with some ideas specifically for Vaadin projects.
There’s already the beginning of the UX Design part of The Vaadin Way live: UX Design | Presentation Layer | Building Apps | Vaadin Docs, but it’s not meant to recreate the entirety of UX design theory there, just something for developers getting started with design stuff.
Of course, I’d be remiss if I didn’t mention that Vaadin also offers many kinds of Design Services: Design services
What you’re describing sounds like reaching a higher level of UX maturity. Maybe this article is able to communicate some of the challenges and possibilities your team is facing and provide insights into reaching higher levels.
I believe the solution isn’t necessarily to hire a UX designer who’s responsibility is to take care all of it. You want to build a culture in the team where everyone in the team sees the value of your work through the value delivered to your users.
The user experience is a sum of many parts. Some are easier to evaluate or measure than others.
UX honeycomb is one model that you can use to break UX into more digestible pieces. Useful
Does the app solve the right issues?
Does it solve some issues or specific people’s specific issues?
Usable
Is the app easy and efficient to use?
Desirable
Is the app pleasing to use? Does it have some features that rise it above just meeting the functional needs?
Findable
Can users easily navigate the app and find the data that is relevant to them?
Accessible
High legibility, visual clarity, keyboard usability etc. benefit all users.
Legislation may require certain level of accessibility.
Credible
Does the app feel trustworthy? How to make it feel secure?
Valuable
Does the app provide real value to users?
Are we focused in making it more efficient, more secure, easier to use compared to others?
All of that may sound a bit abstract If I give one single advice, I’d say focus on consistency. When your application is build from repeatable UI patterns (Design System) it becomes much faster to develop, easier to maintain and easier to use.
Users don’t care if the buttons in dialog are left or right aligned as long as they are always the same way. UI’s are way easier to use when you can recognize the UI patterns and every view isn’t a totally new concept to digest.
If I give one single advice, I’d say focus on consistency. When your application is build from repeatable UI patterns (Design System) it becomes much faster to develop, easier to maintain and easier to use.