Boxes and Arrows: Comments by Marianna Samara

Marianna Samara — Thu, 07 Feb 2008 10:12:55 GMT

I found this article really interesting, especially now that I am designing some wireframes for a project and I noticed that all the tips for good wireframes apply in my wireframes too in order to be more functional and easily accepted from the client. It is really important the client to believe that the wireframes are being designed particularly for his company and is not part of a series of templates that the agency works with.

I can understand also those who commented that there is no purpose on working with wireframes these days as there are other approaches as HTML or Ajax to create more interactive prototypes but I personally believe that wireframes are very usefull for the initial meetings with the client. Firstly, because they save you a lot of time at the first steps of the design process and secondly because you do not need to consider for issues as positioning of brand and other call to action buttons as these are issues that should concern you in later steps in the design process.

Marianna Samara — Mon, 18 Feb 2008 11:53:20 GMT

Nice approach of user needs. In my opinion, these two steps are also neccesary in web or design projects too.Throughout each project development the main focus should be on users needs (by users I mean the people working inside the company that i.e. need a redesign of their web site) as they will actually interact with the system once it is finished. Before starting to develop a draft IA, much time and thought should be spent on how you’ll identify user needs and developing an overall stategy by indicating the objectives and scope of the system.

Marianna Samara — Wed, 26 Mar 2008 11:21:49 GMT

Nice article. I enjoyed reading it. Really informative, gathering organisational with user experience issues.
I particularly liked the approach of organisation architecture in realation to information architecture. Failure of major organisational projects is a situation nobody wants to experience but sometimes is inevitable.
Nevertheless I disagree with the figure 1 as it indicates IA / UX /UI as part of software development only, whether I believe IA / UX should be direct linked with people and product as well.
As already stated I am looking forward for Part II.

Marianna

Marianna Samara — Tue, 01 Apr 2008 09:22:38 GMT

Hi,
Nice artilce. I found the steps that should be followed after gathering the data really useful. Also, I agree with the concept that you can gather the needed information by only asking a few and critical questions and not troubling the user with a big list of questions. However, I believe that in some projects either because of time or budget limitations there is no user task analysis step before starting the design process. I am against that, but experience has proved that this is the common phenomenon. Nevertheless, “extreme user research” could be a solution to these cases so thanks again for the article.

Marianna

Marianna Samara — Tue, 01 Apr 2008 09:44:11 GMT

Hi again,

Thank you very much for the explanation. It makes better sense if I see this figure only as a case study for a specific type of organisation. I work for a smaller company and as a result, I am directly connected to the clients, users, designers and software developers; so I am closer to the product progress (which is mainly web sites) and I see that my decisions and advices can influence directly the development of the product. Furthermore, I absolutely agree with your comment that “Keeping a product healthy in the marketplace is everyone’s job”.

Marianna

Marianna Samara — Tue, 15 Apr 2008 09:30:46 GMT

Peter,
Thanks for a nice article once again (as part I).
This article reveals a great combination of various sources of information and comments that form a frame of UX. Is clear for the reader what is UX, in which steps of product development UX is involved, where it should better fit and the importance of UX to avoid future failures. Again this article clearly refers to bigger organisation models but sometimes user experience can meet barriers in smaller organisations as well, despite the fact that product development members work more closely.
I totally agree with following statement, as it is usually one of the most common reasons why a product fails to meet the users’ expectations.
“The product team’s enthusiasm for the new and innovative may prevent listening to the users’ authentic preferences. And when taking a conventional approach to usability, such fundamental disconnects with the user domain may not even be observable.”

Joe thanks for the ’ organizational architecture’ slide share group , I have already joined.

Marianna Samara — Fri, 18 Apr 2008 12:32:38 GMT

I vote for both as well.
In general, is better to be able to express your points in a few lines, but some topics require some theoretical background which is good to be refered. So just maybe it is important all the writers to have in mind writing sorter articles for the ease of reading but this will not be always the case!