Mark Twain once said, “I didn’t have time to write you a short letter, so I wrote you a long one.” and emphasized the challenge of writing concisely. I myself had 9 years to write this letter. Now it’s time to honour the master.
AÇEV, Akrep, Alarko Carrier, Anadolu Hayat Emeklilik, ARÇELİK, Atölye, ATP Zenia, Borusan Holding, Brisa, Carnap.ai, CarrefourSA, Çelik Motor, Çetaş Otomotiv, Corendon Airlines, Decathlon, Denebunu, Domino’s, Eczacıbaşı, Elektronet, Estee Lauder, Eureko Sigorta, Fazla Gıda, Gain Media, Garanti Ödeme Sistemleri, Gedik Yatırım, GROUP M, Hackquarters, Hayat Varlık, HBR Türkiye, Hepsiburada, Hepsipay, Hippo, HIS Global, IATA, İş Bankası, Kale, Koç Holding, Koç Sistem, Kom Mayo, Kworks, Mastercard Advisors, Migros, N11, Newport Shipping, Optimum, Protranslate, Samsung Türkiye, Socrates Dergi ve Dijital Yayıncılık Sanayi, TANI, Tatilde Kirala, TEB, TELESURE, Teracity Yazılım, THY, VNGRS, Webrazzi, ZER…
When I sit in front of the keyboard to write this letter and focus on what we left behind in the last 5 years, I think of the valuable professionals we have had the opportunity to work with from the institutions above, which we have served in order to create a more effective user experience design, I realize that we took each step always to do our best and nothing less. Then I remember over and over again, how over 50 of my companions, with whom I had the chance to walk on this path, put themselves second for SHERPA’s success. I am proud of every pixel we drew, message we sent and hours we spent awake to find a better way. If I had to go all the way back to May 2013, to the days when I had no safety net, I wouldn’t hesitate to ask the same question again, with a heart full of belief: “Are you up for creating Turkey’s best user experience studio?”. How would one describe this? I don’t know. I make do by saying “we accomplished what we aimed for”.
We won’t stop!
Today, we are launching our new version, SHERPA 4.0 and we bid our POs (Project Owners) a farewell worthy of SHERPA culture. We’ll continue to do what we know best, designing human-system interactions, but from now on only with our friends at Paribu. We joined forces with them on January 1st, 2022, with the highly ambitious goal of designing the world of tomorrow. Together, we will sail out to vast seas full of unknowns, as we have never sailed before.
Yes, our mission now is even more ambitious. We won’t rest until we build Paribu’s current and new services in the global arena with our teammates from Paribu Technology Team. We won’t stop before designing the most effective human-system interactions for a multi-cultural and highly motivated user group which we aim to grow to 10 million and eventually to 100 million people. And finally, we won’t say “that’s it folks” until both Paribu and SHERPA’s names are cited proudly, or in short, until we have done everything in the name of user experience design.
There are some websites with heavy content and complex navigation structures. Before you visit them, you feel anxious about whether you’ll find what you’re looking at a glance. But once you start browsing, you experience a seamless information architecture intelligently designed and executed. My suggestion best case for those kinds of websites is gov.uk: UK Government’s Public Sector Information Website.
When I started investigating about the story of a single domain including 25 ministerial departments, 407 other agencies, and public bodies’ content, I found out that behind the scenes of this impressive digital transformation story lays down the initiative taken by the a.k.a “Digital Champion” Martha Lane Fox’s famous report named “Directgov 2010 and beyond: revolution, not evolution” targeting directly the UK Cabinet, emphasizing the need for a radical change in the way the UK Government digitally communicates. This report and the marginal economic gains proposed to the Cabinet were so clear and impactful that no one could stay still, and showing that one simple fact, well-told was enough to direct the rider, to motivate the elephant. Shaping the path was the next step. Government asked for feasibility on a huge project from GDS (Governmental Digital Services) with two simple but hard to achieve goals:
To test, in public, a prototype of a new, single UK Government website.
To design & build a UK Government website using open, agile, multi-disciplinary product development techniques and technologies, shaped by an obsession with meeting user needs.
With a bit of luck and the help of my dear friends (in this case, Kerem Alper) I had the chance to meet the man, the captain leading the team at the hardest times of this massive project: Ben Terrett, Head of Design @GDS 2011-2015. The story he shared with me was so inspiring and interesting that together we decided to publish it in Turkish at SHERPA’s Blog and in English at SHERPA website.
If you don’t know Ben yet, I’ll guarantee that you’ll be more than glad to know him. If you do know him already, you’ll find the chance to read about the behind-the-scenes of Gov.uk’s digital transformation, as well as actionable insights from Ben on design and product & team culture. So everyone will find something useful in this interview.
Not only being the one leading this transformation from 2011 to 2015 as the Head of Design @GDS, but Ben also has a really impressive professional background. Now he is the CEO of a Digital Transformation Agency, Public Digital, operating globally, where they help other world governments digitally transform.
Once we met, my first question was:
“You led a multi-disciplinary design team working across government on GOV.UK, and furthermore you joined the Cabinet Office when GDS was set up to deliver the recommendations in Martha Lane Fox’s “Digital by Default” report. How did you manage to put all of these into your basket? What is your secret sauce?”
Ben replied:
“Very kind, thank you. No secret sauce. I’m a designer and I do my hobby for a living which is a privilege. If I had to offer any advice it would be to always do things that interest you, to say yes more than no and to not be afraid of new opportunities. Take some risks. And always remember to focus on the quality of the work. If that’s good everything else will fall into place..”
Right after that answer, knowing how hard is to gain the RDI, Royal Designers for Industry title (he holds) as a designer, I asked him to enlighten me about the application procedure, requirements, and evaluation policies. He stated:
“It’s a real honor. I feel incredibly humbled as the other Royal Designers are incredible. I’ve since found out that everyone thinks that, even the most famous of the RDIs. There are only ever 200 RDIs at once and every year they get together and vote for new designers to receive the honor and join the group. Generally, they are looking for years of sustained excellence, design work that has improved the lives of others and a commitment to something like design education. Having now sat through a nomination and voting meeting I know how hard it is to meet that criteria. You don’t apply you get nominated, so it really is an honor.”
I confess that if someone had asked me to lead the design team whose responsibility would have been “the digital transformation of the UK’s public sector information” I’d be terrified at first. So I wondered how Ben felt when he was asked to lead this massive project. He replied:
“Simply to keep focused on the user need. To use design in a very functional way and not let traditional graphic design or marketing get in the way. To strip everything back and focus on getting tasks done online. I knew we would need a very strong typographic style and that a visual identity would come from being strict with simplicity. This blog post is a good example of that approach https://gds.blog.gov.uk/2013/06/18/retiring-our-icons/
I also wanted it to feel British with any nationalistic overtones. The New Transport typeface used on the UK road signs allowed us to achieve that. The designers Margaret Calvert and Kenneth Grange were very early inspirations for the project. Design-wise, it has a very modernist philosophy.”
Taking strength from Ben’s (to be respected) modesty, I could not restrain my curiosity and asked the question that its answer is probably the anticipated:
“To overcome the ever-growing requirements, never-ending scope changes, exhausting design feedback cycles and time pressure, what kind of design methodology you used to?”
The answer was shorter and clearer than I expected:
I knew that gov.uk launched in beta form in 2012 and replaced hundreds of public sector sites. It has wrapped in ministerial departments including the Foreign Office and the Ministry of Defence and organizations such as the Driving Standards Agency and HM Revenue and Customs. Since its implementation, gov.uk has become a one-stop-shop for Government services in the UK, letting people register for a birth certificate, apply for UK citizenship or find out when the next Bank Holiday is, all in one place. Gov.uk has been hailed for its design – in 2013 it won a Black Pencil at the D&AD Awards and was named Design of the Year by the Design Museum. That is quite a success.
However, I didn’t know the answer for, the “success criteria” of Ben. Did he succeed? He satisfied my curiosity:
“I didn’t really have a personal criterion. At GDS we had a very strong team culture and we were really focused on building a single domain that meets user needs. I wanted the design to help and be a part of that. I also felt that we should have a world-class design team and a world-class design output. We were funded by public money so we owe it to citizens to do work of the highest quality. I think we achieved that but although the awards were great, it was never a factor in my thinking or ambition.”
It was clear the gov.uk project had a sophisticated audience while working on government digital assets since there are lots of different personae. There should have been massive user research process to conduct, loads of insights to collect. Right after smiling meaningfully he stated:
“That’s a whole other interview :)”
And leaving the impression that user research was one of the hardest parts of the whole project deserving another stand-alone interview.
He gave a strict “No” answer for my “Did you work on a more challenging project than Gov.uk in your professional design life?” question, and an inspiring another respond to my last “Which one you prefer: Being the hands-on designer or the one who manages the designers?” question:
“I like making good design happen and I believe if you want to do that at scale you have to lead a team of designers. So I think the question answers itself. If you only ever do hands-on work you are limiting yourself and the impact your work can have.”
After listening to what Ben has achieved in the field of information architecture, I think that defining him as the “last information architecture master” can be a small but memorable indicator of my respect for his craft.
Do you know how many results you get when you search “UX” on Google? (In private/incognito mode) 234 million results appear. In the UX world, where there is so much content; it is normal to have mistakes and accidents. However, some of these accidents, if not careful and no action is taken, could increase the risk of casualties among team members. Let’s take a look at one of the most common areas of “accident” and answer one of the most fatal questions: Should we write Use Cases or User Stories in the UX documentation? (If you say both, don’t read the rest of the article at all; take a short walk, come back and give it another try.)
Since the “Agile” hurricane struck Turkey, the debate over writing Use Case and User Story has been flaring up among the enthusiasts. If the main concern of the Agile methodology could be interpreted as “Taking the simplest and the most effective steps first and delaying the rest of the concerns until the product creation phase” writing both the Use Case and the User Story in a UX project, creates an antithesis to this statement.
You ask why? Let’s answer why by examining in detail the key differences, the risks, and the approaches that emerge when using Use Case and User Story.
Use Case
Use Case is the name given to an end-to-end interaction sequence that takes place between an actor and the system, creating a value observable by the actor.
So you may be thinking “This is a wonderful definition, however, isn’t it like a quantum physics term definition? It says so much but means so little” then you are not alone. When you place the above definition and the stick figures together (just type Use Case on Google and you will know what I mean); then you would most likely end up with an unwanted documentation format which will never be used again.
I think it would be more practical to continue with an example:
The actor does something. The system does something else. The actor does something other than that. The system does something totally different. For those who say “Please, show me visually.” The following example for Use Case diagram is for you.
Here are a bunch of interactions. So, is this it? Is this the Use Case? No.
Finally, for these series of interactions to form an end-to-end flow (the main flow), we need “alternative flows” for the exceptional circumstances and alternative steps.
For someone else, such as a designer or a developer, to work efficiently after examining the User Case; the main and alternative flows about the activities framed by the User Case must be thought thoroughly. This thinking practice also requires you to have a good command of the rules that determine how the actor interacts with the system in the Use Case, which rights those rules give to the actor in exceptional circumstances, and how they direct the actor.
In other words, the BDUF – Big Design Up Front, which is opposed by Agile from the beginning, becomes mandatory. Rightfully, for the Use Case production “Let me think of everything, plan, detail and then start production.” becomes inevitable.
Weren’t we supposed to be Agile?
User Story
The key to writing a User Story is avoiding details in the beginning stages of the project; creating a working environment where details can be added to the project in a timely manner and as needed.
Unlike Use Case, User Story samples are created with much simpler reasoning:
As a <user>, I can <indicate folders not to backup> so that <my backup drive isn’t filled up with things I don’t need to be saved>.
In fact, as the key approach summarizes, the User Stories were born as a reaction to extreme elaboration. This is exactly why they are called anti-BDUF. When Kent Beck came up with the concept of eXtreme Programming (XP), he positioned the User Story as a point of support for this iterative and progressive production approach and pointed to the true Agile methodology.
Mike Cohn took the issue another step, wrote a book called “User Story Applied” and created a remarkably rich bibliography on the use of User Story in Agile projects.
Next, Jeff Patton introduced the Story Mapping technique to keep User Stories from drowning in the functional depth of a product. This effort became a method of positioning a User Story, which may be seen as very simple, in relation to the bigger story and showing how we can connect it to other (simple!) User Stories.
I would also like to share the following graph summarizing the position of User Story in Agile:
As can be seen from the examples, there are three prominent concepts in the User Story creation process:
We answer the question: What type of user are we writing this story about? We identify the activity, seen as a need in the story. We clearly demonstrate the user benefit that emerges as a result of this story so that we can review it in our prioritization work.
The position of the User Story within the value chain, in the axis of the business objectives of the product; depends on the clear manifestation of these 3 steps.
Although I would like to continue with the “Acceptance Criteria” that defines the acceptance status of the User Stories, Epics which is the next level above User Stories, and the “3C”s of Mike Cohn’s User Stories: Card, Conversation and Confirmation; I put an end to the User Story explanation and recommend you to have a look at the reading list at the end of my article.
The main difference between Use Case and User Story
The key difference between these two concepts is timing. The product design environment can constantly change because of business objectives, product characteristics and the constraints of project time limits. If you are trying to develop a product in that environment at a time when response time is a sought after capability, you have two options. Trying to think of all details, making analysis from the start and then deciding if you will design or not, places User Story and Use Case on two opposite ends.
Use Case is the choice of “I define every detail from the start” people, and User Story on the other hand is the choice of “I only define the essential details needed at any given point” people.
User Story people tend to think that they can whenever necessary further elaborate the User Story and create other User stories associated with it, and acknowledges that even this User Story may become unnecessary in the future, and they may have no objections to remove it. Use Case people think differently. Essentially they because of their fear to deviate from the detailed analysis, tend to clash with change.
Can I use the Use Case instead of User Story in an Agile Project?
In theory, there is nothing against it. However, choosing Use Case in an Agile project forces the resolution of a gigantic dilemma which is the imposition of “monolithic” and “absolute acceptance/rejection” philosophy. There are two factors that build a barrier between fragmented and iterative creation. The first one is that in the Use Case Creation, both cause/benefit definition is usually ignored and secondly, the lack of necessary relationship to be established between the business objectives and the Use Case. The effort spent trying to solve many small issues from the start will produce some results. However the loyalty to such results during the production period will put a barrier to the effective use of time and neglect “recent developments” that could provide added value.
Which one to use?
I am a part of the generation whose projects do not continue as they were planned/agreed upon.
I’m a veteran who admires the Japanese way of working. When my plans completely fall apart in the middle of a project, instead of whining about it, I happily take full responsibility to do my best to solve the issues. Most likely “the man who died while keeping the project going” will be engraved on my tombstone.
If you’re trying to do business in a market where discipline is of utter most importance similar to a football player on the German national team, and if your sole capital is time; I suggest you choose User Story and the iterative approaches that come with it.
“I like the subject. You said there was a reading list?”
If you are interested in the topic, you can start reading the following in order:
Due to the rapid increase in mobile internet traffic, recently one of the most frequently asked questions from project owners is if their website would be responsive. This is not a bad question; however, the question is incomplete, and also our responses are quite technical. At this point, we at SHERPA want to provide a solution without drowning everyone in terminology.
Go ahead. Read it, enjoy it, and even share your objections, but please do not ask if it should be responsive or adaptive.
As if he had heard us, Nick Davison, vice president of technology at Rhythm Agency, suggested a solution for this dilemma. (Yes, it’s possible to find an answer to almost every question on the internet.) The project Liquidapsive is just like the final answer to the discussion with four simple examples.
Let’s examine them one by one:
If you’d like a responsive website
Enter the liquidapsive.com and pick “responsive” from the drop-down on the top of the page. The user interface of the website will convert to responsive. Let’s continue for those who might be wondering what changed.
Responsive user interfaces have different layouts for different resolutions. As you drag your browser window narrower and wider, taller and shorter, you will understand how the interface responds to the changes in size. You can see that the transitions between different layouts are softer and fluid (liquid) during the change. The content and media elements within your page layout begin to vary depending on your browser’s display area. If you ask how it happened or are displeased by content not being as fluid as you would like, I can recommend a series of articles, however, be warned that if you are not a developer, they might give you a headache. In Hollywood-made horror films, remember what happens to the teenager who asks where that sound came from and still goes down to the basement all alone. Believe me, It’s better to trust the experts to design your product or service’s user experience.
If you’d like an adaptive website
Enter the liquidapsive.com and pick “adaptive” from the drop-down on the top of the page. The user interface of the website will become responsive. Let’s continue for those saying “So, what happened?”:
Adaptive user interfaces have different layouts for different resolutions. If you drag your browser window narrower and wider, taller and shorter, the page layout does not change. However, if the viewport reaches a resolution predefined by the development team, then the page layout adapts itself to the new resolution.
If you noticed, there are white columns on the right and left blocks of the screenshot above. It is because the viewport displayed on my browser is 1.440 pixels, and the upper limit for the adaptive option of liquidapsive.com is 1.366 pixels in width. In other words, the website does not adapt itself to viewports over 1.366. It is a decision which is made within the user experience design process. If your users prefer displaying your website on giant screens as much as next-generation TVs’, it would be a good idea to review your decision about 1.366 pixels for the upper limit and to consider adaptive solutions for wider resolutions such as 1.600, 1.920 and 2.500 pixels, and more.
If you’d like a fluid/liquid website getting into every form
Let’s first ask what the timing of the project is. Your answer to this question will set in motion a series of questions and answers from which there will be no turning back. Let’s assume that your answer is “Let’s first find out what is happening, then let’s see the budget, and timing is not an issue.” Enter the liquidapsive.com and pick “liquid” from the drop-down on the top of the page. The user interface of the website you are on is fluid/liquid now. So what? It’s actually almost the same as the responsive UI.
This is where our famous debate mentioned in the title (and also ego wars) begin. The comparison of responsive to fluid/liquid is not valid. Responsive is a type of development that performs responsive page layout decisions based on display areas. On the other hand, liquid is just one of the responsive page layout methods. And yes, an adaptive page layout can also be liquid. Therefore, the question if the best one is adaptive, responsive, or liquid is a futile discussion.
Content and media elements vary depending on the display areas of your browser when the page is designed as a liquid. If you try to display your website with resolutions other than the defined page layouts (that is smaller or larger than the defined metrics), you may see the page layout scattered. Here you can see an example of what happens when you display a page prepared as liquid, in 628 px as an undefined page layout. This interface is a dead-end of a project providing a user experience that ignores the widths below 1.024 px.
We know exactly what we want: Make it static
Then let’s ask: why static? Enter the liquidapsive.com and pick “static” from the drop-down on the top of the page. The user interface of the website you are on becomes static. Let’s keep for those who say “Is this all? Is it done?”:
The static page layouts, as can be seen from the name of the preference, are static, so they do not vary according to the condition. Whatever your screen resolution, they’re always static. Whether it is wanna-be-smart phones, laptops, tablets, it does not matter on which device you display your website, you always see the same page layout. Of course with a small difference: you see some different kinds of scroll bars to view the content outside the viewport. Here you can see an example and then decide how many times you have to scroll the bar to see the whole content.
If you read this blog post, I first want to thank you. From now on, you are one of us. Unless the speed of the development of mobile internet quite slows down, I am worried that this debate will be exacerbated and I considered to write this blog post as public debt. If you have any questions, please comment below.
Finally, I would like to emphasize that I avoid providing technical details in the article as I was trying to explain the matter in an understandable language. The necessity of the language of expression that I used to describe the issue plainly. My sole purpose in writing this article was not to make it easier for you to decide whether your site should be adaptive or responsive, but to help you get information first and so idea when conducting a discussion on the user experience.
But not finished yet…
Frequently asked questions
1. In the 2nd paragraph of your article, I got bored, and I jumped to the last section, and I did not understand anything. Well now, we have a mobile website. We would like to turn it into responsive. What do we need to do?
First of all, I assume that your mobile website runs on a subdomain such as m.yourfabulousdomain.com. If this is the case, I feel bad for saying this, but I cannot hide the truth. Google does not like you. If you wonder why that is the case, I recommend you check out this article. In case you don’t read the article, here is the summary: Google does not like URL redirection. If you would like to learn more, you can contact us via this form to get an SEO 101 education pack.
2. Do I have to know all this mumbo-jumbo? What does my agency do?
If your agency is free to make the user experience decisions which can affect the KPIs of your web assets, you don’t need to know all about this. If you’re not satisfied with your agency, we say “Oh! Look at the delegation discipline!” and we would be delighted to meet you. In other words, if you are the one who makes the user experience decisions of your web assets, you must know about it to answer the questions of your agency or other service providers. If not, you sometimes are tricked, generally, have wrong feelings and mostly make a false budget allocation, and you become pretty exasperated when you’re writing your year-end reports.
3. Nice. I got the point. But I am not sure about which resolutions should be responded by our website?
If you use any tool such as Google Analytics to measure the performance of your web assets, you can find out all the answers there. Analysis of these answers, more precisely the interpretation, will require technical knowledge. If your agency cannot support you in this case, you can contact us via this form to get a Web Analytics 101 education pack.
