Hey there, I'm Jonathan, a freelance digital consultant, specialising in UX/UI Design.

I help companies design and develop beautifully simple user interfaces. I work with a huge variety of clients including companies like, Smith & Nephew, KLM, Durex and the National Aids trust.

"Getting real" - Developing web applications the right way

Posted By Jonathan Clift on 11 April 2013

I've read Getting Real by 37Signals (You can get the free PDF here) twice now and not only does it inspire me, it reminds me about some key factors to consider when building web applications. I feel the need to note some of these points down for future reference, so here are some of my favourite points from the book:

Build Less

Stop trying to compete based on features and complexity. Build less and focus on doing those things incredibly well.

Essentials only, start with NO!

So many features sneak there way into applications these days, quite often because developers take the "it's easy to do" approach. The best way to stop this is to start with by saying no! Think back to why you're building your application, is this feature really, really, really essential? Would the application be useless without the feature? You've got to work new features hard before they get anywhere near to being coded, dont just say yes because it sounds like it would be easy to do, it never is and will always add hidden complexity.

Ignore details early on

Details are important but don't waste your time trying to create pixel perfect applications from day 1. The priority is to make sure it works and works well, you can always come back to it and reiterate. Put another way, practice Kaizen and aim for continuous improvement rather than perfection at the start.

Turn your ideas/sketches into HTML prototypes

Lots of companies start development work before designs are even finalised, don't fall into this trap. Get some sketches done and turn those into some HTML prototypes first. You get so much more from a HTML prototype than you will from a pixel perfect design. This will highlight things that work well or not so well before you wasted lots of time developing. You'll probably find a number of things need to be changed, and its much easier to do this in your sketches/HTML than it is to change your core code.

Epicentre Design

Start by working on the most essential part of the page and build around it. Don't start with the header, menus, footer etc, focus on what really matters first to offer the best possible experience.

Design/Develop with a blank slate in mind

The first time users use your web application, they wont have any of their own data there yet. First impressions are everything, and if you don't include a nice blank slate you might put potential customers off forever. This might be dummy data or nice helpers showcasing what it will look like once data is added along with a callout to get them adding their first bits of data.

Catch those errors

When things do go wrong, handle it effectively to avoid ruining the customers experience. Don't have errors like "The operation did not complete successfully  try again." This isn't helpful. Provide useful informative feedback, that a user can act on rather than leaving them to ponder what an error message actually means.

Get the web application online early

Set a realistic launch date and stick to it. If you can't meet that date then maybe you have too many features or too much complexity. It might be better to scale it down a little more, you can always add to it in the future.

Zero training

Probably my favourite. At my old company we offered a 2/3 day training course for new users of our software package. In hindsight, that should of been a clear sign that the software just wasn't good enough. Don't fall into this trap, build features that are intuitive, have inline walkthroughs and subtle guidance that requires zero training. Allow users to make mistakes that don't have major consequences whilst they are learning to use the software. (Undo features)

No Betas

Creating a public beta release is just an excuse to fall back on when things don't work properly. Stop trying to create the perfect product, scale back the features to ensure you're confident of there quality and then release a version.