Lean UX - Lean UI specifications

6 Dec 2011 - 3:53am
1 year ago
4 replies
1620 reads
Silvia Di Gianf...
2009

Hi all,

this is a call for all the agilists out there: do you have any example/best practice of lean UI Specifications and how you communicate them to the developers, assuming you work in a remote team where members are in 4 different locations?

Thanks!

Comments

6 Dec 2011 - 5:05am
Fredrik Matheson
2005

May I presume that you're using user stories? Are you working in a scrum or kanban setting?

What sort of screensharing/videoconferencing tools are you using?

What level of detail do you give your designs? Are they hand-drawn, partially mocked up in Axure or pixel perfect?

What level of front-end and graphic design skill do your developers have?

On 6. des. 2011, at 09:59, Silvia Di Gianfrancesco wrote:

> Hi all, > > this is a call for all the agilists out there: do you have any example/best practice of lean UI Specifications and how you communicate them to the developers, assuming you work in a remote team where members are in 4 different locations? > > Thanks! > >

6 Dec 2011 - 5:15am
Silvia Di Gianf...
2009

Hi Fredrik,

I work in a scrum setting, using user stories.
We use mikogo or Adobe Connect (Intercall)
I have a clickable prototype, partially mocked up and I am doing mockups to define the pixel perfection following brand guidelines and design patterns standards.
My developers have very low graphic design and front end skills.
Silvia

19 Dec 2011 - 10:41am
Chris Schnaars
2010

We use a wiki to organize and share just about all of our specs, and it has worked fairly well. We'll post screenshots of the design we're working on, add information about contextual use (most of the time, anyway), and explain the behavior of the UI elements. For more complex elements, we'll sometimes post a lo-fi working prototype to give the team the full experience of using the design. It's as flexibile as you need it to be, so you can amp up the front-end specs when necessary.

Generally, the wiki is a great, relatively easy-to-use, tool for creating, editing, and sharing specs. Downsides have included the poor search functionality, and version control. (Though I'm sure that we could have put in better practices for keeping versions up-to-date.)

Hope that helps. I can't send any screenshots of our live wiki, but would be happy to answer any questions you had.

19 Dec 2011 - 11:36am
Jo Packer
2010

 

  • We employ Kanban ideas and thinking.
  • I'm a UX team of one officially, but I work with a very talented design director, product manager and a team of devs with great front end skills and a keen interest in UX. The UX of our products is everyones responsibility, I'm just the only one on this problem full time.
  • We start with scenarios (most of the time) and UX user stories ( as a X I want to ... so that ...) along with biz goals, any relevant tech input or constraints we know about so far and conduct any relevant generative or competitor research (time and budget allowing). 
  • We then start designing using everything we know so far. This often starts with sketches on paper where we always get developer / product manager feedback before refining the design in a prototype. Dependent on the feature or project I might use keynote, HTML/CSS/ some very basic JQuery, HotGloo.com or just copy out the current HTML/CSS and hack it around.
  • Our design director takes those prototypes and starts working on the visual language and componentising that feature or working at a screen/view level design for new products. 
  • We have ongoing discussions about everything from context of use, who we're designing for, what tasks are they trying to carry out, how we should MVP this, to that's not possible, that's going to take ages to build, e.t.c and define our designs / prototypes as we go.
  • As often as possible I push for us to get feedback from users (existing or potential) with using our in-house lab (lo-fi, cheap to set up) or we conduct remote moderated sessions on Skype or failing that remote unmoderated sessions using tools like openhallway or services like http://whatusersdo.com/. I'm not a fan of unmoderated research but am a great believer in the deeper insights and takeways possible with face to face research. However when time is very tight and we're leaning up our UX approach I do sometimes resort to other tools, but it's in the minority.
  • Just before or as the developers start building I make a page on Google drawing with screenshots of the prototype, wireframe or psd with call outs defining interaction and content guidelines. This gives us the what does it look like, how should it behave and what data should appear where and what are the rules.
  • There is ongoing discussion as we build the feature / product and the design gets refined even more, as we learn more. The end product is screenshots of the real thing with callouts about how it should behave (interaction and content) which we refer back to when we work on new things.  It's a bit like a library.
  • I reference the Google drawings and arrange them in our in-house wiki on Google sites. Google docs, particularly Google drawing is not a great tool. It's ugly, clunky and a bit annoying to use, but it's something everyone can access without barriers and it's simple enough anyone can make a change.
  • This lightweight process is working for us at the moment, but in the future I'd like to bring things like story mapping into the way we develop our products.
  • The thing we struggle a lot with is final copy. It's no-ones sole responsibility. When does the copy need to be final? It's hard to come up with this before the thing is built as you need to see the entire flow to make sure it's right. It's hard to do detailed design when you don't know what the copy will be. We don't have a content strategist, not sure we defintely need one, but anythings you want to share on how you do this would be gladly received.
Hope that helps. Let me know if you have any further questions jo[at]songkick.com

 

Syndicate content Get the feed