Blog: Fresh Tilled Ideas

Applying Agile Methodology to Web Prototyping

Posted On: July 24th 2008
By: Richard Banfield

I can't imagine what the end product would look like if I tried to bake a cake with my eyes closed. But that's exactly what you're doing when you build a web application or website without a prototype. There is no way to know what the end product will look like, and thus be experienced by the end user, when you build from a tech spec only. Given the obvious drawbacks of baking with your eyes closed, imagine for a second having to do all the parts of the cake at once. Instead of measuring out each ingredient and following an iterative process, you just throw all the ingredients together and see what happens when it comes out of the oven. That's how my 5 year-old bakes. That's not how adults should bake or build websites but we see this behavior every day. Time to grow up people.

That's why Agile makes sense. Agile methodology largely means breaking a project into Iterations. An Iteration is an increment of time, usually one to four weeks. The total project is constructed within a series of progressive Iterations. At the beginning of each Iteration a short term objective is set so it's easy to keep everyone focused. Then at the end of each Iteration, we evaluate what has been achieved. Because the Agile process requires regular evaluation of progress bugs or potential problems can be corrected quickly. This also helps get to the next round of objectives without losing focus on the priorities.

Let's see how it works. Consider the task of building a medium sized website project. The overall project is split into multiple Iterations that deliver working UI pages at the end of each one. So for example, the first round might be the home page template and the second round would be the secondary page templates. Keep in mind that it's essential that the design team works with the client team members during the first round of iterations to determine User Stories and mock-up the screens. For the second part of Iteration 0, we'll work with your technical people to fill in the blanks on specific technical solutions. Starting with the first iteration, the whole team meets for an hour or two, setting the development priorities for the Iteration.

The Agile process is not for everyone, but it should be. There are so few legitimate excuses not to use these techniques. Why wouldn't you use a process that leads to continued client happiness? The client is always happier when they can see rapid, continuous delivery of the project. Not that we promote this but, late changes in requirements are not only possible but also considerably easier to manage. Continual course correction prevents big surprises at the end of the project.

---

Comments (0) Post a Comment Permalink

Designing in Code

Posted On: July 22nd 2008
By: Richard Banfield

I came across this article in A List Apart that really sums up the positives of working with web prototypes. David Verba keeps the prototype design on center stage where it belongs. Here's a taste of what he has to say...

Prototypes keep us focused on our actual goal. I’ve seen countless hours spent generating thousands of pages of documentation that were never used. This in itself wouldn’t be so undesirable if we had infinite developer resources. Unfortunately, this is rarely the case, and I’ve often seen features cut from a product launch in favor of generating “better” documentation. With prototypes, the focus is always on the application and making it better, and it’s much easier to stay focused on value to the end user.

---

Comments (0) Post a Comment Permalink

To Prototype or Not To Prototype?

Posted On: July 17th 2008
By: Richard Banfield

I'm sure everyone reading this blog would agree that the user interface is one of the most important parts of any application. Without doubt the UI affects the customer experience more than any other element because it determines how easily you can get what you want from the website. As over a decade of living with the web has taught us, a web application with a poorly designed user interface has little value.

We've always preached that when creating a new web app starting with the user interface makes more sense than beginning with the data model. On one hand as traditional MVC (Model-View-Controller) frameworks have evolved there is more emphasis on the role of the UI (or View) elements. Unfortunately there is an entire generation of data experts and architects that don't like this idea. We still here of businesses that decline to do any web prototyping before building their applications. I'm a little disappointed that there is still resistance to a UI or prototyping first approach. The advantages are enormous, especially for startups and new internal projects.

As we have noted before in previous posts about the advantages of web prototyping, prototyping can improve the quality of requirements and specifications provided to developers. User testing the prototype gets the potential bugs out the way so much sooner. The web prototype being tested by the user prevents many misunderstandings and miscommunications that might occur between the designers and developer. Changes to the data and application layers cost exponentially more to implement as they are detected later in development, the early determination of what the user really wants always results in faster and less expensive web apps. Because web prototyping requires user involvement and allows them to see and interact with a prototype allowing them to provide better and more complete feedback and specifications.

---

Comments (0) Post a Comment Permalink

BMW cloth car design

Posted On: June 11th 2008
By: Richard Banfield

BMW have done it again. This time it's with a car that changes it's shape based on the driver's whims. The car, which is built on a Z8 frame and covered in cloth, morphs in shape. This is clearly where car design is headed. Customizing your driving experience need not be limited to seat and steering adjustments. Great work.

From Wired Magazine: It's stretched over an aluminum frame controlled by electric and hydraulic actuators that allow the owner to change the body shape. Want a big spoiler on the back? Wider fenders?  No problem. "The drastic reinterpretation of familiar functionality and structure means that drivers have a completely new experience when they handle their car," BMW says.

---

Comments (0) Post a Comment Permalink

Defining the Contrast Between Rapid Prototyping VS Traditional Development

Posted On: May 27th 2008
By: Alex Fedorov

When put into list format, the differences between Application Development VS Rapid Prototyping are very stark:

Traditional Application Design:

•    Engineers and business development teams work on a bloated technical spec often 50-100 pages long that has very little value or meaning because it can't be visually interpreted and doesn't reflect the core experience of the product.
•    Programmers create an enormous database with little flexibility
•    Developers take months to put together choppy wireframes that will later drive the design/skinning process. As all designers know, programmers leading the design process is a dangerous idea.
•    Developers hand off template skinning duties to UI designers who have less flexibility than if they were starting from scratch and iterating on templates with the client.
•    Eventually the application launches and the design process feels like a quick & dirty effort to put "lipstick on the pig"

Rapid Prototyping Process:

•    A designer interprets the clients' ideas for the product goals and user experience, shaving out features that don't make a real impact and focusing on the core value
•    The designer begins working immediately on Photoshop/Illustrator comps of high level pages such as Home, Registration, Account Dashboard and a set of style rules for Forms, Data Tables and Wizards
•    One approval is reached, the designer begins coding out high level pages and linking them together in XHTML/CSS.
•    All template pages are fleshed out in XHTML and can be easily modified, removed, added to or iterated upon.
•    Different states can be developed to show errors, blank states, populated states, etc.
•    Designers hand off templates to the client who then gets developers to respond visually and experientially.
  
Though the design process and programming process is reversed, sometimes it can still take a while to develop the application given the HTML templates, but several key benefits of doing the design first include:

•    Ability to get programmers to understand exactly what they're providing.
•    Ability to show investors or early stage clients exactly how the app will look and work to raise money while in development.
•    Ability to provide user testing to get feedback and make any major necessary changes to prototype.

---

Comments (0) Post a Comment Permalink

Defining and Developing a Web Prototype Design: Part 2

Posted On: May 3rd 2008
By: Richard Banfield

From HTML/CSS to full prototype

Having created your template pages you can begin to build out the complete prototype. As for templates we start with the home page, a few primary pages and the registration or signup process (if there is one). If it’s a web application you are designing you’ll also want to design the critical functional areas e.g. dashboard, profile setup/edit and uploading files. Each project will be slightly different but you’ll notice patterns in all of them.

Building the web prototype

Try not to get too carried away with the details. If you are working with a copywriter then just add simple text fields, which can be updated later. I’m personally not a big fan of using lorem ipsum to fill in blank spaces. It tends to give the impression that you have to fill up all the empty spaces. Rather use actual text and have your copywriter update it either in parallel or after you are done with your designs.

The ideal place to be before your next review is to have the home page, registration pages, dashboard and your primary functional areas designed and linked together. Never show a client separate pages that have no relationship with each other if you can help it. By linking pages you can easily see what might need to be added or subtracted to enhance the user experience. In a recent case we were presented with an 8-page registration process. Using a prototype we were quickly able to reduce the steps to 2 pages.

Testing the user experience

Using this basic but more coherent prototype you can now begin with your first real test of the design. Keep the user testing simple by restricting it to 6 – 8 testers. All testers should be properly screened so that you are getting real potential customers/users to look through the site. Larger sample sizes are not necessarily better than testing a small selection of users. Once you reach 8 people you don’t significantly increase your confidence level (for the statistically minded).

Questions should be objective-orientated. By that we mean that, in general, questions should be considered from the point of view of achieving an objective. Give your users small goals, like “show me how you would buy the _____ item” or “please register for the _______ service”.

Testing is a whole other subject so I won’t go into it here. That’ll have to wait for another blog posting.

Building the actual site

Once your designs are approved you will be able to start building out the remaining pages. Because you have created a template in HTML/CSS this is a relatively simple design process. The hardest part of this step is making sure you are maintaining a solid user experience and not just adding pages for the sake of filling in the blanks.

---

Comments (0) Post a Comment Permalink

Defining and Developing a Web Prototype Design: Part 1

Posted On: May 3rd 2008
By: Richard Banfield

I’ve had a few calls recently from bloggers and writers with requests to clearly define web prototype design. Broadly speaking, all product prototypes are living versions of the idea you have in your head. These tangible prototypes need not be perfect but should provide enough detail to be able to adequately test the idea.

Web prototyping or rapid web prototyping, as it’s sometimes called, is the process by which a web-based model of the end product is constructed for the purpose of outlining how a website or web application will look and behave. In the world of web prototypes the process of developing a prototype might be more important than the end product.

The web prototype, whether it’s on a whiteboard, paper and online is a test site that will include some content, all primary navigation and possibly images and key functional elements.

What a web prototype is not

In our experience we don’t think of a web application prototype as just a mini-site. If it’s a moneymaking application then it’s essential that the prototype be close enough to the end product that your business and revenue model assumptions can be tested. A few scraps of paper and some wireframes do not constitute a prototype. These things are however essential to the planning and development process.

How to plan your prototype

Even if you’re not particularly good at drawing the best place to start is with pen and paper. Sketch out the basic elements starting with the user experience in mind. Use basic usability questions to direct your thinking. What will the user see first? How will they know what we do? Where should we direct their attention? How will they register? There is a lot of debate about using personas or use cases to define the initial designs. Although in some complex applications we develop use cases we generally find there is only one primary persona for each successful design. If you have too many personas or use case you either need additional applications or you need to get some focus.

At this early stage less is more - only focus on the essentials. Do not be tempted to fill in all the gaps and fill up the space on the home or landing pages you are sketching. That level of detail will come later. Drawing out the site pages helps everyone involved to visualize what you are doing. Getting everyone on the same page, literally, is critical to understanding where the design will succeed and where it needs more help. In 90% of our designs the first sketches happen on the white board and are then transferred in more detail to paper or wireframes online.

Who should be involved in the prototype?

If you’re doing this for yourself then you may only need to include your business partner/s and a competent web designer. If you’re a design firm the clients core team and your core design team will be involved. Ideally you want the prototyping team to be as small as possible. Inviting more people doesn’t invite better input.

Once you have your prototype sketched out get feedback and sign-off so you don’t end up going in circles. This can be difficult if the client needs additional team members involved to get approvals. Try educating your clients that this process is not to secure approval on the aesthetics or functional elements but rather on the layout and navigation of the future site or app.

From sketch to actual web design

Although it can be useful to start testing your sketched designs with real users at this point we don’t recommend it. In the 200+ projects we have done using prototyping we have found it’s faster to get a more coherent design together before starting the testing. User testing is not expensive if you adopt the methodologies set out by Steve Krug so it shouldn’t matter either way.

To achieve the speed of execution our clients expect we move directly from sketches to Photoshop mock-ups. The client reviews these mock-ups and any changes required are made immediately. Because we publish the designs to the web via Basecamp, we find progress is only limited by the speed at which we can get feedback. In some case we’ll move from sketches to HTML/CSS immediately so we can make updates even faster. This can only be achieved if you have signoff on a template or you are working on an existing design template that doesn’t need to be updated.

---

Comments (0) Post a Comment Permalink

Notes on Managing Different Subscription Levels on Web App Prototypes

Posted On: March 22nd 2008
By: Alex Fedorov

Recently, we finished a major Web Prototyping project for a client building a project management application in the Creative space. The application has 3 different subscription levels: Free, Enhanced and Professional. Each level allows for increased functionality and features, and we agreed with the client that the best thing to do would be to build out each account level to show the Development Team and potential users exactly how the application functioned at each level.

To view screenshots that demonstrate these ideas, click here:
Large Version | Medium Version

Here is a short list describing the process we used:

1. Complete the full version of the application first with a focus on giving the user the most thorough and comprehensive experience possible. Be sure to build the prototype files out in a separate directory with its own subfolders and keep all links and images relative to the html documents – not the site root. This way, when you make a copy of the directory to create a different account, you don’t have cross-account link problems.

2. Identify the features you are going to remove from the lower subscription levels. In this case, we created a quick document listing what features were to be removed each section as our roadmap to begin the removal process.

3. Instead of simply going through the html pages and removing features of the application that aren’t accessible at that level, take screen captures of the features, gray them out in Photoshop and replace the actual features in your html documents with these graphics. This way, the user understands precisely what it is they’re missing at a lower account level and is tempted to upgrade their account. Having a direct hyperlink from the screen capture images to an Upgrade form is also vital.

3. Create a very easy-to-use upgrade form page that changes the account type to a higher level. This will be instrumental in taking the user from the Screenshot view through the Upgrade process.

4. Add documentation into the prototype to inform the Developer or Programmer that after the user is successfully upgraded to a higher account level, they should be returned to the page they originally came from with the new features in tact. This way the user gets the direct benefit of upgrading by gaining access to the features they upgraded to use.

---

Comments (0) Post a Comment Permalink

A Parallel in Industries

Posted On: March 18th 2008
By: Alex Fedorov

Recently, we began a series of redesign discussions with SPEC Process Engineering in Burlington, MA. We’re thrilled to be working with them and have already learned quite a bit about an industry we otherwise knew nothing about. They essentially design & build large scale manufacturing plants, research laboratories and chemical engineering plants.

The most interesting aspect so far from our meetings with them is the realization that their industry has always operated in a tightly traditional way and that their process is dramatically different, causing some potential clients to raise eyebrows.

Instead of bidding separately for Architectural, Engineering and Building contracts, SPEC’s proprietary methodology allows them to handle the entire contract with their in-house employees from start to finish. This method allows them to be far leaner and more rapid than their competition. However, when we discussed this in greater detail, it became clear that the industry is so deeply entrenched in the way things have always been done that this aspect of their approach was at times a warning sign to potential clients.
However, when you weigh the costs and benefits, SPEC’s approach enables them to finish a project in 8 months that could easily take a series of various contracting firms 24-28 months. While an architect at SPEC is designing, they can order the parts they anticipate (and some of these parts can take 16 weeks minimum to arrive at a jobsite).

This made us think about how web applications and sites have historically been created. In our industry, the traditional method involved a long and complex technical spec that was often very difficult to interpret by the designers and programmers involved. For the last several years, we have seen many web application designers starting with the design first – a method that we like to call Rapid Prototyping. This not only makes the process easier to understand, but allows you to A: get feedback from potential users, B: raise capital by demonstrating an application to investors in its XHTML/CSS state, C: make changes much more easily and quickly than if the application had already been programmed and D: give the programmers a finite roadmap to work from.

Here’s to breaking with tradition and increasing efficiencies – in any industry!

---

Comments (0) Post a Comment Permalink

Web prototypes through the eyes of a car designer

Posted On: February 12th 2008
By: Richard Banfield

To me, building web prototypes must be a lot like designing cars.

Step1: First you sketch out the basic layouts and place the essential functional elements in their ideal locations. We photograph these basic layouts which we sketch on a large whiteboard. The photos are shared with the design team and the client to ensure we have the basics right.

Step 2: If you like what you see you start to render the design in ways that brings additional value to the layout and enhances the features. We're all familiar with car concept drawings like those of Chip Foose on the TLC television show "Overhaulin".

Step 3: Once the drawings or Photoshop designs are looking like the images you had in your mind all along the next step is to build a prototype. Car designers use clay to do this. Web designers code their designs into HTML/CSS. Customers, partners, investors and user experts can then get a sense of how this product will live in real space. By coding the design you allow target users to take the website or web application for a test drive.

 

---

Comments (0) Post a Comment Permalink