Lean UX – Creating a web app in 4 hours – a case study on Writr

Lean UX is all the rage these days. It promises faster delivery through reduced deliverables and a more iterative approach to designing. The product is exposed to the users early allowing feedback at the most important stage of the product lifecycle. I decided to set myself a challenge of creating a web app in 4 hours using Lean UX principles and finding out if I could practice what I preach when it was me who was the end client.

Sponsored link

The idea

There are a couple of sites around which promise distraction free writing but what they were missing in my opinion was a way to make the writing enjoyable and competitive. I wanted to take the concept to the next level by introducing features such as scoring and competition – but retaining the minimalist approach which removes distractions and allows you to get on with the task at hand.

Writr was born.

Disclaimer: Now in ordinary circumstances I would obviously test the concept of the idea itself with end users (or the product idea being the result of that user testing), but given this is for the purposes of this blog post and my strict 4 hour time limit I am going to make the large assumption that this product is something which the target audience would want and therefore I am going to build.

Identifying the audience

As with any UX project this is the first step you should get to grips with and no less so than creating a web app through Lean UX.

My primary target audience (or persona) were bloggers as they suit the sort of bite-sized writing I aimed to cater for through Writr. Being one myself and without the timescales for any proper user research I thought this was a good starting point.

Identifying the context of use

Mobile first is often the way to go with many new projects you may work on these days. However, that was not the case for Writr. My two main use-cases I wanted to focus on were people writing blog posts, or people writing essays.

Given that writing in general on a mobile device (particularly a touch screen) is a chore if doing anything more than a short email I decided the primary focus of Writr should be for the desktop.

Figuring this out early on meant that I could sensibly prioritise my feature list and not waste too much time of my precious 4 hours developing something for mobile. I strongly recommend you read my other article about contextual product backlogs for a full explanation of how this works in practice.

Identifying the functionality

Prioritising my Trello Board

Prioritising my Trello Board

Writing requirements in the form of user stories is a great way to generate functional specs without the overhead of a massive functional specification document. I came up with a list of features which I thought users of the product may like to see. Of course you should ideally do this with the users themselves but in my ultra-compressed timeline I had to take an initial stab.

I fired up a Trello board and jotted down my user stories and spent some time prioritising the requirements. I knew it needed some kind of metrics in order to make it competitive so in my mind these were high priority items – behind of course the ability to be able to type something in the first place!

 

 

The UX design

Sketching on the iPad

Sketching on the iPad

Now that I had my functionality defined and prioritised it was time to create a couple of quick wireframe sketches using Penultimate on my iPad. This was going to be a simple 1-2 page app so this process didn’t take very long, but it still helped clarify in my mind what the pages should look like and what should be most prominent on the page.

 

The interface

The settings screen (1 hour passed)

So the first key part of the app was allowing users to set the amount of words they hope to produce, and the time limit they have to produce it. This meant the first stage was implementing some sort of settings screen to allow them to do just that. Behold..

Writr settings screen

Initial settings screen

Ok it looks like a baboon’s unshaven backside, but it did the job and meant that the user requirement was covered off (and therefore could be tested).

With lean UX, or indeed any lean practice the important thing is to get something out there to test – and early.

There is always time to go back and finesse, but you may as well do that using actual feedback from actual users.

The main app screen (2 hours passed)

The main Writr interface

The main Writr interface

The second screen of the app is where the user actually writes. I also had user requirements to play back the word count and the time remaining.

Again, it’s not going to win any design awards but it covers off the user requirement.

The code

Regular readers may know that I come from a Front End Development background. That meant I was in the lucky position of being able to have a bash at actually building this thing myself. I looked to see what the quickest way I could get to my end goal was and this meant using a library which had a lot of the functions I would need to create already built in, so the obvious choice was jQuery.

This isn’t a coding blog so i’m not going to go into too much detail here but the code just like the design needed to be iterated on. What I ended up producing in the 4 hour time limit was pretty dirty, but it did the job. If I had more time I would have spent longer refactoring the CSS and the javascript – but the important thing was to get something out the door.

Improving the UX (3 hours passed)

As it turned out i’d covered off a good deal of my main user functionality in 3 hours. That left me one hour to improve the user experience of Writr.

There were two main things I wanted to do. The first was to make the text box more prominent in the design as without that text box the app is nothing. The metrics were using up a lot of the screen space so I decided to move them up to the header area.

The second adjustment I wanted to make was to make the metrics more satisfying by showing a visual level of completeness rather than just text. Fortunately I found a nice little jQuery plugin (my earlier framework decision was paying dividends) which allowed me to do just that.

Writr main screen v2

Writr main screen v2

As you can see the layout is looking a lot tighter and the main focus is now on the writing itself.

The metrics also look a lot more pleasing to the eye and give the user greater satisfaction as they see them either fill up or tick down.

 

 

Final tweaks (3 hours 45 minutes passed)

Writr settings screen v2

Writr settings screen v2

I had 15 minutes to spare so I decided to spend them sorting the settings page CSS out and adding some ‘delighters’ in the form of some nifty jQuery animations.

All in all I thought it was looking pretty good for four hours work! And most importantly I had managed to release a minimum viable product when I said I would.

Over to you

So now the only thing that remains is the user testing of the prototype which is the key driver of Lean UX and Lean Development as a whole. And that’s where I want your help. I have some ideas on future features for the product but I want to hear from you guys.

  • What did you like about it?
  • What did you dislike about it?
  • What features would you like to see?
  • Would you use it?

You can find Writr here.

Image courtesy churl

Sponsored link

3 thoughts on “Lean UX – Creating a web app in 4 hours – a case study on Writr”

  1. Tomer says:

    Really cool!
    But what did you build it with?

    1. Chris Mears says:

      Thanks! Pretty much just a text editor..

  2. Doug Gough says:

    Pretty cool. It motivated me to write. The design gets out of the way, which is exactly right for this kind of app.

Leave a Reply

Your email address will not be published. Required fields are marked *

Read more:
Reassurance
How reassurance seeking patterns can help your user experience design

Your Amazon shopping screen has just told you your payment has gone through and the order was successful. What do...

Close