Posts Tagged ‘design’

Written Specs vs Prototypes

Wednesday, April 1st, 2009

No client wants to read long scoping or technical spec documents, they either do not have the time, or they do not understand the content within them. Written specs take a long time to write and for small to medium sized projects they might not be the best solution.

We recently have adopted a more visual approach to scoping projects. Instead of just supplying a written technical scope we are using drawings, design mock ups, wire frames and prototypes. Our new process is as following:
Prototype - Drawing

Drawings

We start off with the good old fashioned pen and pencil, rapid drawings, ideas anything that comes into our heads gets put on paper. This is a great way to set up the structure of the design and layout quickly and easily.

Wire Frames

The next phase is to build the basic blocks of the page, this can be done either in a graphics package such as Photoshop or in HTML. We tend to use large coloured blocks to denote areas of the page.

Design Mock Ups

The next phase is the refine the wire frames and skin them with a design, so that they look superb. This design phase is very iterative and involves lots of client involvement and feedback.

Prototypes

With our prototypes, each page is designed and marked up in HTML and JavaScript, but with no business logic or database, which creates a skeleton of the site. These screens are considerably easier to update based on client feedback, and make sure that the structure of the site is agreed before the code and data model are designed. It also allows us to use a highly iterative process when working with clients.

The education for clients is that after the prototype has been signed off, that is the what we will be delivering, we have design freeze after that point.

The advantage of this is that the client can see exactly what they are getting, and can engage with the functionality before it is built and it is too late. A lot of the time clients have their own ideas about how the software should work, and pays to get their input early and often while you are deisgning the system.

So no more written documents?

This approach has worked very well for innovative projects, where the scope of the project is not clear or not set. However we still provide written documentation as well to back up the prototype as there is simply no replacement for this.

This approach is not for everyone and will not work for large scale projects where a full and detailed project management plan will still be required, but for smaller projects the results have been amazing.

Tags: , , ,
Posted in General | No Comments »

Designers And Developers At War

Thursday, March 5th, 2009

Working in a technology office that places a large emphasis on design, we have a larger than normal ratio of designers to developers.

I was listening to an interview between Joe Stump (lead architect) and Daniel Burka (creative director) of Digg, which made me think a lot about the designer, developer relationship.

This relationship is often a strained one, often there is clear separation of teams with designer and developers often working in separate offices.

I am generalising somewhat but developers tend to be more pragmatic and see the whole picture, where as designers are much more creative and grand with their visions. There needs to be a compromise in order for the two teams to work well together.

Here are my tips for a productive working relationship between designers and developers:

1. Sit Together

If you all work in the same space then it is much easier to see what the other team do, and appreciate the skills that they have. You will also get to know the designers personalities and that helps when communicating with them.

2. Collaborate start to finish

From the very start of the project designers and developers should work together. This ensures that the best ideas are highlighted, and there are no nasty surprises later in the project, when the developers see a signed off design and freak out as it cannot be done.

3. Developer sign off

Any design that gets sent to the client has to be signed off by a developer first, so they can assess whether the design is actually possible, and can be built in the time line specified.

4. Keep talking

Always keep talking, have round table meetings, cross team brainstorms and make sure you developers keep your techie speak to a minimum.

5. Educate each other

The more you can educate designers on what is and isn’t possible the easier it will be the next time, simply saying that it cannot be done is not acceptable, always give reasons.

6. Mutual respect is the key

Both teams must respect and work together if you want to create an amazing product. Each team cannot do it by themselves.

7. Naive knowledge

I have often seen very elegant solutions suggested by designers as they do not really understand the technical points. Sometimes developers can over analyse and be too risk adverse.

8. Pause before you speak

Listen to what the other party is saying and then pause before you reply, really consider their point of view. This is universal for all teams.

9. Don’t say no – developer’s default response tends to be “No”

We have all done it and it is not healthy, remember there are shades of no, only use a flat out no if it really isn’t possible. Most developers love a challenge and no should not be part of their vocabulary.

10. Compromise

There is always middle ground, if you are asked to build the impossible, give options and suggest alternatives.

11. Don’t be afraid to challenge

Don’t be afraid to challenge each other ideas even if they are not in your field. I often challenge a design that I see even though I am not a designer. However you should always defer to the experts, at the end of the say if I challenge a design but the designers over rule me, then fine they are the experts in design.

Conclusion

We have a lot of healthy banter between the development and design teams, words like spot uv, belly band and matt lam, always make me laugh. Recently the developers were talking about extreme programming, this prompted the designers to come up with extreme design, which involved designing while snow boarding.

As a developer I personally hold designers in very high regard and have huge respect for their skills and expertise, I have learnt a lot from them, and hopefully I have taught them something in return.

Developer and designer can work very well together, given the right environment and ethos, and when they do, amazing things happen.

Tags: , ,
Posted in General | 3 Comments »

Design Does Not Always Solve Everything

Wednesday, March 4th, 2009

I am often called in to consult when a site, software or systems are not working correctly, either they do not deliver the benefits they were built for, or they are not as successful as the owners expected.

Working in an agency that places a heavy emphasis on design, it is easy to say that a new design solves all problems. Most creatives place a lot of emphasis on refreshing or changing designs, however this is just one part of the solution and needs to be used with a more holistic approach.

If you site is not giving you the returns that you expect, the design of the site is probably only one part of the solution.

Think about the following aspects of your site:

  1. Navigation – can users find what they want quickly and easily
  2. Signposting – are you highlighting the most important information
  3. Leading and Calls To Action – make sure users know what to do on each screen
  4. Information Architecture – grouping and arranging data into logical groups
  5. User Feedback – engage with your target audience and get their input
  6. Analytics – watching users move around your site can yield surprising results

Remember that if your site is not working, giving it a new set of clothes will not fix anything, using a more balanced approach will fix the real root of the problem.

Tags: , ,
Posted in General | No Comments »