Behind the scenes: evolving the UI

by

First of an occassional series of posts describing how we do development here at Mike CI. I’m sure what we do is by no means unique, but hopefully our experiences might resonate with your own project. Or at the very least give you an opportunity to point out how we can do things better!

As you’d expect for a new product start-up we are an Agile shop.  All prospective features we get are put in our Product Backlog in Agilo, which is our Scrum tool of choice. I’ll probably do another blog at some point on how we do Scrum. At the start of each sprint we take user stories from the backlog and figure out how we will implement them during the Sprint planning meeting.

The main goal of our last sprint was to add a new component – the Account Manager. Our first release of the Account Manager includes functionality to enable users to register an account, invite other users to join them, manage their profile and change their password. Simple stuff, but a core component to the platform.

For the Account Manager we wanted a cleaner look and feel than the Control Panel. Managing your account should be easy and simple to do, and the design should reflect that. We also knew we would be adding more features here so the design had to be able to cope with that, eventually users will be able to upgrade/downgrade subscriptions, view usage and change their payment methods.

Our initial step is to story board the flow on a whiteboard and then capture the flows in Balsamiq. We’re really pleased with Balsamiq as a prototyping tool. It is incredibly quick to pick up and produces great mock-ups that convey the flow and spirit of the story without restricting the design. We then review and debate these flows in the sprint planning session. As you’d expect with a team of IT geeks professionals these debates can get quite animated! We then re-factor the mock-ups and paste the images in to the relevant user story in Agilo. The flows and mock-ups are crucial as not only do they give us the spec for development but we work our test plans from them too.

Invite a user to join Mike

Here is the first cut of the Manage Users Page from Balsamiq.

As this is a new application we decided to follow this up with some Photoshop mock-ups. We don’t always do this, but on this occasion as we weren’t constrained by the Control Panel look and feel we decided to add this step.

Manage Users Design 1

Initial Design for Account Manager

We created about six different designs, variations on a theme, but they really helped us visualise what we wanted and review and discuss the designs. This was a bit of a design smack-down, there could only be one winner!

While this was going on the developers had been implementing the functionality without the design. The application is a fairly typical Java Spring application – web pages are JSPs, we use SiteMesh and a bit of Ajax here and there. The developers coded from the back-end first giving all the screens a blank design to start with. All the key elements in the screens were given IDs which helped the skinning process later on. The most crucial stage is resolving the design on the webpages. This is another iterative cycle and often what looked good in Photoshop doesn’t necessarily work when implemented in CSS and HTML. In fact, I’d recommend not spending too long on the Photoshop design stage – the sooner you start working up the designs for real the better.

Once we’d settled on a final skin design it didn’t take long to skin the app, about a day or so, with a few impromptu reviews along the way.

Manage Users Implemented Version

Final version of Manage Users screen

This is the final version, I hope you like it. It ties in more to our website and blogs than the Control Panel and that does raise us some questions about whether or not we want to align the designs more. I’m really happy with the designs and I hope our users are too. We hope to release the initial version of the Account Manager soon – so watch this space!

After a few iterations we think we now have a pretty good process for rapidly developing Mike applications. Balsmiq has been great in enabling us to define an initial design. We can then, in parallel, work up the final designs (in Photoshop or HTML) while we progress the development. The final step is to skin the pages with the final designs. Constantly review along the way and be prepared to compromise, what looked great in Photoshop might not work for real.

I hope this has been useful, comments appreciated!

Advertisements

Tags: , , ,

6 Responses to “Behind the scenes: evolving the UI”

  1. Mark Tattersall Says:

    Nice post. It is always good to hear how the development process works in real life from shop to shop.

    I think the point you make about Photoshop is very valid. The 2nd stage prototping I have seen has always been in HTML, CSS to ensure that the design is grounded in reality.

  2. David Palomar Says:

    A very interesting post, I am looking for information on how to integrate UI designers into the scrum process, because in many projects the UI is seen as an external task to the project and it is not to the planning, except perhaps in the first sprint . Of course, no assessment tasks usability, and so on. Something that I think is a mistake.

    This post gives me a clue.

    But who decides what is the best prototype, the Product Owner? “You realize a sprint 0 to produce the prototypes? You decide in daily meetings? How evolutionary prototype integrals in the sprints with the backend?
    A lot of questions, I know.

    • Chris Neal Says:

      Thanks for the feedback David. I agree with you that not including the UI prototyping in the Sprints is a mistake. If I can elaborate on what we do it might answer some of your questions (and possibly raise some more!). We did quite a bit of initial prototyping in Sprints 0 and 1, but as we are a new product we couldn’t possibly prototype everything up front, we have to do it as we go.

      One of my roles is Product Owner and I create the initial mock-ups, but these generally evolve as we review them at the Sprint planning meeting. We initially agreed the screens on a whiteboard during the Sprint planning and then put them into Balsamiq, but this was taking too long. I now try and get some initial mock-ups for the stories I want in the next sprint done ahead of the Sprint planning. The Sprint Planning meeting is critical as it brings together the developers and UI designers to review the screens together.

      Of course they designs are never fixed and we often have to amend them once the development is under way. Any changes are generally agreed as we go, if it is a big change/issue we might discuss at the daily stand-up.

      As we progress we’ll need to figure out how we factor in usability and user suggestions to our process, but I think we’ve got a good foundation to extend.

  3. Michal Says:

    Great post!

    I love Balsamiq! Use it every week.
    Before I use Balsamiq though, I like to sketch on a whiteboard first, just like you advised in your post.

    I like using MockUpMagnets.com for that white-board phase.
    Great for client meetings, UI brainstorming, etc.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s


%d bloggers like this: