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!

Marianna Samara — Fri, 07 Jan 2011 19:42:06 GMT

Hi,

Great article Alexa. I just completed the tutorial and I will start my own examples in a moment. Just I want to let you know I noticed a typo mistake but because it is inside the code is worth correcting it, in case someone gets confused in the future while trying to follow your tutorial without previous knowledge in ActionScript.

On section 9.6 ->

9.6. The complete script that will be placed on the button, which includes the actions that should happen when the condition is met or not met, is:

on(release) {

if(_root.termsBox.selected true) {

_root.gotoAndStop(“W07”);

}

else {

_root.gotoAndStop(“W06”);

}

in the second line of code the symbol ”==” is missing between “selected” and “true”.

Thanks again for the great article, looking forward for part II.

Marianna

Marianna Samara — Fri, 07 Jan 2011 19:42:06 GMT

Nice article Paul.

Specially step 1: Sales & Kick off together with last recruitment tip “Leave time between participants to summarize results and to change the tasks as needed “ should be considered throughout the usability testing process. I found myself several times creating a “Do’s & Don’ts” guide to help team members through the process but after testers feedback I had to reconsider the list and updating it. Time limitation is a factor that leaves you no space to look back on your results in detail but is good to save some time between sessions to examine your results so far. This might help you avoid future mistakes in the same study and optimise the user testing throughout its own process.

Wait to read Part II.

Marianna Samara — Sat, 05 Mar 2011 05:58:06 GMT

Great Article.

I agree that this content can be used as a “web-based form” guideline. Nevertheless, I believe that there are four people who determine the success of a web-based form. Developer is the fourth one. The implementation of designers’ clear understanding of all the details is an important step before the user helps shape the overall approach to the application form. Sometimes many innovative ideas never get into practice. Usability practitioner’s responsibility is also to work close with developers to ensure that implementations of the designs do not drift from the validated design intent.

Look forward for part II :)

Marianna Samara — Wed, 26 Nov 2008 09:37:52 GMT

Thank you for sharing your experience with us!
I think we can all agree that dealing with participants is a sensitive matter. I strongly agree that we should make sure participants feel that they help us and that we are not testing them. Recently I participated in a usability test for a website and there were some moments during the test session that I felt I was judged for my choices (while trying to accomplish some tasks). I felt that mainly due to the way the questionnaire was structured. So apart from making the participant feeling comfortable at the beginning of the usability test we should make sure that the tools we use point to that direction too.

Marianna Samara — Fri, 07 Jan 2011 19:42:06 GMT

Christopher, that’s a really nice article.
I work for a design agency and apart from 1 or 2 projects so far; most of the times clients don’t have the content ready during the UCD process. Especially if they decide to use a CMS for their website they think it is better for them to fill the content later. That is usually because they need some guidance on what the main structure of their website will be and then they want to locate the appropriate team members that will write the content for these sections. As a result, as you efficiently described in your article the wireframes & initial designs may seem out of date by the time the client adds the content. Just of precaution I tend to design the wireframes being flexible & not much dependable on content quantity when achievable. However I agree that the best practice is to produce UCD deliverables with as much content as possible.