Efecte Blog

When you first bump into a new website or piece of software, the first thing you see before you dare to click anything is the visuals; colors, shapes, images, fonts, contrast. Jesse James Garrett calls this the surface. In other source, this is referred as aesthetic appeal. In my previous post I promised to write about different aspects of user experience and I thought of starting from the most visible part.

Tip of the Iceberg

One of the best things about visuals is that everybody has an opinion about them. This means that it is very easy to get feedback – I can ask from a colleague in the cubicle next to mine and get instant feedback. Because the nature of visuals is static, I can also show the visual proposals through website or via mail to get feedback from very large amount of people. Unfortunately, the opinions people have differ greatly from each other and asking from very large amount of people is probably not the way to go. Mainly, because more people you ask more varied opinion-base you will get. Take colors for example: if you ask enough for many people and narrow down the possible colors to use in your software, you probably end up in a situation where there are no colors to choose from. Or perhaps you will have two colors. Who hates black or white -  most probably someone? To overcome this problem, there needs to a be a despot in the organization who decides about the visuals. This despot can be a predefined document that people follow, usually called Look and Feel (LAF) document or a style guide, or the despot can be an individual in the company. I’m not saying that this despot should not ask for feedback on visuals, but this despot’s main responsibility should be to keep the visuals consistent, and according to company brand.

Overall visual consistency, brand identity and visibility are the two most important aspects of software visuals. Overall visual consistency is one of the important aspects in creating consistent user experience. Consistency in this refers to  usage of visual cues and elements in similar manner in similar contexts and reusing these same patters where applicable. Company brand visibility in the visuals is important from overall user experience perspective to ensure that the experience created outside the usage of the software, like with customer visit, website visits and other marketing efforts are also linked to the software. Consistent and uniformly presented brand identity helps in leveraging this impact through the use of the software.

Of course it does not hurt to make the visuals also beautiful, but when it comes to building user experience, if company brand is not built on beauty, the software created does not need to be built on it either. And as with opinions on visuals, beauty is also in the eye of the beholder.

If, however, the visuals are the only thing in a place in a piece of software, the software diminishes to a painting. If your goal was to use the software to solve some problem, the mere painting will not probably solve your problem. And of course, if your goal was to enjoy nice painting or two, there are probably more pleasant environments to do this, like Louvre or Eremitage . To make sure you are not just looking at a nice looking painting, ask for a live demo or try the piece of software yourself. You will know in minutes if you are looking at a real software or just a nice painting.

So what lies beneath the surface that really makes the difference when it comes to a truly great user experience? I’ll share some of my insights in the next post -  so stay tuned!

Experience matters – that’s the key idea for our employee self-service product. The big question is: how much does experience actually matter? Think a bit of all the experience and knowledge that you have gathered during the years…… Mind boggling isn’t it? All the experience that I have: as a concept it is something that is truly out of my grasp. The sheer amount of tangible, intangible, conscious and unconscious experience that affects all the decisions that we make is just too great to comprehend.

The expression “Experience matters” tries to refer to something new experienced using a particular software. Still, the old experiences have great effect on the new experience caused by the software. So how to limit the effects of this old experience to the new one? There is, of course, no proven way to do this limitation, but certain experiences can be neglected as having only minor effect on the experience. On the other hand, certain experiences have much stronger effect. If you consider for instance time, usually if the experience has not been very traumatizing, more recent experiences have typically more weight when considering how the new experience really feels like. Also, context of the experience has more weight the closer the experience is in context related to the new experience. For instance, usage of computers and different software has usually greater weight to the new experience felt when using an another software, when compared to the weight of for example a skiing trip to the Alps.

Use of software can sometimes draw users’ full attention – like when teenagers play some fairly addictive game. It may seem that nothing can distract them and their full attention is drawn by the game. In this situation, the game can actually fairly well control the current experience spiced up of course with the previous experiences of the teenager. Typically there are, however, plenty of distractions present when using software. If I consider myself in the office, the list of distractions is fairly long: people come to chat fairly often, emails keep popping up, Skype and Communicator chat sing all the time, phone rings from time to time. And that’s only the internal distractions. In addition, in an open office environment there is at least the same amount of external distractions. All these distractions have an effect on the overall experience.

Different User Roles

The issues described above are something that we as a software company have no control over. But there are, however, many things that we can control. The self-service product that we are developing is meant to solve certain problems. All people do not have these problems. This starts to limit the amount of different kind of users able to use the channel. We can go further and defined user roles to categorize potential users. And in fact now that I have babbled all along about experience there is already an existing “field” and buzz-word called User experience or UX that has plenty of tools to tackle the issues related to experience of users’ using software products.

Jesse James Garrett has fairly well described the different elements related to User experience in his book. These elements from concrete to abstract include:

•   Surface (Visual appeal)
•   Skeleton (UI design)
•   Structure (Information architecture)
•   Scope (Product backlog)
•   Strategy

In the future blog entries I try to tackle each of these elements in more detail. Tell more how we face these elements? And what are biggest problems, fallacies and pitfalls related to these elements?

So stay tuned!

We all probably had our favorite bedtime stories as a child. One of my favorites was a story about Pablo the penguin. It’s about a penguin who is always feeling cold and tries to come up with different means to keep warm. To spoil the whole story, in the end Pablo surfs with his bathtub through the oceans towards warmth using the ocean water coming from the sink. Physicist buddies of mine would state that it is impossible and against the laws of physics.

Times have changed and now part of my profession is about writing stories. You all probably heard about user stories. And if you have been involved with agile software development, you know that user stories are the building blocks of an agile software development backlog. Stories are sentences in the business language of the end user that captures what the user wants to achieve. In addition to this, user stories should also fulfill the INVEST criteria, i.e. stories should be Independent, Negotiable, Valuable, Estimatable, Small, and Testable. Simple right? Well, not necessarily. To create stories that fulfill these criteria, product owners need to grasp the market needs, user needs and iterate over and over again with the development team. This is the bread and butter of product owners in agile projects. The only problem in these criteria is that they have been created to support the agile software development, but agile software development itself does not support creation of easy-to-use software.

So how to create stories that also support easy-to-use software?

1. As a  <Role>, … when writing the stories make sure the user role from which the story is written, has a persona defined
2. Independent: although the stories need to be independent from each other, they also need to map to at least one user workflow to create connection points to existing users’ stories that have been created. Or then, the story itself needs to create a workflow of it’s own.
3. Negotiable: to ensure also the negotiability on the ease-of-use there needs to be sketches the users and product managers can comment and negotiate. Same kind of negotiability needs to be achieved through usability testing of the prototypes and ready-made software.
4. Valuable: stories need to be valuable for the market, and for the buyer, but the most important part in creating easy-to-use software is to make sure the stories are valuable to the real users of the software. The users needs to have a real problem that the software solves – and solves it well thus creating value.

Just as with children’s books the ones that are on the top of the pile are the one read most often – in product backlog the stories with most value are also on the top of the pile. And actually the same applies for the UI design for stories: the stories used the most in the software should be on top of the pile, that is, visible in the first view of the software. Biggest problems in creating the pile arise from the fact that just as most of us had a different favorite story as a child, so do users have different problems that they need to solve.

By creation simple stories that at the same time fulfill all the criteria define above, we are one step closer in creating also simple and easy-to-use software. Impossible could my physicist buddies say. But I assure that we will do this and ride the bathtub side-by-side with Pablo towards the warmth of the south!

Site-note: Actually Pablo is probably riding north, because he is from the south-pole, but I prefer south especially at the moment.

itSMF-vuosikonferenssissa  järjestämässämme workshopissamme Sampo Pasanen esitteli loppukäyttäjille suunnattua palvelukatalogia ja Efecten ajatuksia itsepalvelusta. Tilaisuudessa nousi esiin paljon kysymyksiä, joista inspiroituneena Sampo päätti kirjoittaa blogisarjan, josta alla neljäs ja viimeinen osa. Kommentoi ja jaa mielipiteesi!

Katalogin ylläpito ja kehitys

Laitemallit ja versiot muuttuvat jatkuvasti. Miten katalogi suhtautuu tähän?

Loppukäyttäjää harvoin kiinnostaa laitteeseen liittyvät yksityiskohdat. Katalogi kannattaa rakentaa standardoitujen laitekategorioiden ympärille. Sen sijaan että katalogissa on valittavana teknisiä laitemalleja, kuten Dell Latitude E6410, siellä tulee olla ”Kannettava”, ”Kevytkannettava”, ”Tehokannettava” jne. Itse kuvaukseen voidaan haluttaessa lisätä esim. linkki laitemallin kuvaukseen. Näin toimittaessa katalogin rakenne ei muutu ja käyttäjien on helppo löytää haluamansa palvelut.

Puhelimet koetaan henkilökohtaisemmin, ja niiden merkistä ja mallista ollaan kiinnostuneempia. Puhelinten tapauksessa usein on päädytty mallikohtaiseen katalogiin kategorioinnin sijaan:

Esimerkki palvelukatalogin puhelinvaihtoehdoista

”Nokia E9”, ”Apple iPhone”, ”Samsung Galaxy S (Android)”.

Ohjelmistoissa joidenkin ohjelmien versioinnilla on myös merkitystä. Siinä missä Skypen versio ei ole käyttäjän kannalta kiinnostava, Adobe Photoshopin tai Windowsin versio voi olla hyvinkin merkityksellinen. Peukalosääntönä kannattaa välttää versioiden korostamista ja ainoastaan niiden sovellusten osalta joissa sillä todella on merkitystä, se kannattaa ottaa huomioon. Joistakin ohjelmistoista täytyy tarjota useampia vaihtoehtoisia versioita samaan aikaan.

Mitä katalogiin kannattaa sisällyttää pitkällä aikavälillä?

IT:stä tulee itsepalvelua. Itsepalvelu on ylivoimainen tapa tuottaa korkeatasoista peruspalvelua kustannustehokkaasti. Mitä enemmän katalogiin voidaan viedä asioita, joita käyttäjät tarvitsevat, sen parempi. Kaikki mahdollinen kannattaa tuoda katalogiin ainakin saataville. Se, että tapahtuuko varsinainen tilaaminen kaikissa tapauksissa kyseisestä järjestelmästä, on toinen kysymys.

Tuodaanko katalogiin kaikki palvelut kaikilta yksiköiltä ja toimittajilta?

Tähän kysymykseen ei ole yksiselitteistä vastausta. Oleellisia kysymyksiä jokaisen eri tilauskanavan kohdalla ovat:

• Käytetäänkö kanavaa oikeasti, vai menevätkö tilaukset service deskin tai jonkin muun tahon kautta?
• Kuinka tyytyväisiä käyttäjät ovat kyseiseen tilauskanavaan?
• Kuinka paljon aikaa organisaatio käyttää tilaamiseen kanavan kautta?
• Voidaanko kanava korvata helposti katalogin toiminnallisuuksilla?

Katalogin kautta tulee päästä käsiksi palveluihin mahdollisimman laajalti, mutta itse tilaamista ei tarvitse kaikissa tapauksissa tehdä katalogista, jos perusteet muiden kanavien käyttöön ovat olemassa.

Kuka vastaa päivittämisestä?

Tässä on kaksi vaihtoehtoista mallia: yksi keskitetty henkilö/funktio hoitaa kaikki muutokset, tai palveluista vastaavat hoitavat itse myös katalogia. Molemmat mallit voivat toimia, mutta aluksi suosittelen käyttämään keskitettyä henkilöä / tiimiä, jotta kuvauksista tulee yhdenmukaisia ja hyvät käytännöt palveluiden kuvaamiseksi saadaan luotua.

Simplify

There’s a clear message from management to all IT leaders: simplify. 

We’ve met a number of top officers from both G2000 companies and mid-sized organizations during the last few months. Management is totally fed up with the growing number and complexity of IT systems, and (not surprisingly) the costs that follow. Here are some direct quotes: 

“No more IT stuff !!!” – management board member in a G2000 company.

“I’ve given tens of millions to IT. It’s not about resources, it’s about getting the job done.” – management board member in a company of 5000 employees.

“Enlighted CIOs bring light to the organizations through simplification.” – Kati Hagros, CIO, Kone (blog post in Finnish). 

And the list goes on. 

This often results from the following

• No real vision exists for IT development and IT is developed from inside out, not from outside in
• No knowhow in generating user friendly solutions –> unnecessary complexity in the actual implementations and processes
• IT is full of management and leadership is missing –> big changes that would be needed to make a real impact aren’t implemented

This leads to IT being developed in silos and big picture is missed. Who suffers? Users, and eventually business. Luckily, first signs for customer centric outside-in development have started to form. Now it just takes will, effort and stamina to build a simpler IT. The change won’t happen overnight: start from quick wins but don’t forget the long-term development.

Efecte’s role is to simplify the interaction between employees and IT with self-service solutions. What are you going to simplify next?

Sketches to choose from

There is no choice, if you only have one option. Or well in that case you still probably have two options, as Rolling Stones had back in 1981: Take It or Leave It. If you should, however, decide a new business application to solve certain problems that you are having in your organization, the option to leave it is really not part of your vocabulary. You have to choose something. To make a better choice there should always be plenty of options to choose from.

The same amount of options applies in user interface design. Stakeholders like product managers, potential customer, and user should have plenty of design sketches to choose from in every step of the product development. From design perspective this requires a lot of fresh and different ideas to solve the problem at hand. Luckily, we designers live and breath from the ideation process.

Bill Buxton says in his book about sketching that:

 ”You are always in the ideation process – it’s just the granularity that changes.”

Meaning that early on in the software development process, when there are only some initial market needs identified and not a single line of code written, the possible solution sketches can and should look fairly different from each other – clearly different ideas of the solution. As the software development continues, the sketches will become more precise and focus on narrower area of the upcoming solution.  The amount of different solution sketches or even simple prototypes should still be big enough to give stakeholders room to comment and options to choose from.

The initial sketches act as a good visual channel to communicate the possible solutions and verify that the market need is understood correctly in both sides of the fence. Later on, when the sketches become prototypes and prototypes become production-ready software, the means to gather feedback changes. Now there are not that many options anymore and feedback is received through different usability testing methods. What remains, is the need to give enough options and receive invaluable feedback to support the continuous improvement on the design at hand.

In the end, there is only a set of production-ready business application to choose from, it is time to make the final choice: Take one and leave the rest behind.

I have heard a couple of times people referring certain software as “Professional software” – meaning software so difficult to use or even understand that there are usually just few “experts” in the company who are willing and able to use it. I have heard a lot more often people asking for help in using some software claiming that they just cannot understand how this thing should work. Then the expert arrives and saves the day. The expert is the hero and the one asking for help is probably feeling inadequate, especially if the software in question should be used daily.

Just pick the right software to use and you are the expert!

There are many reasons that these kinds of software exist. Most were created too quickly, with too few people and with too many features. The first thing that goes out of the window in this situation is usually ease of use, if it was ever even in. The initial user role that the software was meant for is forgotten. The software’s UI becomes a representation of the underlying code. The design in the underlying code may be the best in the world, but if the software’s UI is created with same logic – not with the logic of the users it is intended to – the outcome of the software cannot be good.

Some software were initially meant for some other use and for some other role. Then the usage of the software was extended to another role, but no changes were made to software itself to support this role. Then there are also a lot of software that were from the beginning meant for everybody, and afterwards are no good for anybody.

But there are, however, also real professional software. That is, so rich in features and complex in nature that you need to understand the surrounding field of expertise fairly deeply until the logic and usefulness of the software is at your grasp. E.g. in my work Adobe Photoshop is a good example. It is not meant for everybody, it is clearly meant and designed for graphic designer.

Next time you are buying either a ready-made or custom software ask the salesman: what is the most important user role that this software is meant for? If the salesman has a clear and rapid answer then there is higher probability that the software and it’s UI has also been build for this role.

You don’t need to feel inadequate – just pick the right software to use and you are the expert!

Do you know the saying ‘Stuck in a rut’? That is, living boring lifestyle that never changes. Mark Twain used this idiom in his famous speech about consistency.

There are those who would misteach us that to stick in a rut is consistency–and a virtue; and that to climb out of the rut is inconsistency–and a vice.

- Mark Twain, Consistency speech, 1887

He was talking about the misunderstandings of the word and how it was understood at that time as unchanging or immovable. The world has changed a lot from Twain’s times, but still consistency if you consider it as following processes and rules is still considered a beast of burden.

Cornerstones of consistency

Inside large companies there is a plethora of processes that you are obligated to follow just for process sake.  Mostly you are told to stick in a rut and follow the defined process. There is no feedback loop and no improvements done. This rigidness for the sake of consistency all around the company makes the processes the beasts. It is not the processes that are the beasts, but the company’s ability to react to change via the processes.

On the other hand, in smaller companies the lack of processes can be the thing causing problems. Employees have their own ways of working and have defined their own processes. And typically as you don’t need to inform anybody about the change in the process besides yourself. You end up using different “process” all the time. There is also another word for this: ad-hocking. Twain would probably call it being so much outside of the rut that you cannot even see the rut anymore.

Consistency is one of the cornerstones of good usability. Usually in this context, consistency is considered of being something that the users see and feel from user interface perspective, like user interface components, layouts, and visualization. Consistency in user experience can be extended to include also what the users need and what they do not need. This requires a lot of different activities – like market research, analysis of buyer and user persona, definition of use cases or user stories, prototype building, iteration over the actual product design – just to mention a few. I believe that in order to achieve consistency in these, following of defined processes is vital.

If you have good process that guides your work and truly makes your work easier, it is much more probable that you will also follow it. If you have chance via defined feedback loop like retrospectives to bring forth shortcomings in the process and even change the process to fix these problems, it is very likely that you will follow it.

—

Efecte’s blog team will now take a well-deserved summer leave. Have a consistently inconsistent summer and see you again with new topics in August!

There should also be sign posts in software to tell users where they are.

The other day I was discussing with a friend of mine who complained that her car navigation system had taken her 100 km detour to a location that was just 50 km away. More than an hour of extra time spent on a journey that should have taken only half an hour.

This made me think that I have taken numerous similar kinds of detours in the depths of different software and sometimes have been so lost that the only way out has been to go back home. This provided that the option to go home has been available. Other options have been to close browser tab or software altogether – similar to abandoning your car next to an emergency phone and calling for a taxi home.

If you compare for example Microsoft CRM to Google’s search page, you probably know what I’m talking about. Of course Microsoft CRM system is way more complex piece of software than Google search, but it’s the ideology that differs.

When following the usage of different software, it is clear that the users take 100 km detours all the time. Some software may even seem like a maze that the users cannot find out.

This should not be the case: we should demand the same kind of simple navigation help from the software as we demand from car navigation systems. User of a software typically has quite clear understanding were she wants to be, but only a vague idea how to get there. Software should state loud and clear: “From the next exit take a right turn and in 50 meters you have reached your goal”.

This is especially important for software that is used rarely. With ICT WebShop we created a software navigation that guides the end-user to the right direction. As Riitta Kohvakka from Tieto-Tapiola puts it:

 The look of the product and its browser-based interface are up-to-the-minute. It is a modern tool that guides end users through the operation they wish to complete.

As there are no junctions that have hundred different roads leading to it, in ideal world there should not be software screens that have hundred different options to choose from. As there are street names in the navigation systems and a red dot showing where you are, there should also be sign posts in software to tell users where they are.

Just as navigation systems are nowadays more and more frequently built into cars, so do software need to have built-in navigation systems that tell users where they are and where to turn next to reach the goal they are aiming for.