Design in Tractis

I haven’t written for a long time, sorry. With the deadlines and the blog, it takes twice as long, especially if I want to write something interesting. Today, I’m going to show you quite a few things regarding the application. This will probably be the only post you’ll see from me this month and next month, so I will take the opportunity to show interesting features.

First, let me tell you how it’s designed. I have been trying with user-focused design for around 7-8 years. This method, which is well looked-upon and is one of the most used and dominated by people in my field, is not causing the same effect nowadays.

Usually, when I observe interfaces designed with that method, I notice that focusing on the user is completely being misinterpreted. When I started, I thought that designing with that method was like taking a notebook and pen, listening to each user, writing down every “requirement” and every “whim” and, based on those data, including them in an interface. This is where humanity’s largest destructions in interface designs are produced, I remember thinking that some of the things I had designed had turned out like the car that Homer Simpson designed at his brother’s company.

As I was saying, this also happens when I only apply user-focused design. I tend to include all the users’ possible requirements, trying to standardize all of them. Anyway, to change the air a little, I have decided to take another route, which is equally directed and leaves me in the city without having to do much mileage: action-focused design.

At first, people feel out of place when hearing this but the term has been bandied about for a long time and I’ve read some papers that examines it minutely, explaining more than anything else designs based purely and exclusively on action patterns.

It’s not bad. It’s the most specific that I’ve found so far and, together with the small doses of user-focused design, we can attain what many call “a complete software architecture”. A design based on actions and not on a user’s possibilities. In general, this distorts the application to non-existent levels. Try doing something small, and you’ll see that the application requires an interface that is “able to do everything” instead of doing certain actions well.

Our design process is perhaps quite different to that of other companies. To start with, I’ve always required following a development line that provides great flexibility, keeping within margins of error and ensuring that there are not many irreversible mistakes. To ensure this, our design pattern (see further below) follows very simple steps: apertura proceso > reunión de mapeo > prototipo borrador > presentación del prototipo > producción final > subida de material.

It’s not usual, at least for me, to see this in all companies, even in large consultants. They all pursue the goal because there’s no time or budget for applying those steps, which are nevertheless essential; since I’ve started to force myself to apply those steps, I wake up without many headaches. Getting to the point, I will show you some of the application in PDF so that you can take a closer look at the subject: how we create the prototypes, what they are, the foundations and the documentation for each project developer and collaborator. It did not take us months to do this; in fact, all that planning and production usually takes a week or two.

• Wireframe-Setting
• Workflow-Draft Invoicing
• Workflow-Negotiation
• Wireframe-Draft Contract
• User module final draft

I hope you’ve liked this. You can ask about anything without any drama in the comments. We will try to answer, although we’re suffocating because of the launch dates.

By Diego Lafuente
Saved in: Design, Tractis | No comments » | 26 July 2006