I am rebuilding this site (click to read more)
Jump to content

Articles

wdfw w ff wdf sfsfd sfdwdfsdfwerw r werw erwe rwe rwer werwer werw erwer we r we rwerewrwe rwe rwer wer werwer werwe

My Articles
Community Articles
Guest Blogging Information

My Articles

Show all categories

Ikea introduce Buy Back Friday - will buy back and resell your Ikea items

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.
 
Jimi Wikman
💫 Jimi Wikman

Figma's selling points - just for isolated design teams?

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.
Jimi Wikman
💫 Jimi Wikman

Color Variables & Components view - Sketch 69 make life easier for you

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.
Jimi Wikman
💫 Jimi Wikman

Why Service Design is confusing and therefore very hard to sell

If you work as a Service Designer or as someone who try to sell Service Design assignments, then you probably have noticed that it is not so easy. You probably have met your fair share of people that have no idea what you are talking about. Maybe you have written that off because the job title is still fairly new, but that is not always the case.
Service Design from a UX perspective is still fairly confusing and poorly defined. It's a problem that you hear many definitions of what a UX Service Designer actually do, but there are other problems as well. Let us first look at how UX Service Design is defined.
This is a fairly fluffy definition of what the UX Service Designer do and as with so much of the design discipline it have no real process, but rather some blocks of activities that are loosely defined. It is no wonder why it is so hard to understand what the UX Service Designer will actually do and how it is different from the regular UX Designer.
As UX Service Designers is supposed to work on a higher level than a UX Designer, you also face the issue that many of the executives and managers you meet comes from a background in ITIL. That means that many you will talk to probably have a certification in ITIL Service Design. Now you will face not just the problem to define exactly what you do and will deliver, but you also need to explain why they would hire you when they have a certification in that same discipline.
The ITIL Service Design is a bit different because as UX Service Design focus on the user experience, ITIL Service Design focus on different things and have a different definition of Service than the standard IT definition.
This is why when you step into a room filled with experience executives and managers and proclaim that you are a Service Designer, that might not generate the mental image of a UX Service Designer, but that of an ITIL Service Designer. This is not a very good starting position, especially when you talk about user experience and they might wonder how that is relevant to resource management or fund allocations.
My suggestion is therefore to always refer to your profession as a UX Service Designer rather than just Service Designer. It will make sure you at least will not be confused with an ITIL Service Designer.
Jimi Wikman
💫 Jimi Wikman

Making up combined roles - it is rarely a good idea

Scrum Manager. Developing Architect. Fullstack Developer/Designer. The new roles are popping up left and right these days. Some are clearly just another way to say "generalist", but others are roles that have a very high chance of making people sick. Why do we see these ads? I think it is because the people writing them do not know the craft.
For me, who actually is a generalist with pretty decent competence in multiple fields, I find these ads very amusing. Rather than writing that they need multiple roles filled, but only have budget for one, they make up new roles. Presumably in the hopes of getting someone who can do most of what they think they need.
Because this is the thing, most people that write these ads don't really know what they need. I have seen ads that sound like someone making a frankensteins monster out of the roles. Clearly with little to no understanding of what the different roles actually mean. Some ads just try to mix the best of two worlds, like the Scrum Manager that combines the caring/facilitating aspect of the Scrum Master with the managing/controling role of the Project Manager.
From the person who write the ad it probably makes sense and that is because they do not understand the work involved. From their perspective they probably see a scrum master and a project manager as both having management descriptions, so it should be ok to mix. The fact that they work in different directions where the scrum master work down towards the team and the project manager work up towards the steering group does not seem to occur to them.
In most cases this is not so much of an issue because what you will get in most cases is a generalist. A Scrum Manager for example will be a general manager with some understanding of the scrum process and some understanding of the financial side of project management. The person will not be optimized for any of the roles, but will get things done. Sometimes at the expense of either the project or the team. Or both.
The biggest risk with making these combined roles is that unless you really know that you are compromising the roles you can cause serious damage. Not just to the deliveries and the teams as they do not get the attention they need, but also to the individual you are trying to hire. It is very easy to burn someone out with a combined role, especially if the expectations if that you should do both roles at 100%. The very least you must always do when defining combined roles is to define the ratio. How much time should be spent where and why.
For anyone looking to fill a combined role, here are some examples and some sugegstions on how to approach them:
Scrum Manager - Focus on the Scrum Master part. By making the team working well you will get most of the work as a project manager for free. Deliver reports to the steering with focus on risk mitigation and finance. Progress will come of itself if you focus on the Scrum Master part correctly. If put in a compromised position, always protect the team. It will serve you best in the long run. This is a sure way to burn yourself out if you try to do both at 100%, so be weary of the signs and make sure you get plenty of time to actually work and not just sit in meetings.
  Full stack x - Most designers or developers are full stack, kind of. We do take an interest in what is around us and we dabble in the surrounding fields naturally. So just make sure you are not expected to actually be responsible for anything you are not comfortable with and you will be fine.
  Developing Architect/Scrum Master - This is one of the most devestating roles you can have. As an architect or Scrum Master you will be in meetings constantly, whch means that any attempts to actually develop anything will be a massive source of frustration. If you will attempt this, dedicate blocks of time to development that can not be disturbed. Preferably you work from home or in a separate room with phone, mail and other distractions turned off. Minimum of 4 hours blocks, but I suggest full days for focused work. Avoid this if possible or accept that the amount of developing you will do is most likely next to nothing or will happen during weekends and night time.
  Scrum Master and QA - While most Scrum Master will assist in QA by doing tests or gathering requirements, that is not their actual job. Being a tester or a reuirements analyst is a full time job, just like being a scrum master. If you are going to split your attention between the two, make sure you understand the cost both to you and your team. You will not be doing any 40 hour weeks, but rather do 60 hour weeks to make this work and the stress will be intense. Be mindful of combined roles as they can spiral and become very stressful. What may look like an opportunity to show your skills, especially if you are new in the role(s) can put you on the bech for years if you are unlucky.
If you are looking for people to join your team, always look towards who need that role. Is it for management taking care of the need of the people above, then hire a manager. If the person is taking care of the team, then hire a scrum master. If you need someone to do focused develop, hire a developer. If you need someone to take responsibility for the code structure, hire an architect, or elevate a development lead. And so on...
Combined roles have always been a part of working in IT. As long as you know what you are expected to do and know you can handle it even when things get rough, then ignore the title and do the job. Also be careful about dividing your work because that also can cause serious health issues.
 
Above I have some of the combined roles I see a lot.
What roles do you see and how do you handle them?
Jimi Wikman
💫 Jimi Wikman