A&D - analysis & design

A company (UX) maturity model

I published a short post about Companies' UX maturity in the UX Leadership Journal, an interesting Journal – check it out.

It is a response to a blog post from Adaptive Path - you should read it first... (also short :) ) 

Comments [0]

Editing map & text

Our geographic information system requires a quick transfer between text editing and spatial editing (for a simplified example see distance measurement in Google maps, make sure to switch distance measure ‘on’).


This is not an easy task for the user and not a trivial design for designer. In general you can let users to go through a very smooth process, so they can go between the map and a form or a panel and edit what is relevant. When focusing on the map they edit map objects when focusing on the dialog they edit dialog fields. But what if they want to do other operations on the map before editing, like zoom or pan? In some cases you can incorporate, if editing requires only mouse clicks while zoom is done with mouse ruler and pan with mouse dragging. But that is not always the case.

If you need to use mouse dragging for editing as well, the design should separate editing from other map operations. It is then possible to let the user select (e.g. clicking a button) that she will now initiate map editing, this way it is clear to the user what is the current status of interaction, that’s good right? Not sure. Testing with a few users show that they go straight to the map for editing, they do not look for a button before they start editing. We have both a desktop application and a web application and I suspect that expectation may be different. Still need to check that. I am wondering what to do if we receive different results when testing both platforms. That’s a tough one. Please share your experience with me.

Comments [0]

"Do you need this report?"

When dealing with information systems, you always need to deal with reports and dashboards. There are various tools to generate them and countless ways to present. Companies are working hard to improve the presentation of information they have. Databases and file storage are getting bigger as we gather more information, over a longer period and since HD memory is getting so much cheaper, we have no reason not to save it all. And then we want to do something with it, right? Analyze it, present it to managers, produce knowledge out of data. How do you do it? Well one aspect is how you present this data, Stephen Few is a great reading on this topic, but this is not my focus.

My focus is on the questions. 

  ©cc by Okaiuz
What does the user want to know? What does she need to know? When I present a report or a graph to a manager and ask her – do you want this? I often receive a positive answer. Will she ever look at it again? Not so sure. While looking at it she was thinking – mm interesting, yes, maybe I will take a look at this type of report from time to time; it will give me XX information… but with the daily load of information she will never get to it. We must find ways to produce reports that will give real value. It is so easy to suggest reports, so difficult to suggest a good one.

Research about users’ goals is (or should) always part of our research phase. It is never easy because users are rarely explicitly aware of their goals. When dealing with tasks and processes you can usually get most of it from interviews, inquiry and analysis. But when it is about presenting information there are often two levels of findings. Some reports are easy to figure, they include information users may already use and users tend to know what they need. The next level is more difficult, this is information that could not be accessed before, complex reports that join different types of information (from different tables or data sources). You rarely get users to request it, but that doesn’t mean they will not gain from it. I find personas and storytelling helpful here; you need to see the world from your user perspective, not just to know them well but to feel them. You need good understanding and empathy for your user. Getting close to the user is an important part of being a good designer.

Comments [2]

Is your design process a scientific method?

I have a weakness for science methods... I’ve mentioned it before. Dan Saffer just wrote about the design process and the scientific method. In short Saffer gives a good explanation why the design process is not a scientific method: a scientific process should lead to repeatable outcomes, while a design will (and should!) not. I agree.

UX professionals, as in other social / humanity professions, usually choose between a scientific view of their profession and a more humanity / quality / creative view. Social sciences are relatively new fields of science and for many years striving to prove that they deserve the “science” title. Postmodernism winds have changed it a little but still for the wide public the scientific title gives an integrity certificate to whatever people do. I know math & physics seems complicated to most people (and both are in many ways) but dealing with people is always more complicated and a bigger challenge in my view.  With no definite rules, no one paradigm, no outcome twice (even when you pursue the same process, as Saffer pointed out) you need more than “just” a scientific method to achieve a solution. Yes, I agree research will help, problem solving methods help too but none of these tells the full story of a design process, there is more into it.

So while some UX’ers invest in research, processes and methods other claim it is all about creativity, sketching and doing good. Is there a road in between? I hope so cause that is where I’m heading. Which way are you?

Filed under  //   design   research   UX  

Comments [3]

Land Information Systems

I’ve missed writing regularly here for the most trivial reason – work overload. It’s not an excuse I know. Anyway the reason for this load was a tender response I was involved in that took a lot of my time. It was for a cadastre (land) information system (which is one of our main areas here in Sivan Design). The subject of land systems is a fascinating one, may not sound like it when you first hear about it, but if you have interest in people, in developing economies, in the power of information – it is.

A land information system presents a legal option of land ownership. It may sound trivial for some of you, but in many countries receiving land ownership is difficult and only a very small percent of land parcels have a registered owner. In some countries there are unofficial tenure systems that make things even more complicated. This tender was for a former USSR country which has a different angle, because private land ownership is a relatively new concept…

A great way to learn about the importance of land ownership and registration is to hear or read Hernando De-Soto , a Peruvian economist known for his work on the importance of property rights. He gave a very interesting keynote lecture in the last ESRI conference, unfortunately the video is missing recently – it was an inspiring one. He presents a strict view of the connection between properties rights and economy growth. According to De-Soto formal land registration is crucial because of credit options, sense of stability, utilities development and taxes collection, which all effect economy.
There are critics, obviously, they may be right to some extent, land registration is no miracle it is a tool. And as in any other complicated situation it cannot solely control economy. If government is not stable or corrupt, it will not fix it. But I feel it can start the ball rolling.

Land information systems are highly complex! A land information system is usually used by a few groups of users: government officials, business organizations (lawyers, real estate agents, etc.) and the public, with each group having very different characteristics. These users have various tasks and processes to complete, so the system must include tools for structuring processes and monitoring them. Another complexity is the use of both regular (textual) information – Who is the owner of the land? and spatial (mapping, survey) data – Where is the land?, so you can imagine the complexities involved.
When designing a land system, it is not only about design, but also about content. Design can be challenging (or not) in many different ways but when the content is meaningful for you …it blows your sails…

It is not the first time we respond to such a tender but it is a great challenge every time -
Good luck to us J

Filed under  //   GIS  

Comments [1]

A day in Addis Ababa

I just came back from a day trip to Addis Ababa.

The business didn’t go so well (yet!) but I got a glimpse of Ethiopian music and dance (and food). I love dancing in general and ethnic dancing in particular so it was a great ending for a hectic day!


The Place

Playing music & dancing

         

After a while the place was packed

They have incredible shoulder movements and a lot of energy in the upper body, I uploaded a few seconds video to YouTube if you want to see it in action.
I only had my iPhone with me so quality is not that good, but worth watching anyway. Enjoy!

 

Filed under  //   culture  

Comments [2]

The design process (of sunglasses)

See this movie (via Core77) for a great description of a design process. Although I never designed a product that is not software, the process described in this film is so familiar and so similar to a software UX design. It is both trivial and surprising.

The movie presents the following process:
Designer gets to know the users (e.g. bike riders), their needs and consider the experience they are looking for > sketch a few options > prepare a rough model > test it.
Then designer take the results to the computer, make a mockup and add details (e.g. detailed design) > prepare a detailed model > and test it.  >> Iterate and redo this until they achieve user satisfaction.

If you think this is simple – try to pull it off in a software company J

I loved the last comment about the “wow” reaction when you see people using your design (and enjoy it), this is why I’m in this business, and Muller expressed it exactly as I feel it.

Filed under  //   design   UX  

Comments [1]

Culture & design in Israel

I found Fletcher post about culture and design in India and China very interesting. It immediately made me think about UX in Israel, something that I already discussed before.

Fletcher pointed out two important design abilities: understanding the big picture and attention for details which, I agree, are both important for a good UX design.

If I may summarize Fletcher ideas, although I do urge you to read the full post, attention to details can be undermined as a result of:
- Daily life isn’t easy so details seem like a luxury, if something works – it’s good enough
- Education programs are lacking
- Not enough UX experience

Details are treated better when:
- People are used to do as told and tend to follow requirements in an exact manner
- A culture that values mastering old techniques rather than inventing new ones

So where is Israel on these continuums? Well I would easily say on the Indian side.

> Life in Israel is probably easier than in India, as for the perspective Fletcher is giving, but then it is easy to say we have more important things to consider then design details. I’m not sure this is true for UX practitioners but for Israeli users, details can be perceived as luxury. Also for policy makers of websites and software companies – it can be a reason for not investing in UX (unless they have international management or international users).

> Education programs for UX are definitely lacking, actually the big universities for all I know (Tel Aviv and Jerusalem) don’t have programs in UX at all!

> Add to that the absence of “chain of command” in the Israel culture, on the contrary – we always argue J and usually everyone has their own opinion when it comes to interface design.

> We are great with inventions even if we are a bit conservative. Anyway an Israeli will always adapt a short cut if available rather than “master an old technique”, so if we can cut down on the details, it is a win win situation.

> I would add to that our tendency to “round” corners, which is a known Israeli “pride” and does not work great with UX details.

> About experience, I’m not that sure, we had a good start as the army and related industries has UX (or Human Factors) for a long time, but somehow it did not pass on to the civil software industry. I don’t have a good explanation as technology tend to pass on a lot…

There is more in UX than details, I know, but this is a good point for considering the cultural significant in UX design. Despite the above list, I consider my fellow UX designer in Israel to be rather good in dealing with details, but hey I’m an Israeli too, so I’m not sure it counts.

I would love to know what you think – take a moment to share your thoughts.

Filed under  //   culture   design   Israel   UX  

Comments [2]

The small details

When we define UX we usually talk about the big picture. The big picture is the important stuff.
But UX can also mean small-tiny improvements.
Today a programmer came to me with a small addition to one of our products – an auto save option. That’s it. What can you do wrong here, right?  nope.

So here it is. She was planning to add this:

What can you do better?
1-Change the text box to a spin
2-Make sure the default is not 1 min. (15 min. seems more reasonable)
3-Make it enabled only when checked
4-Move the units


These are really small details, you only need basic UX knowledge. But this is also UX.

Click here to download:
oledata.mso (32 KB)

Filed under  //   design  

Comments [2]

UX practitioners' task list

 The IA institute published their 2009 salary survey. What I found interesting is the task statistics they present.  I meet many people who ask me about the task list of a UX designer. Some of them are junior designers some are managers that are considering a UX practitioner on board. I usually hesitate with the answer. UX is a wide variety of tasks; the exact combination depends on the person fulfilling the position, the specific product and, of course, the company including its culture and other professionals available.

That is a very general answer, a genuine one but not so helpful… The statistics from the IA survey may give a good example of the variety I’m talking about. Here is my summary of it.

The survey asked about the time dedicated for a task, interestingly enough, none of the tasks received a score of “this is all what I do”, meaning no UX practitioner is devoting her time to one primary task, it is always a list of tasks. Frequent answer for most tasks was “occasionally (not every day)”.

So what do we do most of our time?

Task

Score*

Wireframing/Sitemaps/Process flows

61

Interaction design

55

Strategic work
(business models, high-level categorization, scenario development, life cycle assessment)

45

Other user research

41

Audience definitions/Persona development

38

Usability testing

36

Project management

36

Graphic/interface design

31

Content management/strategy

30

Staff training/recruiting/team management

27

General business consulting

26

Travel

25

Taxonomy development (thesauri, metadata, controlled vocabularies, etc.)

25

Marketing/proposal writing

23

Content generation/copywriting

22

Business administration/operations (non-IA)

21

General IT consulting

13

IT integration/programming

12

Database design

9

*Score is a weighted combination of number of responders and time they spend on a task (this is my score you can see original numbers in the Survey report)

Although the survey provided quite a long list of tasks, many people felt it is not exhaustive and added more tasks under the “other” category:

  • Building and documenting the internal design research practice
  • Business requirements, functional specification creation
  • Business semantic and metadata management
  • Collaboration and knowledge sharing
  • Contextual inquiry, survey analysis, search data analysis
  • Evangelizing user experience research findings and recommendations
  • Meeting with clients to review current work and understand business requirements.
  • Presenting (ideas, lectures, etc)
  • Prototypes development, product roadmaps
  • Prototyping
  • Qualitative data analysis
  • Report generation
  • Requirements gathering, requirements management, use cases
  • Research
  • Review the work of development teams for compliance with corporate design standards
  • Specification writing, design reviews
  • UI implementation
  • Writing use cases and stories for agile product development
  • Business analysis, requirements development, QA, testing
  • Content and/or competitive assessments
  • Domain modeling, evangelism, workshops, meetings
  • Evangelism - communication - selling IA
  • Evangelizing strategy
  • Front-end development, production, document creation - style guide, spec creation, gathering and defining requirements
  • Internal education
  • Managing internal (customer) relationships
  • Presentation creation
  • Problem solving
  • Product management
  • Product strategy and management
  • Project-specific problem-solving; internal consults
  • Social media: strategy and monitoring
  • Writing reports

55 of the 431 responders added more tasks - it is a large number suggesting the need for more task options was significant.

It is important to note that this is probably a good picture of the current situation (mainly in the US – about 70% of responders), but not necessarily the desired one…

Filed under  //   UX  

Comments [0]