After decades of promise and hype, artificial intelligence is finally achieving an inflection point of market success. It’s now seemingly everywhere In the past few years, the necessary ingredients have come together to propel AI forward beyond the research labs into the marketplace: huge amounts of data; powerful, inexpensive computer technologies; and the advanced algorithms […]
from CIO Journal. http://blogs.wsj.com/cio/2017/03/03/machine-learning-and-knowledge-discovery/?mod=WSJBlog
Why I’ve developed a negative relationship with the design language, and why you soon will too — that is if it hasn’t happened to you yet.
Okay, I’m going to start this off with one statement; Material Design is great. It has helped unify user interfaces across platforms, and it provides designers with awesome resources (the icons especially 🙏🏽). And while some of you may use Material Design as your UI-North-Star (why are you doing that to yourself), I am not that big of a fan.
Let me give you some background on the short-lived friendship between Material Design and I: It all started in the FABulous Summer of 2014, I was about to enter the 6th grade and my passion in graphic design kick-started. There to help me learn about it, was Google — wo just unveiled their brandnew design language, which within the next few months was going to become so overused that you could rename it to any song played on a pop-music radio station. Better yet was the fact that my father and I had just created our startup, which I was the designer for (By the way, you should totally check out the company). Of course, since I was beginning, I used dribbble to guide me through the many upcoming trends of design, including the embarrassing throwback to long-shadows 😷, and one of the up and coming trends was Material Design. I was intrigued; as far as I was concerned, Material Design was the easiest way to design interfaces. I mean everything was figured out for you; the color palettes were from a selection of colors, the interface-structures were given, the components all have instruction, they even tell you what the shadows should look like. It was like one of those fill in the blank stories, where you replace certain blank spaces with words — but in this case, you’re replacing given fields with ones pertaining to your application. Of course, being a sixth grader I couldn’t resist filling all those blanks, and with that, I was hooked.
Material Design has designers in a chokehold
How many of you followed a design template or language blindly?
Let’s be honest here, by a show of hands, how many of you have tried Material Design or any other super-specific design language and just stuck with it. ✋ Don’t be ashamed, it’s become normal at this point.
Let’s try another show of hands question; How many of you have seen an app which followed the Material Spec so much that if it had a “G” in the logo it could pass as a Google app. ✋✋✋✋✋ Okay, so all the hands went up.
I was guilty of the horrible crime that is conforming to every single standard the folks at Google Design showed us. And by the end of my designing process, my app looked like if Google made an app and just turned the primary color to teal. And that’s my fault. I’m not blaming Google, I’m not even blaming the spec, I’m blaming myself and others who are like that. The kind of people who blindly follow any design language because they think they have to. I was there, and I see many others (not naming names) who do the same thing. And while it is important to have standards for design quality, and even for usability, the problems begin when there is so much to follow, that personalizing a design language gets you an award from Google.
Fixing the issues; Material edition
Now what? After a few hundred words of ranting and explaining why I don’t think it works, where do we go?
I understand that I’m not solving any issues by ranting about things I do not like, so the question is; how do we solve them? We need to make sure that we learn how to infuse our brand into everything we do. Whether it’s adding your own style of illustration, or replacing Material Icons with those of your brand. And another big component is messaging; whether it is through colors, navigation, or just messages.
I like to look to these two apps for inspiration on what to do when it comes to following design languages:
A perfect example of this is Dropbox. I’ve always admired Dropbox in their design inside and out of Material Design. Through clean minimalism and delightful illustrations, Dropbox has mastered the art of making the most of Material Design. Here’s what we can learn from their app.
Despite following the spec, Dropbox was able to customize Material Design to showcase their brand values, which is very important for anyone’s app. By using special elements like illustrations, you are able to maintain your personality even if you decide to use UX-cues from a design language.
Keep your styles consistent
Use the same personality throughout platforms
Have fun with it, and remember that deviation from the spec is not a bad thing.
Airbnb is pretty amazing when it comes to their use of Material Design, mostly because they deviate the most from it.
Airbnb has, in my opinion, nailed the art of showcasing brand within design languages. Through the use of custom icons, fresh imagery, custom elements, and some pretty awesome typography, Airbnb was able to get a really nice aesthetic in their apps. Somehow, they do all of this while remaining on spec. So let’s see what we can learn from them:
Airbnb uses a lot of aspects from other platforms, especially web, and this creates an uber-cohesive experience which can be enjoyed by users. So here’s what they did right!
Typography is important, make sure to make it different.
Icons don’t have to be from the icon pack!
Use colors! Lots and lots of colors!
Final thoughts after an article full of rambling
First of all, congratulations on making it this far. This is my first design article and the fact that you dragged yourself to the end shows me immense support. Also, I’m not writing this as a way to shoot down a group of designers, but to offer insight on mistakes I made when I started. I truly believe that design languages like Material provide new designers a great way to learn more about the realm of design, and they also offer opportunities to experiment for the more experienced.
I would love to hear your thoughts (the negatives as well) and I also wouldn’t mind a recommend 😉.
Thank you for reading!
from Sidebar http://sidebar.io/out?url=https%3A%2F%2Fuxdesign.cc%2Five-grown-to-hate-material-design-5a6d9fc9bc00%23.y6z2b9sd4
I wanted to see how far I could push myself creatively. So I redesigned Instagram.
The challenge: to take an application I love and use everyday, then see how far I could push myself creatively as a designer, by rebuilding it from the ground up.
I chose Instagram because I’ve been a dedicated user since 2011 — a year after it was launched.
Originally, I started using Instagram for its filters. But over the past 6 years, I’ve been able to see all kinds of changes and innovations that have emerged within the app. And I now use Instagram pretty religiously to express myself and stay connected with current trends.
You could say I’m an Insta-veteran.
Side note: I do not work for Instagram, and the views from this case study are strictly my own. Unlike the designers who work at Instagram, I don’t have full access to all the user data that influenced their current design. As a result, this case study is not exhaustive, and I am certainly not suggesting that Instagram abandon their current design and adopt my redesign.
My personal goals in undertaking all this
My goals for the redesign:
To facilitate a more engaging and seamless experience when it comes to exploring and staying connected
To design a more personable and intuitive user interface
To design through user empathy (HCD)
My goals for my own personal development:
Learn how to conduct and analyze user research, create flow charts and wireframes, design through Sketch, craft animations through Principle, and prototype through Invision
Complete my first design project from start to finish while sticking to my design principles
The roles I assumed during the process of building this redesign:
User Researcher
Data Analyst
UI/UX Designer
Product Designer
I left my sketches and wireframes out of this article for the sake of brevity, but you’re welcome to view them here.
Understanding Instagram the company
Instagram is a visual-storytelling application that provides a platform for users to curate and share life’s beautiful and creative moments. Since it’s debut in 2010, Instagram’s user base has grown into the hundreds of millions, allowing people from all over the world to connect and share moments from their life.
To keep up with its ever growing presence, Instagram is constantly innovating creatively to push forward its mission of “sharing the world’s moments.”
My user research and data
Before I began my redesign project, I conducted interviews with 40 Instagram users to get a better understanding of whom I was designing for:
What does a typical Instagram user look like?
What are their reasons for using Instagram?
What keeps them coming back?
I conducted these interviews either in person or via a phone or video call.
Target Audience Demographics
Among the 40 Instagrammers I interviewed, there was 10 males and 30 females. The age of the male users ranged from 22 to 27 years old, while the female users ranged from 19 to 25 years old. 65% are currently college students or high school graduates with plans to pursue higher education.
To make this even more interesting, 67.5% of the users I interviewed ranked Instagram in their Top 3 Most Used Application. Additionally, 72.5% of the people sampled uses their Instagram everyday.
And the fun continues
I asked the 40 Instagrammers I interviewed to describe Instagram using 3 adjectives. What do you think about Instagram? How does it make you feel?
I collected a total of 64 adjectives. The top 3 adjectives were: Creative, Fun, and Simple
I also asked what they liked about Instagram. Here were their top 3 reasons:
it’s picture-based
it’s easy and simple to use
it helps them stay connected
Who do you relate with more? Are you like Alex, who uses Instagram to share his life and occasionally uses the search feature to find cool things? Or are you like Sam, who uses Instagram to stay connected with friends and her interests? Or both?
Either way, I’ll be designing with users like you, Sam, and Alex in mind.
Now that you have a better understanding of who I was designing for, we can move on to the good stuff!
Experience #1: the Home Page
Aside from the repetitive functions within the home page, there were three major problems that I noticed.
Problem #1: Content Overload (Instastories vs Feed)
Immediately after opening the application, Instagram users are met with two prime features competing for their attention — should they scroll through the stories or surf through the feed?
Both options are very content-saturated, and can almost feel like an endless pit of scrolling. According to research on the paradox of choice, more choices can actually lead to decision fatigue, less happiness, and guilt or fear of missing out (FOMO). This is especially concerning when almost half of the Instagrammers I sampled reported checking their Instagram right after waking up and/or at night before bed.
Side note: I decided to keep the minimal chromatic design Instagram implemented in 2016 because I thought the reasoning and logic behind it was pure genius. You can read about it here.
For the solution, I chose to integrate the stories directly into the feed for a couple of reasons:
The feed and story will now be working together to facilitate a more cohesive experience for the user.
Integrating stories into the newsfeed also prevents it from being a “rooftop deck” like what Julie Zhuo (Product Design VP at Facebook) mentioned. In the current Instagram design, Instastories are easily forgotten once the user starts scrolling through the feed. Out of sight, out of mind.
Side Note: Don’t worry, I didn’t get rid of Instastories. I just moved them into the message inbox, which you can get to by clicking on the top right corner of the home page. I will discuss this further below.
Problem #2: Disassociation between top nav and swipe gestures
One of the main questions I sought to answer through my user research was whether or not the swiping features on the Instagram home page was intuitive.
Simply put, are Instagram users aware that swiping left and right corresponded with the top navigation?
To answer this question, I conducted a relatively simple experiment during the interviews.
Method (n=40)
Before I started this experiment, I reminded the users that they should not be looking at Instagram for this portion of the interview. Then I primed the user to visualize the interface of Instagram by describing to me the layout of a typical profile page of Instagram from top to bottom. And then again, with the home page. After describing the home page. I asked them four simple questions.
For swiping:
From the home page, where does it take you when you swipe from left to right? Answer: Camera to post to story
From the home page, where does it take you when you swipe from right to left? Answer: Message Inbox
For the top nav:
3. How do you get to the screen to post to your story? Answer: Top left camera icon
4. How do you get to your message inbox? Answer: Top right “arrow” icon
Note: If the user answered this part of the question with “swipe left/right”, I would prompt them to give an alternative answer. (Do you know another way to get to ______?)
Based on my results, overall swipe knowledge of Instagram isn’t that great:
Only 20% of people responded correctly to both swipe responses.
30% got at least one correct, and 50% got NONE correct.
50% of people know swiping left to right takes them to the camera.
20% of people know swiping right to left takes them to the message inbox.
Top Navigation:
72.5% of people know how to get to their message inbox by clicking on the top right arrow icon.
55% of people know how to post to their story by clicking on the top left camera icon.
Additional fun facts and stats:
Only 3 out of 40 people interviewed got all four questions correct.
On a scale of 1–5 on how familiar they are with navigating around Instagram, 75% of people rated themselves 4 or higher. Only 30% of those people got at least ONE of the swiping questions right.
A considerably high 92.3% of the people who answered incorrectly believed or guessed that swiping left would take them to the explore/search page. (Which makes sense since the search/explore icon is located next to the home icon on the bottom nav)
The analysis from the results suggests thatInstagram users have not established an association between the top navigation and the swiping features.
“I don’t know. I just tap around until I find what I’m looking for, and then all of a sudden I see my face…” — random Instagram user when asked how do they get to their message inbox
One way to make the swipe gestures more intuitive might be to link it with the bottom navigation. However, I thought this would be a great opportunity for me to implement a completely new feature…
Swiping to see new and older posts
Part of my user research was spent reading through the reviews of Instagram on the app store. One of the main complaints from Instagram users was the lack of chronological order on the feed.
What I wanted to know was why people wanted their feed to be chronological? Why were they so upset about this change? By digging deeper, I found that users correlated chronological with thoroughness. With Instagram’s current algorithm, popular posts (deemed to be posts that you wanted to see) are located towards the top of the feed. This frustrates Instagram users because they would often missed a post that they would want to see but didn’t (aka FOMO — fear of missing out).
To compromise with Instagram’s current algorithm and the user’s need for chronological order, I decided to implement this swiping feature with an indicator to give users some peace of mind:
For example, if the indicator is in the middle. You’ll know that this is not the newest post and you can swipe right to see the newer posts. If the indicator is on the far left, you can rest assure knowing that you’re on the newest post from that user. To see older posts, just keep swiping left.
Problem #3: Top left corner — out of reach, out of mind.
People hold their phones in many ways. Regardless of how they hold it, the top left corner of the screen will alway be the most inconvenient and painful location to place a navigation for users. Because reaaaaach *drops phone on face*… or something to that effect.
Research suggests that the most accessible and least painful spot to place the navigations will be towards the bottom of the phone — right next to the user’s thumb.
From my data, 100% of the people I interviewed know how to post to their feed (because they use it). However only 57.5% of those same people either don’t know how to post to their story or just don’t use it at all. To increase the posting activity for Instastories, I chose to combine the two posting features because 1) it is now easily accessible and 2) low-key praying that the popularity from the feed will rub off on the stories.
Experience #2: Explore and Discover Mode
Now you have the option to explore spontaneously through Instagram’s current native algorithm or discover intentionally through your own collection of saved hashtags. So Sam and Alex can just turn on “#ecgtracing” or “#fitness” to stay updated with their interests.
In my case, I would probably turn on “#coffeefliicks” and “#dametravelers” to see aesthetic pictures of coffee and places. You can also just click individually on the hashtags to see one at a time and then drag down to refresh to see all the active hashtags together. You can also click to add new hashtags, delete hashtags, or search within your hashtags collection (and yes, it’s in alphabetical order).
Experience #3: Sliding into the DM and Stories
Only 42.5% of the users I interviewed used Instastories. Two of the biggest reasons why people didn’t use Instastories were because 1) they already have Snapchat and/or 2) they kept seeing new stories from people they don’t particularly care about.
To remedy the second reason, I implemented a new feature called “Stories From Your Favs” to instill more value and purpose into using Instastories.
Now the stories of the people you love, adore, and/or admire are all at the top for your feed for your immediate viewing pleasure. Talk about staying connected!
You can easily remove or add people to your favs by clicking on the heart located next to their name. (Awee)
Side note: What was my reason for moving stories into the DM? First, I needed a place to put the stories since I moved it out of the feed. Second, when you reply to a story or send a photo, it goes directly into your message inbox. Therefore, it made sense to group Instastories and DM into one big happy package.
Another side note: In the current message inbox interface, there is no bottom navigation. Users would only know how to get back to the home page if they know how to use the swiping features, and as I mentioned above — only 20% of the users I interviewed knew that swiping left takes them to their DM. With that in mind, I decided to keep the bottom navigation static here so that users wouldn’t feel lost.
Experience #4: Notifications and Profile
Ahhhh… the final stretch. For the notifications and profile page, I wanted to give the user interface more breathing room by adding more negative space and grouping/nesting similar items.
Additionally,you can now “like” and reply to comments directly within your notifications just by holding that person’s username (tapping takes you to their profile). Once you hold the username, it will trigger a comment box to appear with an automatic @username. Then all you need to do is to type your response and hit “Post”.
I thought this would be a great feature because often times, you can get lost in the sea of comments within the post. What was their username again? Where is the comment? What did the comment say?
“Following” Notifications
Last fun fact of the day — only 35% of the Instagram users I interviewed checked the activities of the people they were following. Whether to keep this function or not was probably the hardest decision I had to make. I decided to keep it and simply redesigned it in a way as to draw more attention to the activities by enlarging the photos.
Profile
To be honest, I love Instagram’s current design. To increase the minimalism, I made some slight changes to the viewing icons and added in more negative space to keep the design consistent.
Reflecting on the work I’ve done here
Going into this project, I knew this would be the perfect opportunity for me to hone my design skills. I had just switched from studying medicine this past semester, and I wanted to pursue a career in product design. So I figured the best way for me to learn would be to just throw myself into a project, and go from there.
Looking back now, that is a complete understatement. Within the last two months, I was able to learn all the things I set out to learn in order to deliver this project and so much more.
I think one of the best things about the learning and creation process is that you come to curate your own. You learn what works, and what doesn’t. You learn how to do things faster, better, and more efficiently. You learn random things along the way while trying to learn about the thing you actually set out to learn.
And the cherry on top of that is that it doesn’t end. The learning process is continuous.
from Sidebar http://sidebar.io/out?url=https%3A%2F%2Fmedium.freecodecamp.com%2Fi-wanted-to-see-how-far-i-could-push-myself-creatively-so-i-redesigned-instagram-1ff99f28fa8b%23.jmfeahdul
Though San Francisco-based startup Abstract has only launched in private beta, the company has already generated significant buzz in the design community. Their promise to fix “disorganized design assets” and “conflicted copies of files creating confusion and noise” through a new, Git-like versioning system directly addresses the friction that designers have tolerated, often painfully, for decades. Abstract’s co-founder and CEO Josh Brewer, formerly a key member of the design team at Twitter, agreed to answer my questions about the company’s still brewing product and long-term ambitions.
Is it too simplistic to describe what you’re building at Abstract as “Git for designers”?
It’s a decent shorthand for what we’re doing, but yeah, it would be too simplistic to just call it that. Abstract is a new way for designers to manage and version their files, document their process, and work on things in parallel with a way to bring the work together and not lose the history. It just so happens to be built on top of git. And we built it on top of Git because it is a stable, proven technology. And because the ideas behind Git (decentralized version control, committing, branching, and merging, diffs, etc) are sorely missing from most designers’ workflows today.
Can you explain, especially for designers who are not intimately familiar with Git, what ideas you mean?
Absolutely! There are a few really awesome concepts that are central to a healthy version-controlled workflow. We came up with the acronym CBM as a shorthand: Commit, Branch, Merge. But before we get to those, it’s important to point out that Abstract is not a syncing service.
Why is this important? Have you ever wondered why we have “conflicted copies” all over the place? A sync-based architecture looks at two binary files and can only understand that there is a conflict, but has no way to resolve it.
Abstract is true version control. That means Abstract understands the entirety of the file and every time you save (and commit) we know exactly what changed between the two versions of the file.
Okay, can you explain those three core concepts? Starting with Commit…
Commits are like saving and annotating your work all in one go. Commits provide context and help everyone understand your work. Extra bonus: you know how you did that one really interesting thing but weren’t sure about it and now after a couple weeks you realize you were on to something? You can go back and pick up that idea and bring it forward. Thank you, commits.
Branching?
No more duplicating files and appending your initials to the end of the file name in order to riff on someone’s design. Branches are organized and safe spaces for ongoing work in a project that can be merged back into master once the work is approved. It’s like being able to duplicate your files for a new exploration and having the ability to bring it all back together in the end. As if that weren’t enough, scanning down the list of branches provides a quick overview of what’s going on for any given project.
And merging?
If you’ve ever had to open up two (or more) files and tried to copy-paste stuff from all of them into a new document that was supposed to be the new point of reference, you know what merging feels like when the files are not connected. Now imagine what life looks like when Abstract can do this for you (with occasional input from you when the same object has been changed in two places).
The idea of “merging” two design files is going to strike some as a frightening prospect. How do you reconcile two versions of the same document that have each been altered drastically but in very different ways?
“A frightening prospect” you say? I don’t know. We do this all the time. It’s just super manual and often involves creating a new document and recreating the whole thing by copying and pasting from the other documents (notice how there is no connection between these files? or that the history is totally blown away when taking this approach…) Now, if you’re saying that having a computer program do this for you scares you, well, we’ve got you covered.
The first way that we calm those fears is by keeping the delta of change between two branches as small as possible. Abstract offers the ability to update your branch with changes from the parent branch while you’re working (this is optional, but recommended). This alone makes the merge process much less likely to have confilcts. As for “altered drastically but in very different ways,” I would need a more concrete example to be able to really address this. If you created two different branches in order to explore two substantially different directions, one could assume that you might pick one and abandon the other. Or you could end up having parts of each that could be brought together. If that’s the case, the Abstract merge process allows you to pick and choose which artboards from which branch you’d want to keep, all the while preserving the history of work.
How much of this feels like a natural extension of what designers do today, and how much of it feels like a new behavior that must be learned?
I would replace “a natural extension” with “an evolution” of what designers do today. There is some new behavior to be learned for sure. I would argue that is core to being a designer today: continually learning and improving your skills and your process. Abstract removes the need to understand the inner workings of Git and you don’t have to use the command line to do your work. The interface provides a few simple actions that give you the power of a Git-based workflow without all the baggage.
I think back on how I used to FTP all the files needed for a web site. I mean, it’s terrifying to think about how many times I edited something on the server when I should have been doing it locally. And then one day someone introduced me to Subversion (and later Git) and I immediately understood the benefits of using version control to manage local and remote files. I’ve only used FTP a handful of times in the last ten-plus years. All because I learned how to use a new tool that protected me from myself, was clearer about what was going on, and could be rolled back with ease.
Designers are an incredibly adaptable and willing bunch—this is why I believe that designers will adopt a new workflow that creates more clarity and better organization, resulting in more consistent work and greater collaboration.
What have you seen in testing Abstract with users? Is it relatively easy for designers to adopt those new behaviors, or is there a learning curve?
Early on we were fortunate to have a few teams that were willing to use Abstract while we were still finishing some of the core feature set. In most cases the teams had some familiarity with Git and Github and were able to “get it” pretty quickly. We also had a few people who were totally unfamiliar with Git and we were very interested to learn how they perceived the product and how difficult it was for them to get the concepts and feel confident using the system. In nearly every case, we were pleasantly surprised by the responses, hearing things like, “I love committing!” and “I cannot imagine working without this.”
There is no question that there is some learning curve, but so far people have been more than willing to spend a little time to figure things out and once they have the core flow down, it starts to become second-nature.
There have been other attempts at incorporating version control into designers’ workflows before. LayerVault, Pixelapse and Folio come to mind, two of which have shuttered and one of which hasn’t quite caught on. I’m sure you have an answer for why Abstract is different and I’d be eager to hear it, but what I’m wondering is this kind of thing can truly become second nature to designers?
Okay, let me try and tease this apart. First, why haven’t previous approaches worked? Second, how is Abstract different? And third, can this become second nature to designers?
First, I think one primary reason these products didn’t last is that they didn’t address the deeper underlying problem: binary files are impossible to version well. And if you don’t understand what has actually changed within the file, it’s incredibly hard to do proper version control. This leads me to number two…
Part of our core I.P. is that we do understand the binary file and can track changes in the file from version to version. This keeps our file sizes much smaller (we only have to store the delta of change) and allows us to take advantage of Git in ways plain binary files cannot. We’ve also taken the important concepts from Git and the well-established workflow and simplified them down, wrapped a GUI around it, and crafted it specially for visual files. There’s a lot more about what makes Abstract different, but I think we’ve touched on that plenty so far.
Three, I sense some fear that this is hard or that it isn’t “natural” for Designers in your question. All I can say is, even with the limitations we currently have, we are hearing things like, “I cannot imagine working without this” and “Man, the ‘it just works’ factor is off the charts.” So, yes, I think this can become second-nature to anyone working with visual communication.
Can you describe for the layperson what it means when you say, “We do understand the binary file”?
Imagine many books on a bookshelf, all with the same white cover. Now imagine some of these books have been reprinted and are on their second, third, or even fourth edition. Without reading through them page by page, how could you tell if any of the books were different from one another? Binary files are like these white covered books: from the outside they look eerily similar but inside they are extremely complex and can be quite different. By using Abstract, we can crack open these files and easily understand what has changed, bit by bit.
How difficult is this to do? Why do you suppose previous design version control products didn’t take this approach?
To be honest, it’s really fucking hard. That’s probably a big reason others didn’t take this approach. And I also think that until you can, no pun intended, abstract away the file you can’t even begin to build the right experience around it.
Is there an inherent fragility in this approach then? Some of these tools, especially the newer ones, tend to change their file formats frequently.
There is some fragility in this approach, but considering that it’s impossible to achieve otherwise, we think this is something we are willing to shoulder so that we can support as many formats as possible. We also hope that going forward toolmakers will see the value in Abstract as well and that we can find—likely through our API—ways to make this easier for both sides so that all of our users can have the best possible experience throughout the design process.
If this works, Abstract puts itself in a unique position. On the one hand, support for Abstract could become an attractive feature for makers of design tools. But then you’re operating a service that could make or break these tools; if your service goes down, do workflows that have been refashioned around Abstract break? And does that effectively roadblock designers in the middle of their day?
If this works, we definitely are in a unique position! As for workflows breaking and such, we built Abstract to work offline. So you can still launch Sketch files, edit and make commits. And you can always export your files if you really, really need to. We take our responsibility in supporting the design process very seriously, so of course, making sure that we don’t “roadblock” designers is of the utmost importance. The amazing thing we’ve seen so far is that even when things are a little wonky, or users encounter a bug, they are more than willing to work around it and to work with us to get to the bottom of things ASAP! We think that’s pretty cool.
Understanding that you don’t want to commit to specific timetables, can you give us an idea when all of this will happen? When will you be out of beta, and what do the following six, twelve, eighteen months look like, roughly?
We are planning to come out of our Private Alpha in Q2 of this year. We have some incredible people using Abstract every day to support their design work and their feedback and input have been incredibly helpful. I’m happy to say that most of the things we are hearing are things we are either actively working on or have on our roadmap for the first half of this year!
Our long-term vision is to provide designers with a stable platform that supports the way modern designers work and increases the clarity, context, and visiblity for the rest of the organization. We started with Sketch files and plan to support Adobe file formats soon. There are several other aspects of the design process (prototyping, presentation, asset management, etc.) that deserve this kind of support as well. Over time, we plan support every aspect of the design process with the same care and consideration.
While we are absolutely focused on designers, we also know that nearly every part of an organization interacts with and is impacted by the design team. Access to the visual history of any project is huge for everyone else that works with designers. We see Abstract becoming critical for top-level executives, product managers, developers, and people in sales and marketing as it answers the question, “What is our product going to look like tomorrow?” This has a direct impact on so many aspects of the business—from copywriting to sales and marketing to business strategy, and more. Being able to know where you are in the process is essential for any business trying to stay focused on delivering value to their customers.
We are just getting started and can’t wait to see how Abstract affects the way we design and build products and companies in the future.
+
from Sidebar http://sidebar.io/out?url=https%3A%2F%2Fwww.subtraction.com%2F2017%2F02%2F27%2Fabstract-wants-to-change%2F