I have seen hundreds of projects fail. But also much more projects succeed in the past 6 years I have worked at Vaadin. It doesn't really matter if it's a 10 person team in Texas or a 1 person project in Laos, they are all basically the same and succeed or fail for the same reason. Any library you choose for your project, be it Vaadin (great choice by the way! ;) or anything else, there are issues that are much more important.
What is the most critical part to get right?
Some of the customers I’ve met assume that choosing Vaadin for their UI layer automatically gives them the best app on the market. Sure, it helps, a lot, but the best framework in the world will only get you so far. Looking at the projects that succeeded vs. those that didn’t, there seems to be a common denominator: User Experience Design. Every single project where I have had dedicated UX time available during the project has been more successful than the ones that didn’t.
So, how do I do this ‘UX’, anyway?
User Experience design is something all great things have in common: it isn’t restricted to software alone. But in our field, UX determines how your users will respond to your application. Please do not confuse design with ‘prettiness’. An app that has not been designed from the user’s point of view, but looks good, will still frustrate your user to no end, no matter how many hours you spend on polishing the colors. Creating good design takes some time, but it will also clarify your goals, making the rest of your project much more smooth.
The best practice I’ve found for proper design is to start with the most boring stuff: specifications. Wait, I’m not talking about waterfall here. What I mean is that you as a project manager (or team lead, or even product owner) need to have a clear vision about what problem your application is trying to solve. Before any coding takes place, sit down with a small group: the product owner, the project manager, and a UX designer. In the meeting, hammer out a plan that will allow the UX designer plenty of time to get to grips with the problem domain, to study other solutions that may already exist, and most importantly, get to know the end users of the application. When done, the designer will produce the UI blueprints (here is a nice list of things that might be included: http://www.helloerik.com/ux-is-not-ui), from which you can start the implementation. On smaller projects this process can take anywhere from two to four weeks; in bigger projects, you could easily spend two or three months on this.
I have learned the hard way that excellent developers rarely make excellent designers. Having dedicated people for usability issues makes all the difference. We can however all learn something about usability and a first step towards that could be the recently aired webinar we had on UX Best practices below.
A month without any coding, are you serious?
Yes. I can’t emphasize that enough.
Don’t marginalize your UX
Some people think that UX is a one-time thing. Doing it for a week or so in the beginning should be fine. Or, even worse, assume that UX is something you can create after the project is mostly done. Some also think that time will pay for a fully featured theme for the app. Sorry, but that’s not the way you’ll get results.
Specifications and features change, this is one of the fundamental laws of software development. If your development team is agile, why shouldn’t your UX be, too? User experience design is something that lives alongside development in your project. You should review and expand on it during development. Same goes for the theme; creating one in the beginning of the project is probably not a good idea, since you’ll end up changing it alongside your UX. My recommendation is to use the lightest theme you can during development, and leave the actual theme for later. But you can still prepare for the theme; make sure your layouts are sane, that you have proper style naming, and remember to keep up a discussion with the designer on how the design is moving forward.
Speaking of the actual styling, as a rule of thumb, usually a good time to start looking at your theme is 2/3 through the project. Typically things have settled down in the design and implementation, but you still have plenty of time for a nice theme.
There's also life under the surface
You will need more than just good UX. You will need to actually create the application. For that, you will need other tools; data storage, reporting, deployment, monitoring, issue trackers, code repositories, and much more. Choose what works best for you, Vaadin will behave nicely with 99% of them. Knowing what tool to use is something I’ll leave out of this article; suffice to say that a tool you know is usually better than one you don’t.
What you also have to do, is decide what sort of testing you want to do. In my experience, having at least some regression tests is critical for an application. Without them, you’ll end up fixing the same issue multiple times, since your developers will not be able to test everything they did, in addition to everything everyone else has already done, before they merge a new feature. Even if you have no other tests, regression tests are the time saver you can’t afford to be without.
What makes a software project rock?
Creating an application with Vaadin can be rewarding, but it can also be frustrating. Knowing where and how to do design choices is a tricky field, one that can’t be fully taught in blog posts. I still hope I’ve given you some pointers on how to approach these things in your Vaadin project. If you follow these, I guarantee your apps will rock and your users will thank you.
- Start with UX. Do this before writing any code.
- Evolve your UX. Your requirements will change, let the design adapt.
- A pretty application is not automatically a good UX, far from it.
And if you leave this blog post with just one thing, here’s a final pro tip: buying the tools to make a Ferrari doesn’t give you a Ferrari.