General advice on UX and UI for a newbie

[John]

I've been following many of the conversations on here for some time
now, and although I haven't chipped in much, I have broadened my scope
of ideas on the subject.

So, why comment now? About a year ago I started work on a web
application that had been sitting in my mind for some time. When I
say started work, I sort of drew up what I wanted it to be and worked
with some guys that I hired from oDesk. It was a hard learning
experience. The guys I was working with were fine, but it was clear
that although I had the idea of what I wanted the application to do on
a higher level, all the "small" things just weren't worked out well in
my head. I had a vision of everything that I wanted it to do rather
than narrowing it down to what it absolutely had to do. Lots of
reading UX and UI books as well as websites has changed so much of
what I thought was important when I started...

For the last few months nothing has happened on the project as it has
become clear to me that until I get a very clear idea of what I am
looking for from the UX and UI side of things, any developer isn't
going to be do much useful right now. So I've gone through much of the
interaction and asked myself what is absolutely necessary and what
isn't. A lot needs to change as I work on function over form for now,
and then worry about form later (sort of).

I have decided to start from scratch pretty much with a mockup and
that is where I would like some advice. I have both Axure RP and
Balsamiq but they each seem to have very different strengths. I would
appreciate feedback on other peoples experience with Axure and
Balsamiq before I commit to any one of them.

Thanks in advance for any advice,
John

[AJK]

Welcome John and thanks for sharing your story.

Regarding your question...
We use mockup software for creating a quick design, with the goal of
testing in on people otherwise we can just use Photoshop and draw
pretty pictures and feel good about ourselves.

Axure: High end, lots of functionality, big learning curve, expensive
Balsamiq: Limited, quick, small learning curve, cheap

Choose the factors that suite your current needs and you will know
which software you will need to take.

Which functions are you looking for that you feel are lacking in
Balsamiq for your current goals? Maybe I can assist.

[Lynnsey]

Hi John,

Axure and Balsamiq are quite different so it isn't a matter of
choosing one over the other. Balsamiq is great for inital low-fidelity
prototypes, while Axure will allow you to create high-fidelity
prototypes, so they have a different role to play in the design
process. Why not sit down with some paper and a pencil? Sometimes the
tools get in the way of the design process. You're also less likely to
over-complicate things with a paper prototype, or get overly attached
to what you've done and feel reluctant to throw it away and start
again.

Before you even start with mock-ups or prototypes, you should have
some idea of what the application should do and how it should do it.
It sounds as though you have already put quite a bit of thought into
this. If you are a typical user (which is seldom the case), or if the
application is for your own use then you can probably figure a lot of
this out on your own. If you want other people to use your
application, you need to find out what those people want and how they
like to work.

I highly recommend a book called A Project Guide to UX Design, by
Unger and Chandler (http://projectuxd.com/). It gives a great overview
of UX techniques and more importantly how they fit into the project
life-cycle, so you can understand how and when to do user research,
when different types of prototypes are needed, when to look at
Information Architecture, how to engage with stakeholders, etc. What
it doesn't provide is in-depth understanding of these different
techniques but there are plenty of books and online resources that you
can reference once you know what you need to know!

Lynnsey

[Carlo Kruger]

Hi John

I would whole heartedly agree with Lindsey. 

I think we're all pretty technical people on this list and as a result we tend to reach for a tool when we have a problem. This premature reaching for a tool, very often gets in the way of us understanding what the problem really is. And the more complicated the tool, the more likely that this will happen.

As a result, I think simple tools (like pen and paper) help us get a better understanding of the problem, because they tend to not get in the way.

The other side of this is that they also tend to stimulate our creativity. I watched  a video over the weekend about the role of play in creativity:

http://www.ted.com/talks/tim_brown_on_creativity_and_play.html

It's a bit long at 30 minutes but quite early on the idea of involving lots of people and building on each other's ideas (brainstorming) and using simple tools (pen&paper, modelling clay) to build prototypes (construction play) demonstrate how IDEO successfully use these techniques to get great designs.

The next step would be to figure out the smallest and simplest possible feature set you need to go to market and then build only that. Then get feedback from real users as early as possible to help you improve your product.

Best of luck

Carlo

m: +27 83 292 6632
t: twitter.com/ironicbuddha
w: http://carlokruger.com

--

You received this message because you are subscribed to the Google Groups "SA UX forum" group.
To post to this group, send email to sa-ux...@googlegroups.com.
To unsubscribe from this group, send email to sa-ux-forum...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sa-ux-forum?hl=.

[John]

Thanks very much for the advice and feedback everyone and sorry for
the late response. I like to answer people directly, but if anyone
has a comment or some feedback on things directed at specific people,
please feel free to.

@ AJK:
Regarding Balsamiq, it seems simpler to use and get something on
"paper" faster, but from there I'm going to have to use something like
Axure to do the more detailed work. Some people have said that it is
better to use Axure from the start, and I can see where they get their
reasoning from, but Balsamiq just "feels" better for initial ideas
etc. I've decided to follow the advice of others on this forum and
stick to paper and Balsamiq for now just to get a better idea of what
I am looking for and I think from there I will put it into Axure to
get a better feel of the flow. If you have any suggestions or advice
I would welcome it.

@ Lynnsey:
Thanks for the advice. I've taken a step back so to speak to look
more at "what it should do" rather than how it should do it. For now
I think the difficult part is narrowing it down to what the bare
minimum is that it needs to do and find a good intuitive flow between
all the elements. Maybe it is bad practice but I still visualise some
of the flow with rough sketches of what it could look like. I've
thought about using some flow diagrams, but I'm not completely sold on
how useful they are or even how to use them properly. Are there any
other books that you would recommend in addition to Project Guide to
UX Design which is pretty practical?

@ Carlo:
Thanks for the link. I watched it and it genuinely forced me to think
a lot about how things are done and how I want to do them. Ted.com is
awesome, but I am always finding new ones that I haven't seen before.
Do you have any specific advice on how to narrow down the feature set
to the smallest possible?

Regards,
John

> > sa-ux-forum...@googlegroups.com<sa-ux-forum%2Bunsubscribe@googlegr oups.com>
> > .

[Carlo Kruger]

Hi John

I come from a scrum background and as a result my solution to the problem of defining the minimum feature set is to use some of the techniques which come out of story workshops and story writing. My attraction to UX is that it is fundamentally about viewing the system to be developed as solving problems that humans have.

Stories and story writing as a craft within the scrum framework is a wicked problem. In my experience it takes time and practice to achieve the right balance between too big and too small. Breaking features into stories along scenario lines is a good way to achieve this balance. Scenarios here differ somewhat from the UX definition of scenarios, but quickly, in scrum story terms adding anything except the 'happy path' scenario is considered a new scenario for the story as a whole.

Lemme illustrate with an example. (FYI this is basically applying BDD to the problem)

If the feature is 'Wish List' for your site, a user story would be:

Story:
As a regular customer
I want to add an item to my wish list
So that I can easily later create an order of items I want to buy

Happy path scenario:
Given I am a logged in user
When I add 'Sugar' to my wish list
Then 'Sugar' should appear in the list

Another scenario could be for example if I did not have an account or if I wasn't logged in.

These basic stories would then be prioritised into creating a release of what has been called 'a walking skeleton'. The trick here is figuring out what the critical features are that are needed to appeal to your users and then giving it to them ASAP. Get their feedback and then use that to drive the priorities of the additional features or improvements your software needs.

The reality is that, try as you might, you cannot anticipate all that the product needs and getting early feedback and incorporating it into your product is the key to success.

Regards,

Carlo

m: +27 83 292 6632
t: twitter.com/ironicbuddha
w: http://carlokruger.com

To unsubscribe from this group, send email to sa-ux-forum...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/sa-ux-forum?hl=en.

[Lynnsey]

@Carlo, can you recommend a good easy-to-read reference site on scrum?

@John,

Rough sketches are good! Keep sketching. What you want to avoid is
getting bogged down in an unnecessary amount of detail. (Unnecessary
of course depends on where you are in the design cycle.)

Once you've decided WHAT the system must do, you can think about HOW
it must do them. Working out your flows is critical for this. You need
to know how your user is going to interact with the system (and in
some cases with other systems or non-system "things" in the same
session, such as a digitag, or a legacy system containing data that
couldn't be integrated into your new application; for example this
morning I tried to enter my husband's ID number into a phone keypad
while reading it from an SMS - Telkom decided I was taking too long
and cut me off - BAD interaction design).

The best flows don't happen automatically - you need to map them out
and then look at them with a critical eye, look for inconsistencies,
redundancies, repetition, things happening in the wrong sequence,
making the user do the job of the technology, etc, and weed them out.
Also, when you work out these flows, try not to think in terms of
screens but in steps. You can figure out how to break them up into
screens later on.

To learn about keeping your feature set pared down to the essentials,
try 37 Signals' book "Getting Real" which you can read online for free
at http://gettingreal.37signals.com/toc.php. Chapter 5 deals with
Features but the whole book is worth a read for their insights into
creating successful software. And this book also supports Carlo's
comment on (not) getting it right the first time (last two paragraphs
of his post). I think the key to getting this right is to listen to
what people are saying and be responsive. People are forgiving of
imperfect products if they know you will listen and consider their
feedback.

In terms of other books, I don't have a huge library (too expensive)
so I do a lot of reading online. I will post separately a list of the
sites I've found helpful.

Best regards,
Lynnsey

PS- came across a great quote today:

Designing an object to be simple and clear takes at least twice as
long as the usual way. It requires concentration at the outset on how
a clear and simple system would work, followed by the steps required
to make it that way -- steps which are often much harder and more
complex than the ordinary ones. -T. H. Nelson, "The Home Computer
Revolution," 1977

[Carlo Kruger]

Hi Lynnsey

I don't think it's possible to express what scrum is in an easy to understand set of references. As part of my service to the community and my role on the local user group, I (or one of my colleagues) usually do a 90 minute presentation on agile and scrum. And even that is usually inadequate. Depending on where you are (I'm in Cape Town) I would be more than happy to chat f2f about it.

In absence of that I present the following:

http://agileanarchy.wordpress.com/scrum-a-new-way-of-thinking/
http://www.scrumalliance.org/pages/what_is_scrum

You'll notice from the articles above that nowhere are user stories mentioned. For an explanation of those take a look at:

http://www.scrumalliance.org/articles/89-focus-on-value
http://www.mountaingoatsoftware.com/articles/27-advantages-of-user-stories-for-requirements

FYI there is a Scrum User group meeting on Wednesday 2 December which is free and open to the public. If you're keen to find out more take a look at:

http://www.scrum.org.za/events/scrum-beer-2-december-2009

and sign up

I'm keen to include the topic of UX and scrum/agile next year as one of our discussion topics

Regards,

Carlo


m: +27 83 292 6632
t: twitter.com/ironicbuddha
w: http://carlokruger.com

PS: additional and interesting links on scrum:

http://agileanarchy.wordpress.com/2009/09/20/simple-scrum/
http://agilethinking.net/essence-of-scrum
http://agileanarchy.wordpress.com/2009/10/08/scrum-roles-an-abstraction/
http://xprogramming.com/xpmag/expCardConversationConfirmation

[Phil]

Well Carlo, if you'd like me to come talk about my experience of ucd
+agile next year, let me know.

I don't know all the answers. But I have a few war stories.

--phil--

http://fronttoback.org

[John]

@Carlo: Thanks for the more detailed breakdown re stories and
scenarios. Typically how many of them do you find necessary for each
project? So far I have a rough idea of 7 for mine. Also, how are
they different from creating a profile of some typical users to focus
on?

The other issue that I am having right now is that if I leave out a
feature for the initial focus that I know will be in there in the near
future, how do I account for the fact that it needs a place in the
UI? Do I just change the UI when it gets added and possibly move some
parts from where customers are used to them being? Tricky question
for me, and one that I think could benefit from other people's
experience :)

@Lynnsey: Thanks for the advice. I've actually recently read the
link that you posted. It's what changed my point of view application
development. There is just so much to take in that often I find
myself doing something that I know I shouldn't just out of habit
almost. It's a long road to change perspective, but I feel lighter
the more I travel it. Hoping to fly soon :)

[Carlo Kruger]

Hi John

The rule of thumb to bear in mind is that a story should be a small piece of functionality that can be completed (as in ready to be released for public consumption) in about 2 days.

The trick is that unlike a traditional project structure, you don't try and do them all upfront and in detail. Let the requirements emerge as you build the product. What I encourage product owners to do is identify the main themes and break those down into features. Then identify the key three or four features and break those down into stories. In all you should end up with about 10 or so stories that you're gonna work on next, 10 - 15 features that will get broken down as you need to for the next iterations, and 10 or so themes (which are really placeholders for future enhancements) for a total of about 35 - 50 items.

The hard part is in designing the product in such a way that it embraces the changes which will be uncovered as you build.

The user profiling you're talking about is an important method for us to identify the stories/features the product needs. It also helps with prioritisation. For example, it may not be as important to satisfy the features required by the profile of a frequent/power user, when you're launching.

As for evolving your UI. The XP community has a pithy saying; YAGNI (You ain't gonna need it). You might be positive in your assessment that clearly people will need a feature, but in reality if you give yourself the chance to hear from your users, then you're likely to find their needs and priorities might be quite different.

I also think that as our experience with the web has deepened, people have become more accommodating of change. I think the challenge we now face as designers is how to evolve design in such a way as to lead our users to the new without losing them along the way. (I am reminded of how Twitter launched their 'Lists' functionality or RT in the last few weeks)

Regards,

Carlo

m: +27 83 292 6632
t: twitter.com/ironicbuddha
w: http://carlokruger.com

[Andy]

Hi John,

I'm using oDesk too, just like you, I need prototyping tool to help
others understand what I need. Balsamiq and Axure are both famous
tool in this field, and they are quite different. Balsamiq is very
easy to use, can create mockup very fast, with dirty hand drawn style;
Axure is heavy, hard to learn, but very powerful, you can use it to
create rich, interactive prototype.

For me they are both useful, Balsamiq can express your rough idea and
Axure can help you make detailed design. However I just found an
interesting tool named "ForeUI", it is very easy to use and seems that
it can do most things that Balsamiq and Axure do. Its skinning
feature can change the prototpye fidelity, and its behavior editor can
make prototype interactive. You can take a look at http://www.foreui.com/

My two cents :-)

Regards.
Andy

[John]

@ Carlo: Okay, so I'm going to be a story writer now :) Well, at
least some short little ones for the time being.

@ Andy: The link you gave looks interesting. It seems like a really
nice option, but knowing Axure and Balsamiq for now, I will stick to
them and try get something done. I tend to spend too much time with
new tools and not enough time doing stuff already. It's on my list
for when I have time to kill though :) How have you found oDesk so
far?

~John

On Nov 30, 1:28 pm, Andy <anyu...@aol.com> wrote:
> Hi John,
>
> I'm using oDesk too, just like you, I need prototyping tool to help
> others understand what I need.  Balsamiq and Axure are both famous
> tool in this field, and they are quite different.  Balsamiq is very
> easy to use, can create mockup very fast, with dirty hand drawn style;
> Axure is heavy, hard to learn, but very powerful, you can use it to
> create rich, interactive prototype.
>
> For me they are both useful, Balsamiq can express your rough idea and
> Axure can help you make detailed design.  However I just found an
> interesting tool named "ForeUI", it is very easy to use and seems that
> it can do most things that Balsamiq and Axure do.  Its skinning
> feature can change the prototpye fidelity, and its behavior editor can

> make prototype interactive.  You can take a look athttp://www.foreui.com/