Articles

Episerver invest for the future as they complete their Acquisition of my favorite A/B testing tool Optimizely. With this acquisition Episerver strengthen their platform offer, and they now claim that they have the industry's most advanced Digital Experience Platform.
Episerver have long been one of the big names in content management and digital experience and Optimizely have been fighting for the title of the king of A/B testing  against VWO for many years. This combination of forces makes sense as it will add value to both companies as they combine their customer bases.
Will this take Episerver closer to Adobe who sit comfortably at the top of the digital experience market, if for nothing else than revenue alone. I doubt it very much, but it should bring them closer if nothing else. Hopefully though we will see more people start experimenting as Optimizely becomes more accessible and integrated.
 
Transaction Details
Episerver is a privately held portfolio company of Insight Partners, purchased in 2018 at $1.16B. Insight Partners acted as the strategic advisor and sponsor for Episerver’s acquisition of Optimizely, as well as the company’s 2019 acquisitions of B2B commerce leader Insite Software and analytics and personalization provider Idio. Now with Optimizely, Insight Partners further advances Episerver’s market-leading product. In the same manner, Goldman Sachs & Co. LLC served as exclusive financial advisor to Optimizely.

Over the years I have seen many claims to what flavor of Agile is king. In this article we will look at Scrum and Kanban to see if we can determine which of these two flavors are the best for you and your team. I have a feeling you will be surprised at the answer, but I hope you will not be.
I recently read an article called "Scrum Is Dead. All Hail Kanban, the New King" where the author Emanuel Marques praise the Kanban flavor of Agile as his experience of Scrum have been less positive compared to Kanban. One of the responses to that article was written by Maarten Dalmijn, and he made some good points in his article on how flawed the initial article was.
To anyone who work with Scrum in multiple projects and multiple companies you probably recognize Emanuel's story. It is in no way a unique experience he has that Scrum, like many other Agile flavors, are misrepresented due to adjustments by the team or the company. Here are some examples from Emanuel's article:
A common thing that happens way too often. When you are inexperienced with Scrum, estimations and you do not set sprint goals, then this happens a lot. We see that the team is not working properly in the burndown chart as well.

This is a typical Agile burndown when using story points when you either have issues that are too big or you do not close issues properly. For a team working with story point, which I think is stupid in any case, a burndown chart is completely useless.
This is again inexperience in making proper estimations and because of that you did not have room for the unexpected. In all processes, methodologies and frameworks you need to be able to make proper work assessments. Agile make that easier by letting you make arbitrary measurements that are more like "guesstimates". If you fail doing that, then you are in real trouble regardless of what process methodology or framework you choose.
Emanuel's team choose to go to Kanban because of their inability to adjust their way of working away from the production line of thinking to an Agile way of thinking. What was it about Kanban that attracted them?
So out of all the things that Kanban offer, Emanuel's team choose to focus on these. As you can see all of these are about commitment and responsibility. If you combine this with the reasons Emanuel and his team felt the need to move from Scrum to Kanban you probably can see the same thing as I can and that is that this is a team that no one has taught how to work properly.
They have been left in a work environment where things are difficult to navigate and control and as a result they feel they are unable to commit to anything. I assume this is because failure, as diffuse as that definition might be, happens frequently. They also seem to be working with a poor scrum master, possibly also inexperienced or limited in his capabilities by the work environment.
Sadly I think Emanuel and his team will soon find out that Kanban with the focus on escaping accountability and control is a bad choice. Kanban is not going to make failures go away. In fact, it will probably make things worse as the stakeholders will find the Kanban way of working, especially the bare-bones version Emanuel and his team are describing, very annoying as they have little to no control in that flow.
What does this have to do with what flavor is king?
Well this has everything to do with what flavor is king. They all are. If you use them properly. Sadly many work places implement Agile in all its forms in the wrong way. They try to make Agile work in a project based organization with an ITIL based steering structure with multiple teams on the same products.
If you add inexperience and poor coaching resources, then you are setting up all flavors of Agile to fail. With that comes frustration and stress for the teams, and they will naturally try to distance themselves from management and any form of accountability as they are destined to fail regardless off their effort.
This is referred to as a MOD project by some of us that work with process and methodology design. MOD is short for "March of doom" meaning that the project or the team are already doomed before they start due to the restrictions already placed on them. It is also in reference to how managers often refer to them MODifying the Agile way of working, which often result in a poor experience.
If you work with Scrum, Kanban, DevOps or any other flavor of Agile, that can be king for you and your team. If you use it correctly and you actually take your findings in retrospective to adjust it to fit your way of working. You can even mix them to find the optimal workflow for your team, because they all come from the same source: Agile.
You have the power to make your flavor of Agile king
This might seem strange for anyone who work in workplaces where your way of working is dictated by management, but there is hope. In all organizations you have two ways of working: The Steering and the Operational. If you can find the way to meet the steering, so they can do their job, then what happens in your team should be up to you. If you are sharing responsibilities with more teams, then you should build your way of working together with the other teams. Never work in isolation if you share responsibilities.
In order to do that you need to figure out what steering need so you can provide that. Usually this is the holy trinity of time, money and quality. Time and money comes through time reporting and proper estimations. Quality comes from requirements and testing alongside prioritization. So no matter what flavor you choose you need the following:
A handover of translated need - you need to understand what the need is so you can take ownership. A Prioritization meeting - to decide what to do next. A common practice to make estimations - learn to make proper estimations instead of "guesstimations". Log time at least once per day if you have time estimates. Break down tasks as small as possible and close as soon as they are done if using story points. That is usually all you need, regardless of flavor.
So go out and make whatever flavor you prefer KING today.

Agile 2 is here. It has been in the works for a while and from what I can tell there has been some sharp and experienced minds involved in that work. It is in many ways a retrospective, but also a way to look at the great failure that is Agile. A failure that originates in the division of visions and the ideal becoming absolutes. Agile 2 hope to change that and it is a great ambition that have my wholehearted support.
In the case for Agile 2 the statement is that one of the issues with the original is that it lack the inclusion of leadership. I agree with that as well as to note that the developers do not always enjoy what is referred as Agile in many organizations. The fracture of the Agile community and then the stagnation into a fixed perception almost to the point of worship also resonate with me.
This is by far the most common experience for me when meeting with organizations. A will to move towards Agile, but a methodology that is fixed in its ways and lack the component of leadership and steering. I also find the interpretation of Agile to be heavily reduced when facing the opposition of reality, leading to an ad hoc situation that is damaging and frustrating to the people involved.
At first glance Agile 2 seem to be on the right track. I look forward to seeing where this will go and how it will challenge today's Agile community. Hopefully the Agile community will adopt their own methodology and embrace this new input to evolve their way of working.
I support the work of Agile 2 and I hope you do too.
 
Agile 2 – THE NEXT ITERATION OF AGILE
AGILE2.NET THE NEXT ITERATION OF AGILE  

As a consultant I see many work ads. Some are good, but a lot of them are almost to the point where I wonder if the people writing them know what they are asking for. It takes a while to write a work ad, so not only are you wasting your own time, but that of those who are looking for work as well. So here are my five best tips on how to write good work ads to get the right people for the job.
 
Describe the problem you need solved Don't add buzz words Have a person that knows the craft write the ad Be honest about your work process Don't ask for unicorns Set tiers internally and price accordingly  
1. Describe the problem you need solved
Most ads are just a big list of qualifications required, but very few actually describe what you need. Asking for certifications and extensive experience in a very specific field is a sure way to narrow the field of applicants. It does not however ensure that you can get the help you need. A certified scrum master or project manager can still be completely useless, while an uncertified person can be a miracle worker. Describing the problem also ensures that you can follow up and see if the person you hired actually could solve the problem you specified.
To some people this is very difficult, because it implies a problem and not everyone can admit that there is a problem to be solved. The thing is though that all work ads are requests for help due to a problem. It may be that you are understaffed, or that there is a competence missing. It can also be that you need help to organize or create work processes. No matter the need, just state what it is that you need help with and you will have a much better chance of getting the right person for the job.
2. Don't add buzz words
As a consultant I can easily read between the lines and when I see an ad stuffed with buzz words I know that this is a bad position. There are certain combinations like "Agile Mindset" with "dig in where needed" that I know means you have a chaotic workplace. Other combinations like "comfortable talking to steering groups" and "team player" means that you will be thrown under the bus frequently.
Anyone claiming that they work in an Agile way in a large scale company don't really know what Agile is and throwing in DevOps, SAFe, full stack x or made up words like "Scrum Manager" does not make it better. In act I often skip ads that are keyword stuffed with nonsense or where I can clearly see an underlying hint of a bad work environment.
Make sure you know what you are talking about and be up front with the situation you are in. Most of us experienced consultants have worked in very bad condition, and we make it work. I just want to know what I am stepping into rather than wasting my time and yours.
3. Have a person that knows the craft write the ad
I have seen ads that so clearly are written by people who have no idea what that role really will do. I understand that it is often managers or HR people that write the ads, but I suggest you let the people who know the trade write it instead. Not only will the ad suffer less from #1 and #2 above, but you can also define the actual work much better.
Having the person I will replace or work alongside write the ad will ensure I get the right information. This is because that person want the very best for the job so the ad will be aimed towards that. I will get the tools, disciplines, work processes and characteristics described properly and without nonsense.
4. Be honest about your work process
Everyone has crappy work processes. It is a fact and there is no need to pretend otherwise. Just be up front about just how bad your process is and most applicants will be fine with that. If the requirement process does not work or you have constant change in your iterations because no one can actually commit to anything, that is actually fine. Most of us work that way every day of the week, and we make it work.
If I know what I am getting myself into, then there is less chance that I will feel like you lied to me and I will stay longer. If you claim you work according to Scrum and it turns out you just have an ad hoc process with stand-ups, then I will probably not be very happy. This is often very difficult for managers and HR, which is why you should use tip #3.
Simply telling that you are trying to work in a more Agile way, but that you are struggling a bit due to the fact that your organization is still project based with a long tradition in ITSM is enough. Or that you are in a transformation phase so things are a bit shaky while you figure things out will do wonders.
5. Don't ask for unicorns
This is the biggest source of amusement for me and many other experienced consultants. Mixing roles as if you were doctor Frankenstein and then asking for 20+ years of experience for minimum wage. I have actually seen ads that ask for longer experience than the technique or tool has been around, which means they failed with tip #3.
When you define roles, then stick to one discipline and don't mix things. The more things you mix in, the less focus you will get in that area. If you combine opposing types, like "Scrum Manager" or "Developing Scrum Master", then you will not get both at 100%. One will be dominating at 80% or more.
An easy way to avoid this is to use the color coding on this page. Mark the requirements you have put in with a color and then see how many colors you get. If you have two colors, then you are splitting the work into two disciplines. Three or more, then you are asking for a unicorn. Secondly you should look at the roles and see how they match up.
A Scrum Manager for example have both Scrum Master and Manager in the same category, but they are opposing in work direction and empathy. Managers work upwards with focus on finance, while scrum masters work downwards with focus on people. Developing scrum masters have conflict in focus. Scrum Masters are extrovertly focused where content switching is natural, while developers are introvertly focused and content switching will hurt their work capacity.
Work is often hard enough as it is and people burn themselves out far too often when working in just one discipline. Combining them increase that risk a lot and if you care about the people you hire you should avoid putting them in that situation.
6. Set tiers internally and price accordingly
Finally, don't ask for unicorns or highly experienced people and offer peanuts. I rarely care about the financial side of things because I value other things and I love helping people, but if you ask for someone with special abilities or long experience, then understand that you get what you pay for. Asking for a lower price makes sense, but don't ask for a senior or someone with expert capabilities and offer them half or a third of what they normally cost.  You will just end up getting a junior with basic skills rather than an experienced unicorn...
I suggest you set tiers internally for all roles you have, or need. Grade then according to experience, competence, workload and then match them towards the value they provide. Make it into a five tier grade where tier 1 is the highest and tier 5 the lowest and every time you make a new ad, define what tier you are looking for. Not all ads are aimed towards tier 1 applicants, in fact I would say most are not. So just make sure you know what you are looking for and then price it accordingly.
 
Final thoughts
Writing ads are difficult, but the cost of getting the wrong person for the job can be far worse. You also scare away a lot of good applicants if your ad is considered bloated, dishonest or if you send out danger signs because of an unfortunate combination of keywords. Even if the ad is for a temporary position you want to make sure you get the right person, so put some effort into the ad. If it is for a permanent position, then it is very important that you put your soul into it.
I know a lot of people think that you will just put something together for the ad, and then we do the real recruitment during the interviews. The downside to that is that you may already have lost the unicorns or that perfect candidate with the ad.
So make it good.

Atomic UX Research. Sounds like something amazing, doesn't it? Something that will fit right into the modular design and development processes in Atomic Design. Unfortunately it is just a fancy name for having a proper documentation strategy for UX Research made up by UX Designers who work in poorly structured workplaces.
When I first read the article "Foundations of atomic research", I had no idea what the person was talking about. Was it a process, a content strategy or maybe even how to present the findings. I looked up the Atomic UX Research further and found the article "What is Atomic UX Research?" and it seemed like it was all about how to organize the documentation of the findings.
I watched the video (added blow) where Daniel Pidcock try to explain this new, revolutionary way to organize data, and I was both amazed and a bit disturbed over the fact that the audience actually seemed to agree with this nonsense. The reason I felt that way is that there is nothing in this new made up word that have anything to do with UX. It's just common sense on how to manage documentation. Any documentation.
Anyone working with research should know that you always connect current research with relevant research that it is related to. It is also standard practice for anyone working with research to add metadata to make the research findable in different situations. Anyone working in UX research, especially towards the web, should know that data get old very fast and loose relevance very fast.
That is not how you work with any form of documentation that is supposed to be alive. If you make UX research then that data is ever-changing as you continue to learn and experiment. This does not warrant a new way of working, you just need to start working the right way. Proper documentation is always a part of research, as is traceability so you can understand where the conclusions come from and how you used it to formulate new theories to be tested.

The Atomic UX Research suggests that you should divide the research into smaller bits and then tag each type with metadata. The idea is that by doing that you can discover other data that is related to your research. If you have hundreds of theories going at once in multiple teams, or you want to bring in similar research on other systems or services then maybe that would be useful.
Then again, if you have that many experiments going, then the volume of data would be immense and you would have no way of knowing what data would be relevant. You would spend a ton of time on matching old experiments that probably will be obsolete as the design have already been updated since it was conducted.

This is the image used to illustrate the four main parts of the Atomic UX Research. Note that the structure start with the Experiment. Now it may be implied, but an experiment should be tied to a theory. What are we trying to prove and why do we think this is worth exploring should be the starting point for all research. While I think this may be implied, for me this is where this theory fails.
By having the theory as the highest level, all experiments fall under that theory. All theories are built on previous learnings so while there is no problem having the information structure dividing the content beyond experiments I think that if you ensure you have your theories in order you would not see many insights related to multiple theories at the same time.
Even if you have an additional level of information for insights you would not have multiple conclusions. The conclusion would be tied to the theory we are working with based on the result of the experiments we run to test that theory. In the event that we make findings not related to the theory we are testing, this would be marked in the conclusions as separate theories to explore at a later date.
My take on the Atomic UX Research approach is that instead of inventing new names, you should start working with research properly. UX Research follow the same basic structure as every other research field. In order for any research to have the desired effect you need to formulate theories, conduct experiments to test that theory, analyze the result and finally take what you have learned and form new theories and of course activities to improve the service or product you are doing UX on.
The result is documented in a searchable tool with metadata and connection to previous theories that support the decision to make further testing of the current theory. You do not need a new methodology for it, just follow the standard research praxis that has worked for many, many years. Doing random exploratory testing is not research. It is exploratory testing/discovery.
Atomic UX Research = UX Research.
 
 

Last week IBM announced that the company would be moving some of its lower-margin lines of business into a new company and that IBM itself would focus on higher-margin cloud services. This comes after a long effort by IBM to diversify away from its legacy businesses.
IBM will list its IT infrastructure services unit, which provides technical support for 4,600 clients in 115 countries as a separate company with a new name by the end of 2021. The new company will have 90,000 employees and its leadership structure will be decided in a few months. This new company has no official name yet and is referred to as NewCo in IBM's marketing and investor relations material..
In a press release IBM state that they "will focus on its open hybrid cloud platform, which represents a $1 trillion market opportunity," while NewCo "will immediately be the world’s leading managed infrastructure services provider."
During an investor call, CEO Arvind Krishna, who replaced Ginni Rometty as CEO in April, acknowledged that the move was a "significant shift" in how IBM will work, but he positioned it as the latest in a decades-long series of strategic divestment. Krishna also said that IBM’s software and solutions portfolio would account for the majority of company revenue after the separation.
IBM, which currently has more than 352,000 workers, said it expects to record nearly $5 billion in expenses related to the separation and operational changes.
 

 

Ikea is making a bit of a splash recently with them announcing that they will not do the regular Black Friday sales and instead will buy back and resell products from their customers. This initiative called Buy Back Friday will happen in 27 of 31 markets globally between November 23rd to November 29th.
When the rest of the world get ready for the biggest marketing campaign of the year, Ikea chooses to focus on a little different approach. The Buy Back Friday will focus on sustainability and not only will it reduce the number of things that are thrown away, it will also allow people to get some furniture at a pretty low cost. The fact that you get store credit for the things you turn is also a great way to give people a bit extra before Christmas.
Personally I think this is a great example on how you can have great marketing while also making a good impact on the world. Ikea get two thumbs up from me.
 

Figma has been in the news for designers for a while and it is in many ways praised as the one tool that will save us all. I am still skeptical because to me Figma is a generalist tool, and I am used to working with specialist tools. I will go over the selling points that Figma have listed as to why people make the switch from Sketch to Figma.
On the Figma website they list 3 main selling points for making the switch: Less is more, Faster in the cloud and Better Teamwork. The collaboration aspect has been their biggest selling point so far as far as I am concerned, but let us go over them one by one and see how they appeal to certain groups.
I will look at these selling points from two points of view. The Isolated design team, which would be where most design studios and larger companies with dedicated design teams would fit. The included design team which is where the team is working alongside the requirements and development team members.
 
Less is more
I could not agree more. Having to juggle multiple tools at once is a bad experience for everyone. The design tool is just one tool and it must connect to the overall flow of the build phases. That means that the design should be connected to the code and the requirements. As far as I know there is no design tool that have that today, so we still need to have that as separate tools.
Abstract for release management
When it comes to both requirements and development, which are the two adjacent disciplines to design, then version management is very important. Abstract is by far the best tool right now for maintaining a controlled version management, which also can follow the same flow as the code. This allows for locking a design, while also continue working on it in a controlled way.
While Figma have a version history built in, it is just that. Version management of single assets with no connection outside the design flow. It is not what is needed for collaboration outside the design discipline, even if it is nice to see who did what when.
InVision for prototyping
I do not do a lot of prototyping and usually the built-in functions in Sketch works fine to illustrate a flow. If I need to do a full prototype I would either use InVision or Axure depending on the situation. Are the functions in Figma as advanced as InVision or Axure? I don't think so, but then again I have not seen any reason to dig into it too much. I doubt it is something that will make or break a decision for a designer.
Zeplin / Avocode for design handover
While design handovers are less common when working with proper pattern libraries, a lot of people still do not have that workflow in their organization. Having tools like Zeplin or Avocode to allow developers to match colors, fonts, margins and paddings becomes important in that case.
For the isolated design teams this is a lifesaver as it reduce the need to communicate with the build team. For the included teams it is simply an additional feature, like a nice-to-have. This is because the included teams will of course collaborate directly with the rest of the team, which makes static information less important.
Overall it is not bad that Figma have the basic tools for prototyping and design handover, quite the opposite. The missing part for me is that they do not have the features to replace Abstract and the features for prototyping and design handover are not exceeding the features of the specialized tools.
I would argue that Figma would best fit small, isolated teams that need a generalist tool over specialized ones or due to cost.
 
Faster in the cloud
One selling point for Figma is that it works everywhere. This is good news if you are forced to work in an organization that only allow PC computers or if you prefer to work on a Linux for whatever reason. Personally I fail to see the importance of this because you should choose the tools that make you most efficient. If you are limited because the organization prioritize hardware over people, then leave right away. Never work for companies that don't care about its people.
The only reason why this is good for Figma is because they want to bring everyone into Figma and as such it must be available on all systems. It does not make the design process more efficient and collaboration of multiple disciplines inside a design tool is far from problem free.
I would say this is only needed if you have the design handover in the design tool or if your workflow is based on passive collaboration.
 
Better Teamwork
This is Figma's biggest selling point in my opinion and it is one they promote a lot. Collaboration is an interesting thing though and it clearly means different things to different people. Figma define collaboration as getting passive feedback through comments and the ability to work on the same designs together.
Comments are passive collaboration
The ability to add comments is the very lowest form of collaboration. It is a passive form of communication and while it is nice to not having to email people to get a comment on a design suggestion, it is best suited for isolated teams that do not have access to the people that they need to communicate with.
For included teams this might at best be something you use when you are not working or to get feedback from people that are not part of the build stream that you are working in. Included teams would get far better results directly communicating with developers and stakeholders than asking for comments.
Adding Notes to your design
While it is sometimes useful to add notes in the design, for example during a workshop, I do not see this as a big selling point as I could just as easily get something like Sketch Notebook to do the same thing.
So while we all want better collaboration, I fail to see how passive communication with external sources will be helpful in most situations. Unless you are an isolated team with little to no access to the people you need to collaborate with. Figma has the same type of collaboration like many other tools that also cater to the same working conditions where you work apart from the people you need to collaborate with.
Is this something that is crucial for a modern designer today? In some cases it might be, but for people who work in an agile and included way this would never be an important feature. It should also be noted that Sketch are also adding these type of features in a near future and if they are similar, then this would not be a big selling point in the future.
 
Design System (not listed as a selling point)
Figma also promote their design system as an important feature, but not as a reason why people move from Sketch to Figma. I bring it up because design systems are used a bit carelessly these days and sometimes seem to be interchangeable with pattern libraries.
In both Sketch and Figma a design system is just design asset management. It is not connected to code in any way, other than that certain values can be seen using the inspect tools in Figma. You would need something like Invision DSM to actually connect code to assets, but usually you will still have a manual step between design and code.
 
Should you make the switch?
This is the big question, just like it was some years ago when Sketch challenged Adobe. Back then it depended on your workflow and your finances mostly, but also what UI you preferred. To some it was also about small company vs big company or just to have the latest hot tool on the market. Here are some the reasons I see.
Figma is the latest hot tool
There is no denying this fact ever since WordPress announced they would go for Figma as the official tool back in 2018. It is now the talk of the town and many are looking at Figma to replace Sketch. If you are one of those that follow the crowd, then Figma is probably pretty attractive right now for this reason alone.
Many designers still work in isolation
Sadly this is still true, even if designers are slowly moving into the build teams. When you are cut off from the daily interactions of the build teams, then you have no choice but to work with passive communication. Having that inside your design tool is a good option if you are crippled when it comes to good communication. Sketch will get similar features so this may not be the selling point it once was.
One cheaper general tool
Money always define the tools we use and the possibility to reduce cost by using one general tool rather that several specialist tools is not a bad thing. If you rarely use the full features on the specialist tools, or if you are struggling with the cost for multiple tools, then Figma is not a bad alternative. It probably has most of the feature you use every day already built in.
Everyone can use Figma
This is something that should not be underestimated. Many companies suffer from low trust and as such managers have the need to control the work even if they should not. In such situations it is very nice to have a tool that is accessible everywhere and the commenting function is also a big bonus.
 
The only drawbacks with Figma as I see it, is that it is an isolated design tool and it is not an offline tool. It has no connection to the build flow and it really needs Abstract as a plugin or a similar product that also have design release flows. The fact that it require Internet also put some limits on where I can or can not work. There are of course plugins to both Figma and Sketch that require Internet connection as well, so the limitations are not only in Figma.
My conclusion when it comes to Figma is that for me there is nothing that make me want to make the switch. The tools are roughly the same and when I need it I will bring in another tool to supplement for example prototyping. It does not fit into my workflow of direct communication where design follows the same cadence as development and test. At least not for the moment.
For isolated design teams, or smaller design teams that do not need additional features I would say this is a great fit due to it's acessibility, indirect collaboration features and price.
For included design teams I would still suggest Sketch + Abstract as the most efficient and collaborative way of working.

After some time in beta Sketch 69 was released yesterday and it was a great release indeed. We finally got Color variables, which has been much requested. We also got the first taste of the components view which is a more structured way to manage all your assets. Finally we got a new insert window to make adding your assets into a design so very much easier and intuitive.
Color variable
This is amazing and I like this a lot, espcially combined with the Components view. For people who find it annoying or time consuming to turn your old layers and styles manually, there is a migration tool that you can use. It is called the Color Variables Migrator and it is of curse free to use.
Components view
This, to me, makes working with assets a whole lot easier. I find that this in combination with the new insert window below make it faster and much more intuitive to work with assets now.
Insert Window
This makes working with assets a pure pleasure. No more droplists to go through with barely visible icons. Instead we get a big, well organised window that you open when you need it pressing "C" where your assets are easy to find and you add them with drag and drop. I love it.
 
This is one of the best updates this year to Sketch as I see it and I look forward to hearing more on the collaboration features they are working on next.