A note on methodology: typically in experimental surveys you don’t want to prime your subjects with words or phrasing that could lead to positive or negative bias.
Additionally, negatively-biased phrasing on a public survey could also attract mostly those with negative views. This would skew your sample even further than solely priming.
With that said, I have no idea what any of those icons are.
I'd agree with you if the point of the survey was to collect information, but I think the structure of the survey makes it pretty clear that this isn't the intent.
Just from my own experience, I have used the overwhelming majority of these services and even worked at Amazon for several years and I could not answer more than a couple of those questions. The icons are so divorced from any real world meaning that when I make systems diagrams in Lucid Charts I use the AWS icons to represent abstract systems rather than the real AWS-specific meaning.
I am not a AWS user but I am familiar with what several of the AWS services do. I looked over the quiz and I could not answer even a single question.
I also think the quiz is to prove a point. Those icons are not helpful at all. The opposite of the MS Office icons which are so recognizable all other office suites copied the color scheme.
I'm an AWS user, I've been using their service for almost 5 years now. I also had a hard time with many of their questions. I agree completely with your assessment.
I was happy that they finally added a simple search tool for their tools on their homepage.
It wouldn't be a very sustainable business, but you could make good money selling a chrome extension that cleans up AWS similar to what Reddit Enhancement Suite does.
That might just be the most dangerous extension ever, or at least one that could get very messy very quickly if it was hacked. Or someone would be willing to pay big money to have it subverted, looking at you cryptonuts.
It's still priming the responses. If the interest is in drawing a truly 'scientific' result, the hypothesis/wanted-conclusion shouldn't be in the prompt used on participants.
Sure - either way it's not a "fair" survey. If I were making this survey trying to be scientific and somebody posted it to HN with this title I would be quite upset at them for priming a large number of my participants.
Also, presenting options such as "dried arterial blood red" and "slightly but not too radioactive green" might also make you less likely to put in effort to select the real one, rather than just picking randomly.
At first I agreed with you but taking the quiz I admit the title didn't really influence how I already felt about AWS icons. At least I remember AWS' service names like Firehose and Kinesis; GCP's are hard to remember when they don't use mnemonic devices for most of their products.
Aws feels like it was built by a bunch of siloed teams. There's a lot of design inconsistency I notice every time I'm in the console. For example, deleting entities is never consistent. Some just do it, some ask you to type in the name, some as you to type "delete me".
Some entities have a name and a description field that are immutable on creation, even though they also have a unique id. I now have drop downs everywhere that list "Rds creation wizard VPC" or something long those lines.
Its not clear what fields are drop downs so I have to type stuff into them to see if they'll give me a list of options.
The UI uses the same styles but inconsistent language. In ECS there's a list of entities. To delete an entity you have to go into it and delete all its children. Then the entity disappears.
I know there's engineering reasons for all this, but I feel like they can do better than settle for engineer grade UI.
AWS was built by a bunch of siloed teams. In the mid 2000's there was a mandate for each separate infrastructure team to open their infrastructure as a service, and they were given tight deadlines. This was meant to solve internal issues but was opened up to the world and AWS was born.
Yes, there was a mandate for everything to be SOA. However, AWS built almost every service from scratch. For example, S3 and EC2 were NOT used for production in Amazon until well after launch (it was a huge migration when the company did it years later).
My team built a world class transcoding service for video and were surprised to find later that AWS had built it's own (much less good) transcoding service. As part of that we also built a 5-10x optimization to multi-part fully-encrypted S3 uploads with a user-friendly client and the response from the S3 team was a shrug, they just weren't interested.
It is actually really common at Amazon for five teams to be building almost the same thing. Some of it is on purpose as a sort of insurance policy or bake-off.
But almost every AWS service was built in the AWS org, even if there was something similar in place at Amazon, at least when I was there (2006-2015).
> Yes, there was a mandate for everything to be SOA. However, AWS built almost every service from scratch.
I think it's more true than false though; tldr: there was effectively a super-fugly internal set of services that were the prototype for many of the real AWS services.
Some of the computing capacity AWS itself used was built on the internal services that Amazon had been using. Provisioning capacity on those internal services required weeks as the API was very primitive compared to EC2. I think also it wasn't until VPC became quite stable that they could start to move Amazon to AWS.
So for a long time, you essentially had AWS service teams having to file paperwork for capacity (decommissioning capacity could sit in a queue for months just like in a regular data center) while AWS customers could spin up capacity via EC2. As you can imagine, AWS would build on AWS, and then they promptly ran into problems when they had to stand up new regions because they had dependency cycles... There was also a ton of tooling built around requesting all the capacity and dependencies, and maintaining the configuration for all that.
So the SOA story is really that there were a bunch of AWS-like services that were absolutely awful, and those were often the prototypes for the AWS services themselves. And many services like Lambda are now possible because they've been solving all the obscure security issues and dependency problems associated with having AWS be their own customer.
For instance, the genesis of one service was that a large customer was using EC2 and had some specialized hardware; they were big enough they said, "hey, we'd like to move this hardware out of our datacenters" and AWS stood up an incredibly primitive service that literally routed some specialized racks into this customer's VPCs. There was no API, you'd email the service team and they'd run some scripts. That's gradually morphed into a real service that's unrecognizable from the early days.
This is true. Each team owns their service end-to-end. It just happens that the console is usually an afterthought. Something to be left for the interns to work on.
The funny thing is, some of the AWS services are indeed quite primitive compared to their Amazon internal equivalent.
Hah. Guess it depends on what siloed means. With a certain size you need to figure out ways of aligning/comunnicating things - whole AWS is probably thousands of people. You will get siloes.
On top of that: it’s not like all services were build at the same time. Some of them are the “bedrock” of Aws (S3, EC2), some of them are experiments that went viral.
On top of that: Aws is meant to give you building blocks. The magic happens at API/sdk level. The console is there to help you discover and play with the service in a few basic scenarios (and to maybe observer your resources). If you click your way through settings things up you’re going to probably have a bad time.
Yes, Cloudformation is my main tool too. I just simplified my comment. Read it as managed by code, be it CF, python, awscli from shell, and all of it in the end boils down to specific API calls.
For instance we have a process that sends sns messages for alerts. It’s just as easy to go into the console and subscribe to the sns event notifications (emails and sms).
Second example. I initially configure passwords with CF (of course with parameters that are added when you run it.) It’s easier to go into the console afterwards to change passwords as it would be to update the stack and renter the passwords.
You aren’t going to store passwords in source control anyway.
For SNS I'd use the API just to make sure every new team member gets signed up for every appropriate deployment (test, prod, whatever) and every old team member gets removed.
I agree it doesn't add much value for a single user rotating their own password.
The console is absolutely indispensable. You need it for your majority of aws users who are doing it for the first or second time. You need it for quick lookups, prototyping, experimentation.
Then when you have the Lego design you want, yes, you whip out cloudformation or bash scripts or Python scripts or ansible or whatever else.
I was astonished to learn that you can sort of scrape your from-console resources into a CloudFormation template, but you cannot get a stack to manage them inplace. Instead you have to blow them away (manually!) and have CloudFormation create a new stack from scratch, because it only touches stuff it created with hidden stack tags.
Terraform import is pretty painful but at least it can handle this.
Not every service has an API, especially new ones. They tend to launch things console first. Look at Alexa. It took over a year to get API, and it still doesn't have CloudFormation support.
I've been to two AWS Summits (Stockholm) and most if not all AWS employees explicitly point out that you should never use the console for anything serious. It might be good for presentations, but it's horrible when you need to manage infrastructure.
That's not accurate. There are some things you cannot even do in the API and it must be done in the console. I agree with others here that you should be using Cloudformation as much as possible, but even that isn't 100% supported and sometimes you need to click around the console to set things up.
I feel like AWS’s MO is to eschew things like usability and consistency in favor of getting features out as quickly as possible. Perhaps it doesn’t have to be an either/or, but as an observer from outside the org, it’s hard to know
You can still have siloed teams, and I think you need them in this case. AWS has many different products and they don't all relate to each other. It sounds like they simply need to adopt some UX/style guides and enforce them across the company.
Names and Icons on AWS were made by people who don’t realize who helpful names and icons can be.
If it’s a database, use the cylinder icon that everyone knows is a database and then add some identifier to show which database it is.
If it’s DNS, don’t be too clever and name it Route 53. Name it Amazon Cloud DNS. Then anyone knows how to look for it in the console, web search for it, etc.
If you want something that the marketing folks can feel proud about wasting time on, add the silly name to the descriptive name: Amazon DNS Potato
> If it’s DNS, don’t be too clever and name it Route 53. Name it Amazon Cloud DNS. Then anyone knows how to look for it in the console, web search for it, etc.
Please no. The unique AWS product names while occasionally inconvenient mean that you can at least find relevant information about them when searching, and you know that someone isn't confusing an AWS product with another platform or another style of deployment.
If you really don't like the AWS product names, then Azure is for you. Now go try to search for help with "Azure web apps" or "Azure sql database". Wade through the posts about locally deployed IIS, SQL server and the like.
And why "Amazon" EC2 but "AWS" Lambda? It throws me off every time I look at an alphabetically sorted list of the services. Granted, Microsoft slaps "Azure" in front of some of their services, but Amazon seems to optimise for having "AWS" and "Amazon" mentioned together as many times as possible, as if we need to be reminded.
`Amazon` named services are core building blocks (e.g. ec2 is just servers). `AWS` are services built on top of the `Amazon` services (e.g. Lambda runs on their EC2 machines, Batch runs on EC2 machines). usually
I don't believe that's the reasoning; and although I worked at AWS in the past I don't know for sure what's the reasoning behind choosing "Amazon" or "AWS" prefix for a service name.
For example, RDS is definitely a service built on top of other core services (EC2, S3, KMS, Route 53), its name is "Amazon RDS" and not "AWS RDS".
Glacier and Snowball were both the internal code names for the products pre-launch, and only ever intended to be such.
When things came close to launch, AWS Marketing decided to just roll with those code names. I've a suspicion that some teams deliberately used copyrighted names for their internal pre-launch project names, just to force the matter.
I've probably spent at least 3 hours collectively trying to find the DNS only to find/remember it is called Route 53. I rarely use it outside of initial setup and trying to recall the name of it each time is maddening.
But then they would have to take the marketing questions out of their associate level certification exams.
1. Which service would you use for DNS record creation?
A) Route 53
b) Amazon Cloud DNS
I joke, its an extremely low quality question regardless of the name. Some of the questions on the exam were pretty insightful, especially the ones that covered problems and what steps you would take to resolve them. Overall, the AWS associate level certification did feel like a giant marketing ploy, but my company wanted me to have it and paid for me to study and take it, so it was a nice relaxing break from the day-to-day.
In general, I would not expect questions around expect people to remember details about a logo just from a name to work very well. People in general can't do that even with extremely famous logos: https://www.signs.com/branded-in-memory/ Nor can they generally even draw a bike, with physical necessity available to guide them: http://www.gianlucagimini.it/prototypes/velocipedia.html
However, it is absolutely a reasonable request of a logo that you be able to go from logo to designated product, and while quizzing about details like "which horizontal pole is higher" is definitely a bit of an ask, you should still see a lot of people getting that right from just "feeling" which seems right.
I agree with both parts of this. My biggest frustration is that even after I looked at the answers, I couldn't explain many of the logos.
There's a clear attempt to create logical connections: 'directory' manages to evoke a bunch of cards in a file, EMR is a solid reduce block above a bunch of map blocks, and so on. The MediaFoo family is actually quite good - I swapped Package and Store, but otherwise got them all right despite never using the service. The family color scheming is genuinely very good, despite the weird outliers like grey.
But then there's all the rest. Kinesis and Cloudwatch are each a bar graph with a base, but Kinesis is rotated, and has 2 layers of floating base instead of 1 joined layer, so that totally clears things up. (And Athena is 1 layer floating base, with bars going both directions, to help confuse the existing two.)
ELBs and ECS are both multiple full-size layers on the left with a 4-rectangle split layer on the right, but ELB is 3 filled layers and a flat split layer. ECS is hollow layers and a 'long' split layer. Memorable!
Database Migration Service is a mix of Direct Connect and RDS theming, which actually makes sense, but also Elasticache is a disjoint version of Direct Connect in database coloring?
(I had a hell of a time looking these up to check, because about half the guides on Google Images are simply wrong about some services. Check out Elastic IP, which is listed with the icons of 3 other services!)
AWS do put a lot of work into their icons set. That said, we (draw.io) get a lot of direct complains about the icons because:
1) They can't find certain AWS icons (the problem is it's there, they didn't expect it to look like that).
2) They change and move between sets rather a lot. That was more a problem previously, the set hasn't actually changed yet this year.
If there's a designer out there willing to create an alternative set, we're more than willing to add it in and see what people prefer. Probably more constructive than just saying "they are bad", show us something better.
I work with AWS every day, and I just realized that even though all the symbols have a consistent look, the style is so generic I don't mentally associate it with AWS. To me it looks like symbols from a design diagram where somebody was in a hurry and picked random symbols from their drawing program's image library.
I don't think they have a 'bad icon' problem as much as a 'too many services' problem. I'm not necessarily saying that they need less functionality, just that they need to divide it up into fewer named/iconed chunks of functionality.
Jetbrains products' icons are OK, but there's clearly a gradual Adobification going on.
Their designers recently declared that colored icons were distracting (?) and are currently moving most of the them to gray. Quite confusing when gray usually means disabled.
Very entertaining and bludgeons you over the head with the point of the survey. I got 6/20 and several correct answers were lucky guesses. I only really recognized EC2, Lambda, and VPC. That doesn't mean the icons actually convey what those are to me though - it's just memory since I use them often.
I'm not sure where one goes in the AWS web interface to view these icons. Poking around the EC2 menus for a while, I don't see an icon anywhere.
I wouldn't say the icons are _good_, but I wonder if part of the reason the quiz is so hard is that Amazon doesn't really care if you know what the icons mean anyway. Seems like they're mostly used for branding and marketing, not anything users will see regularly.
If you click the pushpin icon in the web interface, you'll get a dropdown with the services and their icons. You can drag icons into your top bar as shortcuts.
To me, the icons are far too abstract to mean anything. They all look like the results of someone playing around randomly in a 3D modeling tool. For example, look at the CloudFront icon. I'd expect something more evocative of clouds or similar, but it's just a cube that's been cut and exploded with the rear two subcubes removed.
That said, they're probably extremely easy to generate procedurally:
There's a famous story about early UI fail in some CAD software.
Icons had just come into vogue (yes, there was a time before icons). The CAD system in question used a puck on a big mat to choose functions from a grid of names, which were labels like GRAPH and CONNECT and DEL and so forth. But all-caps names weren't very sexy, so the company decided to replace them with more intuitive icons, cool little pictures of the operations. Getting rid of the tiresome and uncool simple text labels was going to win back market share!
Predictably, users complained that they had a hell of a time trying to figure out which of the tiny, intuitive pictures corresponded to the concrete operations.
The company's response? Supply users with a printed cheat sheet that let them find the icon for each operation. To do a CONNECT, you'd look at the cheat sheet and find the corresponding essentially arbitrary (but intuitive!) squiggle, then search for the intuitive squiggle in a sea of other intuitive squiggles. ("No, not that one!")
I use AWS every day and got 17/20. Thanks to a couple of lucky guesses.
But, I believe that at least two of the questions have incorrect/incomplete answers:
One of the questions that requires a typed answer (instead of multiple choice) shows an icon that is used for both EC2 & Appstream. However, only EC2 is considered correct.
In the Route53 icon question - there are multiple versions of the Route53 icon used in different places (do a google image search and you'll see a dozen variant). The icon in the top left ("Pole with two offset rectangles") is used in the console - but this is considered an incorrect answer. The icon in the top right ("Pole with two slightly less offset rectangles") is sometimes used elsewhere and is the only answer considered correct.
Icons are the least of AWS's UX problems. The AWS console is godawful. It should be a case study in terrible design. I hate every second I spend on it.
Route 53 looks like it was designed by the Marquis de Sade. Not only was it designed by a sadist, it looks like it was designed last century.
They’d be better off putting up a text file because then at least the IT guys would already know how to use it. And making changes would be a hell of a lot faster too.
I think the icons actually are cool and futuristic but there are so many of them an average person cannot realistically keep track of them all. I can only assume they're for marketing purposes to show in slide decks or websites.
I also wonder if they painted themselves into a corner early on by having them for their early services. I guess they're a big-boy company and have stopped doing this earlier but who knows.
7/20, and my correct/failed guesses seem uncorrelated with services I've used or ones I never touched. Anecdotal evidence about how arbitrary these icons are.
17/20 But I'm in AWS all day every day. I also question a one or two that I missed :)
People suggesting that they follow Adobe's lead. That's all well and good, until you release like 1000 products a year. You tend to run out of two letter combos for your icons.
Since there seems to be a lot of negative sentiment here about the icons, I'd like to offer a different perspective.
While using AWS services and leading huge migration projects, I've never thought to myself: "These icons are terrible and slowing down my progress". As in to say, sure the UX icons are a little wonky, but at the end of the day, do are they really impacting people from getting the value out of the services and using them quickly? Maybe Amazon is partaking in what is often sentiment around here: not optimizing things too soon.
Summary: while icons might be confusing and not great, I find zero impact in me architecting systems and communicating designs.
In most cases, the icons are more closely related to the service than the names are, even if they are pretty abstract. Aurora? Fargate? Kinesis? Snowmobile? Sumerian? Obelisk? Gravelbean?
(Ok, I made the last two up, but I bet you would've had to look ...)
I do not think it is plausible that, for most complex abstract things, there must be an icon that intuitively represents it. The most you can hope for is that the icons are sufficiently distinctive and memorable that a frequent user would come to recognize them without confusing one for another.
I am more bothered by names that do not give you any clue as to what they are about, though there is also a limit to the amount of information you can put in a name.
The author of the survey should have allowed "don't know" as an answer. I didn't finish the survey because I didn't want to choose responses I knew probably weren't the right ones. If there are others like me who refrained for this reason, this will skew the results.
(The main point of the survey came across very well, though.)
I have SSO with Okta. It's literally a browser plugin and I select which account to enter, and I'm in. You should definitely look into setting up something like that. It takes away all the pain of logging in.
Yup. 4/20 made me realize how much I use the new type-ahead feature on the dashboard. Not sure it's even worth using icons with so many services being offered.
This is only tangentially related but it seems that many of the shapes are built in some sort of 3d program and then exported to svg. If you inspect the official released svgs you can see tons of artifacts in most of the shapes[1]. You would think that Amazon would have the resources to release very optimized icons for its public facing documentation.
This reminds me of those children's puzzles on diner mats to "spot the difference". You either see it immediately or stare at it for 5-minutes with no results.
I just started using AWS a few months ago, professionally, had a couple hobby projects before that.
I don't think I could answer any of those questions. I actually gave up because it started to feel ridiculous, like I was just looking at random geometric shapes.
But my point is that I still use AWS and I find what I need without ever having seen those icons or remembered them. The console remembers my most used tools so usually I find them in that shortcut menu.
I mean, is there anywhere in the console where you select/identify a service by its icon alone, without the name next to it? I don't remember any such place.
If not... who cares? They're not branded consumer products that need recognition, just a bunch of services and it's not like I'd have any even remotely good ideas for most of these jargony things anyways... :P
You can configure the top bar in the AWS console to show icons only, but that would be madness. (I usually do the opposite and have it show no icons and only text.)
Amazon, like many enterprise tech companies treat UX designers as second-rate citizens. One of the best UX designer I know left Amazon to work at a startup because he was tired of Amazon's policy of assigning UX designers to work under engineering managers.
I've always had issues telling the icons apart, but in fairness the recent UI updates have already been phasing out the icons. They're no longer on the management console home page, and they've been replaced with much improved category icons.
I use the AWS console all day every day, and I couldn't name a single icon. So my guess is they are just intended to be art icons, nothing purposeful. Or they're too similar to be mnemonic.
I won't bother taking the survey, I only use a couple of services (EC2, RDS, SES, S3, Cloudfront) and I have no idea what the icons are for any of those services, even if I login on AWS daily.
This is so on point. I can't recognize more than 1 or 2 AWS things by icon. I've always wondered if I was the only one who found it kind of impossible to tell what's what in AWS.
Amazon would never care about this stuff unless someone independently did enough unpaid work on the project proving it they could determine an economic value to changing it... so congrats?
I agree with you about that in a smaller bunch you do recognize the target icon relatively quickly, but they could have just used the color for the text itself :)
Off-topic (and sort of translated):
Salut Virgile, complet de acord cu tine, dar dacă făceau textul colorat în culoarea "service category", viața era mai simplă pentru toată lumea :) (lume mică, domne, uite de cine dai pe net :D)
Lots of vividly-colored text is hard to read and makes a pretty bad interface, too. Also, apparently the whole quiz is kinda' moot - here's how my console looks now: https://imgur.com/n9Ohtri (apparently they moved to "one icon per service category").
Ref offtopic: nu e cinstit, eu sunt usor de recunoscut dupa ID (plus am mailu' in profil). Nu stiu cine esti :)
That's the route JetBrains went as well and while I wasn't happy with it when they initially started doing it, I have grown to greatly appreciate knowing which icon represents which product at a quick glance.
Adobe made a really gutsy move IMO. Some of their products had very memorable icons, which they chose to ditch in favor of the fully unified look. Ultimately I think it was a good one - Amazon’s current struggle to properly iconify their dozens of abstract services illustrates this perfectly.
I actually would be curious now to see how a company like Apple might approach the problem. Apple’s well-known icons are largely focused on popular apps, which have very distinct and concrete functions. I wonder if there really is a clear and unambiguous icon for something esoteric like a NoSQL database store - I suspect that there isn’t, largely because (unlike apps) it just isn’t something that is in the public eye.
Works fine, but it does make it harder to pick an icon at a glance since you need to spend those 200ms thinking about what the abbreviation means or what abbreviation you're looking for.
It has terrible naming too: a lot of services are acronyms, it makes them difficult to understand for outsiders. Microsoft who is traditionally bad at naming too is surprisingly good at it for its Azure services. App Services, DocumentDB (CosmosDB now), DataLake, ... are more easily remembered than cryptic 3 letters acronyms.
>It has terrible naming too: a lot of services are acronyms, it makes them difficult to understand for outsiders.
I almost think this was a deliberate choice. Makes the services sound more important than what they are. At any rate, many engineers I know love to smugly use this acronym soup.
Additionally, negatively-biased phrasing on a public survey could also attract mostly those with negative views. This would skew your sample even further than solely priming.
With that said, I have no idea what any of those icons are.